Version: unspecified OS: Linux See e.g. this combo2 test: http://simplest-image-hosting.net/png-0-progressbar-bug . The same applies for progressbar.php test. In real world apps, this can be seen in pidgin's transfers window, also in update-manager when it loads configuration. In fact, this is a regression introduced by commit 37a4a68baf1dc63e4fb7b38c53e51c1946bda853. Reproducible: Always
Good catch. Will work more on this. Commit 37a4a68baf1dc should not be reverted though. Without it you end up with glitches in firefox and thunderbird progressbars, because they were erasing a too small area when moving the progress around. Not that I care much about the apps above, but this was really a bug on our side this time: you should not paint outside your allocated rectangle. (I even had to tweak the cliprect to make it work before, which is not good either). So I'll work on fixing the combobox demo *on top of* commit 37a4a68baf1dc. (possibly by adjusting the holes). Cheers Hugo
Git commit 1d64bd5a07ccb5bc3046f9e0804ba19958f528e8 by Hugo Pereira Da Costa. Committed on 26/05/2011 at 11:22. Pushed by hpereiradacosta into branch 'master'. re-adjusted scrollbar handle when rendered in cellviews, to match new rendering from commit 37a4a68baf1dc63e4fb7b38c53e51c1946bda853. CCBUG: 274144 M +1 -1 src/oxygenstylewrapper.cpp http://commits.kde.org/oxygen-gtk/1d64bd5a07ccb5bc3046f9e0804ba19958f528e8
Fixed for cellviews, but still not fixed for update-manager (GNOME frontend for apt). See http://simplest-image-hosting.net/png-0-progressbar-bug0
rha damn it. It does work well for "normal" progressbars. Must be smthing fishy.
Russlan: could you post the printout of oxygen-gtk in debug mode of gnome update manager when the progressbar is being updated ? I'd like to know which drawing primitives are called and for which type of widgets/details ... Thx !
PS: sorry for "Russlan" and not "Ruslan" ;)
Created attachment 60359 [details] update-manager debug output
Hello Ruslan, Thanks for the log. This is strange. The output shows the right methods Oxygen::draw_box - widget: 0xa379688 (GtkProgressBar) state: normal shadow: in detail: trough (draws the hole) Oxygen::draw_shadow - widget: 0xa379688 (GtkProgressBar) state: normal shadow: in detail: trough (this one does nothing) Gtk::gtk_widget_is_applet(): GtkWindow.GtkVBox.GtkVBox.GtkProgressBar Oxygen::draw_box - widget: 0xa379688 (GtkProgressBar) state: prelight shadow: out detail: bar (draws the handle) I just checked that the same calls are being made when rendering progressbars in (for instance) oxygen-demo, but there the rendering is working fine (you confirm). So I'm a bit clueless :( Just added and committed printing out of the painting Rect in the relevant methods, in order to try know more about whats wrong/different. If you get a chance to post an updated log after that ...
Created attachment 60400 [details] update-manager updated debug output Here it is
Git commit 78104ba96d83d042275392697bb34a06888319c1 by Hugo Pereira Da Costa. Committed on 29/05/2011 at 12:40. Pushed by hpereiradacosta into branch 'master'. properly handle "custom" x/y thickness when rendering progressbar handles CCBUG: 274144 M +16 -1 src/oxygenstylewrapper.cpp http://commits.kde.org/oxygen-gtk/78104ba96d83d042275392697bb34a06888319c1
OK, fixed.