GNOME Bugzilla – Bug 766440
Scale slider button has stopped discerning & rendering appropriately for scales with vs without marks
Last modified: 2016-06-02 13:21:50 UTC
I'm not sure whether this applies to the core or to Adwaita, and nor was Timm when he mentioned knowing about this; please move as appropriate. He also didn't reply on here was an existing bug, and I can't find one, so here's one. The GtkScale slider/button previously rendered in one of two possible ways, depending on whether the Scale did or did not have any marks added to it: * Scales without marks got a round button. * Scales with marks got a pointy button, pointing in the direction of the marks. This was great! I like the round buttons and prefer them where possible, but of course if marks are in play, you want a pointer. So the previous behaviour was great. As of 3.20, this nice distinction has vanished. Now, all sliders are pointy, and it looks a bit weird for the mark-less cases where they don't point at anything! If the user hasn't added marks and, whether explicitly or implicitly, set the mark_pos, then surely it's not correct for GTK+ to decide their slider needs to point at some default position regardless? Please see below screenshots (via another ticket I've opened) showing the difference between 3.18 and 3.20: https://bug766120.bugzilla-attachments.gnome.org/attachment.cgi?id=327456 https://bug766120.bugzilla-attachments.gnome.org/attachment.cgi?id=327457 The scales on the left have marks and thus look the same in both versions. However, the scales at the right side from LEVEL onwards do not have marks and so previously were given round buttons; now they are pointy like everything else. HTH and let me know if anything else is required.
I just noticed that my screenshots demonstrate another new difference: Prior to 3.20, if the (legitimately) pointed button was right on a marked value, a pixel or two of the mark were still visible beyond the point of the button. This has changed too; in 3.20, now the button's point totally obscures the mark. Dunno whether this was intentional? If not, let me know if it needs a separate ticket. For utmost completion, the mark colour/opacity also seems to have changed, but maybe /that/ was intended ;-)
Sorry, the above comment refers to the OUT-LVL slider, which in both cases is set to the 0 dB value where the solitary mark resides. This shows that previously the mark was still visible whereas now the button obscures it.
I've brought back the style classes, so we should be able to fix the 'pointy sliders' from the theme side.
Thanks, looking forward to that. I recall a commit to move the marks nearer to the scale, which I guess caused the change whereby they're now totally obscured by the point. Would you want a separate ticket to ascertain whether or not (I'd vote yes) the mark should extend far enough to be visible 'under' the button? I feel it might be a bit too trivial to have its own ticket, but it'd be nice to get some feedback either way.
Matthias, I'd use "marks-after", "marks-before" sounds clearer, then "scale-has-marks-above", "scale-has-marks-below".
Not the most succinct names, but I presume those were used because that's what they were previously, before removal. This way would restore compatibility with other themes that previously drew on them, and weren't expecting them to be removed... which is surely a good thing.
there won't be compatibility whatever since the css structure and the css properties of the GtkScale changed pretty deeply in 3.20
The theme bits just landed in both 3.20 and 3.21, thanks for spotting, closing.
Created attachment 328923 [details] screenshot of differing colours/contrasts of the two types of slider button Thanks again for the fix; it hit 3.20 pretty quickly. But have I done something wrong while building master, or do we now have mismatched without-marks (round) and with-marks (pointy) sliders? The round one here is very nice, highlighted dark and with high contrast at the sides. The pointy one is very low contrast and very similar looking - and hence difficult to differentiate from - the background. Let me know if you'd prefer me to open a separate ticket or provide a more elaborate demo (I'm on my old system so have to improvise)
Created attachment 328924 [details] fixed screenshot of differing colours/contrasts of the two types of slider button [sorry for the spam; my 1st upload of this got saved with the wrong zoom somehow] Thanks again for the fix; it hit 3.20 pretty quickly. But have I done something wrong while building master, or do we now have mismatched without-marks (round) and with-marks (pointy) sliders? The round one here is very nice, highlighted dark and with high contrast at the sides. The pointy one is very low contrast and very similar looking - and hence difficult to differentiate from - the background. Let me know if you'd prefer me to open a separate ticket or provide a more elaborate demo (I'm on my old system so have to improvise)
No worries that's on the radar, the pointy slider is done with svg assets which I'll update when the I'm done tweaking Colorado, so later in the cycle.
My phone autocorrect wants me to tweak Colorado, but I want to tweak colours :)
Great, thanks for confirming! I went back and tested in 3.20 and realised it was slightly present there, but not enough that I noticed it before :-) It's going to look great: I really like the recent improvements in highlighting/contrasting elements the user can grab, plus the new colours in master. Thanks for all your work on GTK+! (I did run a search for a GNOME Colorado project, but in vain ;-)
Out of interest, is there a similar cause for why the window title/header bar uses different colours too, same as the pointy sliders? Thanks to your info, I checked the assets folder, but I can't find any mention of this widget there.