Version: unspecified (using KDE 4.6.4) OS: Linux Interface box in "Capture options" resized almost every time after window opened in Wireshark-1.6.0 and oxygen-gtk-1.1.0 (no such problem with oxygen-gtk-1.0.5) Just after window opened it looks smaller than "Capture filter" box but then becomes the same size. This happens even if animation code removed http://pastebin.com/raw.php?i=gG3NCwHL Reproducible: Always Steps to Reproduce: 1. Start Wireshak 2. Press "Show the capture options" button Actual Results: Sometimes size of Interface box the same as "Capture filter" box but next time it smaller after window opened. Expected Results: Size of Interface box in should not change. Note that window with warning about adding user in wireshark group should not appear. If this window with warning opened before "Capture options" then will be no problems in "Capture options" window.
This is not due to the combobox list resize hook. This is due to our "group box" hack (just compare the appearance of the incriminated dialog 'boxes" between 1.0 and 1.1. You'll see that 1.1 is much closer to what it would look with Qt, but the window resize you experience is the price to pay for this). I'll add an option in CMakeLists to disable that at compilation time (since there is no such thing). The right code to prevent this is: --- a/src/animations/oxygenanimations.cpp +++ b/src/animations/oxygenanimations.cpp @@ -317,7 +317,7 @@ namespace Oxygen if( GTK_IS_NOTEBOOK( widget ) ) gtk_notebook_set_show_border( GTK_NOTEBOOK(widget), FALSE ); - if( GTK_IS_LABEL( widget ) && GTK_IS_FRAME( gtk_widget_get_parent( widget ) ) ) + if( false && GTK_IS_LABEL( widget ) && GTK_IS_FRAME( gtk_widget_get_parent( widget ) ) ) { GtkFrame *frame( GTK_FRAME( gtk_widget_get_parent( widget ) ) ); But I will not commit it, cause it does really look worse than now IMO
So, you think that this annoying window resizing not a bug?
Well. It's not a bug in the sense that it is "intended", as being the only way we can implement Qt like groupboxes. You can prevent the "bug" by disabling this implementation and reverting to the old (inconsistent) implementation of these boxes (the so-called GtkFrame). We decided that the resize issue was a "small enough" price to pay to have the nice groupboxes, since you can't have both (that is: nice groupboxes, and no resize bug). Does that make sense ?
PS: did you try the small patch I sent ? And if yes, what is your personal opinion between the two different rendering of the incriminated dialogs (disregarding the bug you point to) ?
Yes, this patch fixes problem. Maybe this feature should be experimental until will be working without problems. gtkperf will be most objective: 1. gtkperf tests with oxygen-gtk-1.1.0 without patch: GtkPerf 0.40 - Starting testing: Wed Jun 15 01:12:06 2011 GtkEntry - time: 0,13 GtkComboBox - time: 6,36 GtkComboBoxEntry - time: 18,76 GtkSpinButton - time: 1,68 GtkProgressBar - time: 1,14 GtkToggleButton - time: 0,73 GtkCheckButton - time: 0,81 GtkRadioButton - time: 0,85 GtkTextView - Add text - time: 3,42 GtkTextView - Scroll - time: 6,30 GtkDrawingArea - Lines - time: 1,22 GtkDrawingArea - Circles - time: 1,43 GtkDrawingArea - Text - time: 0,47 GtkDrawingArea - Pixbufs - time: 1,03 --- Total time: 44,34 2. gtkperf tests with oxygen-gtk-1.1.0 with patch: GtkPerf 0.40 - Starting testing: Wed Jun 15 01:15:01 2011 GtkEntry - time: 0,09 GtkComboBox - time: 4,71 GtkComboBoxEntry - time: 9,31 GtkSpinButton - time: 0,95 GtkProgressBar - time: 0,77 GtkToggleButton - time: 0,58 GtkCheckButton - time: 0,57 GtkRadioButton - time: 0,54 GtkTextView - Add text - time: 1,78 GtkTextView - Scroll - time: 3,56 GtkDrawingArea - Lines - time: 1,15 GtkDrawingArea - Circles - time: 1,53 GtkDrawingArea - Text - time: 0,39 GtkDrawingArea - Pixbufs - time: 1,24 --- Total time: 27,19 3. gtkperf tests with oxygen-gtk-1.0.5: GtkPerf 0.40 - Starting testing: Wed Jun 15 01:16:17 2011 GtkEntry - time: 0,09 GtkComboBox - time: 4,31 GtkComboBoxEntry - time: 4,80 GtkSpinButton - time: 0,61 GtkProgressBar - time: 0,52 GtkToggleButton - time: 0,43 GtkCheckButton - time: 0,47 GtkRadioButton - time: 0,40 GtkTextView - Add text - time: 0,57 GtkTextView - Scroll - time: 1,17 GtkDrawingArea - Lines - time: 1,11 GtkDrawingArea - Circles - time: 1,39 GtkDrawingArea - Text - time: 0,41 GtkDrawingArea - Pixbufs - time: 0,85 --- Total time: 17,12 I also noticed scrolling performance degradation after updating from 1.0.5 to 1.1.0.
Degradation with scrolling are unrelated to this bug and due to the inner shadows on lists, most likely. This feature should also explain the differences between test 2 and test 3 above. (animations are probably the other main source). Now what do you learn from that ? That more complex (and better rendered) styles take longer than simple one ? I agree. In fact oxygen-gtk-1.0.0 is already the slowest gtk theme on the market (and oxygen-qt probably is too). If speed is the issue, users are still free to use simpler gtk styles. Right ? To me it makes perfect sense that the more feature you add the slower the code gets. (though we do try to minimize the effect). So this, at least, is definitly not a bug. Agreed ? Yes/No ? Concerning "Maybe this feature should be experimental until will be working without problems." Here also, trust me, after spending hours on it, there is *no other way* (this is a gtk2 limitation, which actually got fixed in gtk3). So we balanced the pros (better rendering), and cons (one extra resize when *some* dialogs pop up), and deemed it acceptable (and *not* experimental). Call it a design choice. PS: you did not answer the second question asked in comment #4.
I am not designer so personally for me inconsistent implementation of groupboxes (in 1.1.0 with patch or in 1.0.5) looks good enough. Maybe performance more important for me than consistence. It will be not very good if oxygen-gtk will implement exactly the same look as in oxygen-qt but we have to pay such price as low performance or resizing or other things. Of course users can use other gtk styles (there are not much other styles makes gtk programs looking Qt-like), but maybe the main reasons why they are will not use gtk-qt-engine and use oxygen-gtk instead is no such bugs in oxygen-gtk as gtk-qt-engine have, much better performance. But only one groupboxes feature leads to significant (according to 1 and 2 tests) performance decrease and resize issue reported in this bug. If other features will be implemented with such price then oxygen-gtk may became not more preferable than gtk-qt-engine. If resizing problem fixed in gtk3 why not leave implementation of Qt like groupboxes only in oxygen-gtk3?
Feck... all of the time i was thinking nucleo was talking about comboboxes...
Git commit 1cec3605b5abadb5152d432f61d1896dc399ca7e by Hugo Pereira Da Costa. Committed on 15/06/2011 at 12:03. Pushed by hpereiradacosta into branch '1.1'. added ENABLE_GROUPBOX_HACK flag to disable groupbox rendering. CCBUG: 275665 M +5 -0 CMakeLists.txt M +9 -0 INSTALL M +1 -0 config.h.cmake M +6 -2 src/animations/oxygenanimations.cpp http://commits.kde.org/oxygen-gtk/1cec3605b5abadb5152d432f61d1896dc399ca7e
> I also noticed scrolling performance degradation after updating from 1.0.5 to 1.1.0. Inner shadows hack can also be disabled by ENABLE_INNER_SHADOWS_HACK=0. You'll then get that ugly shadows look from v1.0.5.
Also, after investigating, the gtkperf deterioration between 1) and 2) is *not* due to the resize bug. It is due to the special background rendering for groupboxes, which is practically as complex as the "normal" window background and painted on top. Better rendering, lesser performance. What hits us here is that all gtkperf windows are inside Groupboxes, so the background gets re-painted a lot of times. Luckily enough, this is not representative of many gtk apps. (which shows some of the limitations).
-DENABLE_GROUPBOX_HACK=0 fixes wireshark capture window resizing. Also I built oxygen-gtk-1.1.0 using -DENABLE_INNER_SHADOWS_HACK=0 and -DENABLE_COMBOBOX_LIST_RESIZE=0. Performance now better with this flags but still slightly worse than with 1.0.5 (most notable in GtkTextView and GtkComboBoxEntry tests). GtkPerf 0.40 - Starting testing: Wed Jun 15 16:38:08 2011 GtkEntry - time: 0,07 GtkComboBox - time: 3,10 GtkComboBoxEntry - time: 9,81 GtkSpinButton - time: 1,13 GtkProgressBar - time: 0,61 GtkToggleButton - time: 0,53 GtkCheckButton - time: 0,47 GtkRadioButton - time: 0,48 GtkTextView - Add text - time: 4,11 GtkTextView - Scroll - time: 4,12 GtkDrawingArea - Lines - time: 0,96 GtkDrawingArea - Circles - time: 1,19 GtkDrawingArea - Text - time: 0,36 GtkDrawingArea - Pixbufs - time: 1,02 --- Total time: 27,98
Remaining differences are likely due to animations. (that you can disable via oxygen-settings). but again, I do not see the point. Anyway. Closing, since the "guilty" feature can now be turned off (at compile time).
Maybe GROUPBOX feature should be disabled by default in oxygen-gtk and enabled in oxygen-gtk3 since real fix possible only in gtk3.
@nucleo. I disagree, as mentionned before already: "So we balanced the pros (better rendering), and cons (one extra resize when *some* dialogs pop up), and deemed it acceptable". Ruslan ?
I agree to Hugo. @nucleo If you really want this to be disabled by default, then there should be some poll to see what others think of this (maybe on kde-look.org).
No, no. No poll. Open Source is no democracy (tm), and we (Ruslan and I) are entitled to decide. Now, if many people complain (since happy people usually don't manifest themselves) we "might" reconsider. (though the definition of "many" is left to our discression).