Created attachment 6891 Screenshot of plugins in panel Arch Linux 4.8.6 xfce4-diskperf-plugin 2.6.0-1 Bar always has 1 thick mark marked even with 0 kbytes/sec transfers Same error affects Netload SystemLoad plugins
it seems the bug goes from this commit https://git.xfce.org/panel-plugins/xfce4-netload-plugin/commit/?id=d35e3a59a6369845a835270b2e4f380950e04b03 Affects all plugins that use progress bar element.
That would be a bug in Gtk3 theming engine, see https://github.com/shimmerproject/Greybird/issues/153 Either i put some styling so that the pbar has a 4px width (and then looks the same as with gtk2), or the pbar has the default 1px/2px width and then users will complain that they don't see the pbar...
If someone find a solution that works for everyone (ie various combinations of themes/panel orientations/etc) i'll be more than happy to commit a patch. I wont spend hours digging into that nightmare now.
*** Bug 12941 has been marked as a duplicate of this bug. ***
*** Bug 12948 has been marked as a duplicate of this bug. ***
*** Bug 12949 has been marked as a duplicate of this bug. ***
*** Bug 12974 has been marked as a duplicate of this bug. ***
*** Bug 13077 has been marked as a duplicate of this bug. ***
Hmmm, not sure that gtk is the culprit. For me, the bug was introduced by the latest xfce plugin versions. Before, I had the *.99 versions of the same plugins. They looked completely different (thick, rectangular bars instead of thin, rounded ones) and did *not* have the problem. Gtk was 3.22 for both the old and the new plugins. So it was a change in the plugin versions which introduced the problem, not a change in Gtk versions?
it's in conjunction with min-width/min-height css that was added after *.99 and before .0, see comment #3. If i remove this styling, pbars are very thin, and then users will complain that their monitors/progressbars don't look the same as with Gtk2.
Continuing discussion from https://bugzilla.xfce.org/show_bug.cgi?id=12974 which was closed as duplicate. I have reported a Greybird bug [1]. This bug is two fold: border around inside part of the progress bar is being shown even with progress 0%. Atempt to fix it by Greybird project make it possible to make border for 0% progress dissapear, but at the same time introduced different visual glithes. So at the time of the writing, Adwaita has problem #1 - it shows border for 0% progress, Greybird has problem #2 - there are visual glitches when progress is >0%. Greybird maintainer filed Gnome bug [2] for that. If you use Gtk3 style without border, bug [2] does not appear. Now Xfce updated some plugins for panel to Gtk3 version. They seem to work on my Fedora 23 with Gtk 3.18 and do not on higher verions with Gtk 3.20+. Even when it broke on the same version of Gtk, it is NOT the same thing. Xfce plugin progress bars which are supposed to show 0% progress show progress around 20% on my system. That is about 6px and I clearly see 4px of inside of the progress bar, not just the border as in bug [2] and attempted fix which caused bug [1]. It does not matter if I use Greybird, Adwaita, or a theme without border which is unaffected. I have also tried to create a normal Gtk3 app using PyGObject with vertical progress bar and it seems to work "fine" when we take in the regard bugs [1] and [2]. IMHO the problem is indeed created by "min-width: 4px; min-height: 4px;" CSS override now needed to make a thicker progress bars then directed by theme. However I believe the code needs to detect if bar is vertical or horizontal and set just one of those, not both at once. I will try to play with it as time permits. [1] https://github.com/shimmerproject/Greybird/issues/153 [2] https://bugzilla.gnome.org/show_bug.cgi?id=774695
(In reply to skontar from comment #11) > IMHO the problem is indeed created by "min-width: 4px; min-height: 4px;" CSS > override now needed to make a thicker progress bars then directed by theme. > However I believe the code needs to detect if bar is vertical or horizontal > and set just one of those, not both at once. > > I will try to play with it as time permits. If you come with a patch that does this properly, i'll gladly apply it to all plugins. I'm not happy with the current situation either, but i added the min-width / min-height (hastily, maybe) because i wanted to avoid changing the 'default style' of the progressbars when going from Gtk2 to Gtk3, which would have caused other bug reports ("my progressbars are too small, i can't see the value/color!")....
I have a patch on mind, however I had trouble to understand how should I build Xfce on Fedora last time I have tried. I have this on my TODO list, and I hope to get to the point of contributing to Xfce soon (tm) :-D. I was thinking, maybe naively, something along the lines of: #if GTK_CHECK_VERSION (3, 20, 0) if (xfce_panel_plugin_get_orientation(global->plugin) == GTK_ORIENTATION_HORIZONTAL) { css = g_strdup_printf("progressbar trough { min-width: 4px; } \ progressbar progress { min-width: 4px; \ background-color: %s; background-image: none; }", gdk_rgba_to_string(&global->monitor[count]->options.color)); } else { css = g_strdup_printf("progressbar trough { min-height: 4px; } \ progressbar progress { min-height: 4px; \ background-color: %s; background-image: none; }", gdk_rgba_to_string(&global->monitor[count]->options.color)); } #else
(In reply to Landry Breuil from comment #12) > If you come with a patch that does this properly, i'll gladly apply it to > all plugins. I'm not happy with the current situation either, but i added > the min-width / min-height (hastily, maybe) because i wanted to avoid > changing the 'default style' of the progressbars when going from Gtk2 to > Gtk3, which would have caused other bug reports ("my progressbars are too > small, i can't see the value/color!").... Actually, they *are* very thin now (I can't count the pixels exactly): * Years ago (Gtk 2), they were "medium sized" (about half the height of the label text size), best size in my opinion. * Then they became quite thin (not sure when and why). * With the *.99 releases, they became really thick (same height as the label text or more) * With the current release, they became quite thin again (less than 1/3 of the .99 height, less than 1/2 of the original Gtk2 height). Gtk3.22, horizontal bars, Mate themes.
(In reply to skontar from comment #13) > I have a patch on mind, however I had trouble to understand how should I > build Xfce on Fedora last time I have tried. I have this on my TODO list, > and I hope to get to the point of contributing to Xfce soon (tm) :-D. > > I was thinking, maybe naively, something along the lines of: Note that you also need to make sure the styling is applied again if the orientation of the plugin changes at runtime.... (In reply to Klaus Kusche from comment #14) > Actually, they *are* very thin now (I can't count the pixels exactly): > * Years ago (Gtk 2), they were "medium sized" > (about half the height of the label text size), > best size in my opinion. > * Then they became quite thin (not sure when and why). > * With the *.99 releases, they became really thick > (same height as the label text or more) > * With the current release, they became quite thin again > (less than 1/3 of the .99 height, less than 1/2 of the original Gtk2 height). Whatever we settle on, there will be dissatisfied users.. ideally, this should be based on the theme defaults, so we don't have to fiddle with it.
https://git.xfce.org/panel-plugins/xfce4-diskperf-plugin/commit/?id=dd61ff6ef11fe610a47d4938cb9ac9b5482f35eb implements more or less what skontar proposed in comment #13, and should fix this issue (iff your gtk/theme is fixed too... see the commit message) Will propagate the change to other affected plugins.
Great news! Thanks!