GNOME Bugzilla – Bug 766120
Scale draw_value() align changed from centre/right (H/V) to left, causing significant visual regression
Last modified: 2016-07-30 09:18:43 UTC
Created attachment 327456 [details] BEFORE. Note how 0 dB is centred (relative to other, -ve dB values) and the LEFT/RIGHT fits within the widget. As in the title. When using Adwaita GTK+3 to render a vertically oriented Scale with draw_value(true), previously the displayed value text would be aligned to centre. This was of course a sane default: one would expect the value to be centred above the trough, and centring elegantly handles most types of value, accommodates number lengths, signs or the lack thereof, etc. I run Debian testing, and today I did an aptitude full-upgrade and received its current latest version of GTK+ (and gtkmm, etc.) To my despair, I then found that - alongside a raft of other sudden and really rather stark changes to Adwaita - Scale value 'labels' are no longer centred, instead preferring left alignment in most cases and simply flowing off the edge of the widget in others. Please see attached screenshots of my program. The old version is the one with the labels always centred, which you'll agree looks very tidy. The new version of Adwaita ruins this as now the labels suffer from the problems mentioned above and look horribly inconsistent merely based on their values. I hope this can be rectified by the 'label' being centred again, or finally add some API to allow users to specify how they want the value text to align. Thanks
Created attachment 327457 [details] AFTER. Now the 0 dB is aligned left. and the LEFT/RIGHT max flows off the visible edge of the widget. Ugh!
fwiw, I would assume this is the relevant line from the Debian package logs: [2016-05-07] gtk+3.0 3.20.3-2 MIGRATED to testing (Britney)
OK, having analysed it some more, it seems that the real problem is this. Please note these are only functional descriptions, not necessarily reflecting the code. * Before this update, the formatted TEXT was auto-centred, so whenever the value changed, the resulting formatted draw_value was (re-)centred above the trough. * But now, the text is left-aligned within the 'label', and THAT is positioned in another way. Some cursory tests indicate that perhaps this 'label' is aligned appropriately for whichever of the min/max values has the widest formatted result, since many of THOSE appear to get centred OK, but please double-check this... in any case, if our intermediate values' formats have different widths than the min/max, we're SOL after this update, and they get stuck left or right. I hope you agree the former behaviour is far more intuitive and, more important, visually usable. The latter causes some really ugly Scales as soon as any mildly complex formats is drawn... which unfortunately, my program is full of. I've had a great time with GTK+ up until now, so I hope this can be rectified very soon. I don't know whether this is a result of the recent spate of CSS changes in the theme, or part of the GTK+ core itself, but please move if appropriate, to wherever gives it the best chance of a quick fix.
I should correct myself: this isn't specific to vertical scales or values drawn at top. It's simply MOST noticeably different/bad there! But it has changed on all other value_pos settings too, where it also harms visuals. Perhaps a better solution to all of this, is to finally provide some API for users to set the alignment of scale value text within its label - as in some cases, left/right aligning might be preferable (e.g. right-align a numerical value at the left side of a horizontal Scale). (In case anyone suggests: I know it'd work around but really don't think this is something we should have to kludge by adding and managing our own Label. In that case, I could just use Qt... The point of GTK+ is it usually saves me work via clever features/defaults. Till they change and break the look of pre-existing UI!) Until an alignment API can be added, at a minimum the long-established previous behaviour should be restored. Thanks in advance, for either of these solutions!
-> gtk+ That code was rewritten past cycle, and this looks like a regression from that work. Which application is this issue reproducible with?
Hi, thanks for the confirmation. I am about to attach a minimal replication program. I use gtkmm but presume it has no relevance to the detailed behaviour of the widgets it wraps. Compiled as follows: g++ `pkg-config --cflags --libs` -std=c++14 test.cpp ./a.out I compiled and ran this on both Debian stable and Debian testing, which respectively do and do not exhibit the problem: * On stable, value text is centre-aligned above the trough of vertical scales, or right-aligned to the left of the trough for horizontal scales. * On testing (latest GTK+ libraries), text always gets left-aligned, within a label that (as mentioned before) is sized/positioned according to some other method, perhaps by checking the formatted values of get_lower() and get_upper() So just to confirm, the problem affects horizontal scales too. I guess it affects all value positions/orientations in some way. I'll also attach illustrative screenshots for readers who are in a rush :-)
Created attachment 327478 [details] minimal replication program g++ `pkg-config --cflags --libs gtkmm-3.0` -std=c++14 test.cpp
Created attachment 327480 [details] screenshots of the MCVE on old vs new GTK+ showing the differing alignments top row: Debian stable's gtk+3.0 (3.14.5-1+deb8u1). bottom row: Debian testing's 3.20.3-2
I used an old version for my 'before' ref, because it's much easier to use my spare machine than a VM or etc. There are unrelated things that changed between 3.14 and 3.20.0 - most obviously how the origin/fill level was previously drawn on the wrong side of the button. (Glad I moved to developing on my testing box!) But the change in value text alignment arose between my previous 3.20 and my current one. Just confirming this to avoid any confusion based on the versions. Notably, also, so did the change to using the same button graphic for scales with and without marks: previously, these used pointed and round buttons, respectively. I don't know whether this is intentional (by commit msgs; I'm not likely to search the diffs), so it may be worth checking as a side-quest to this.
FWIW the pointy-slider problem is a known problem, at least I've told lapo about it quite some time ago, I'm not sure if it turned out to be a gtk+ or an Adwaita problem though.
Thanks Timm. Assuming that one isn't really intentional, please let me know if anyone unearths an existing ticket for it, or if you'd like me to create one with a trivial example. But hey, I noticed recent updates did improve other things :-) Previously the value text was different colours/opacities for scales with/without marks, but now they're unified. This is a big benefit to consistency and (once joined by properly aligned labels) will make things look much nicer. The dimmer controls in Adwaita Dark also give better contrast (once I get used to the difference!) The bizarre thing is: I have a screenshot of my rarely tested Windows port, via MSYS2, which appears to have most of these recent changes already in place. This is despite how Debian testing continued looking the 'old' (and in some cases better) way before this weekend. I compiled that test of my program about a month ago and would assume MSYS2's GTK+ isn't that far ahead of Debian... and it surely wouldn't even have reached 3.20 by that date. So I must ask: have all these changes already been made in a past version, rolled back before 3.20.0, then redone? Else I'm lost to explain that screenshot's existence. I'll attach an excerpt next, but feel free to request more info or to arrange a full shot. Anyway, given how slider-heavy my project is, I'm in a good position to notice stuff like this, so I'll enquire or raise tickets wherever I can help out.
Created attachment 327534 [details] [review] widget-factory: Let one of the scales draw a value
Created attachment 327535 [details] [review] scale: Center the value I'm not certain how the alignment should work, especially considering the amount of options involved (value pos, scale direction, text direction). This patch just changes it for value_pos=TOP/BOTTOM.
Review of attachment 327535 [details] [review]: Thanks, Timm - Looks good to me. As a further optimization, I wonder if we really need to set all the properties on the layout every time gtk_scale_get_layout() is changed, but that can come in a later patch.
Review of attachment 327534 [details] [review]: Good idea
Many thanks, both. Not to be annoying... but do you think we could also get the old right-aligned behaviour back for horizontal scales? At least until you think of a better/configurable way - surely restoring the unintentionally changed old behaviour is far better for existing projects that would otherwise have their UIs altered. Btw, maybe it already left-aligned if that was the text direction; I wouldn't know as I haven't used that before.
I'm not sure what the old behavior was tbh. I imagine: Scale horizontal, value left : right-aligned Scale horizontal, value right: left-aligned Scale horizontal, else : centered Scale vertical, value left : right-aligned Scale vertical, value right: left-aligned Scale vertical, else : centered So that seems pretty easy and the text direction doesn't even affect it. Is that what the old behavior was?
Hi Timm, I would need to test it on an old version to absolutely confirm, however that definitely sounds both familiar and aesthetically preferable :-) Having used these two combinations extensively, I can confirm your guesses: "Scale horizontal, value left : right-aligned" "Scale vertical, else : centered" And from these, by symmetry, I would assume you're right on all the others too. These are consistent and visually effective because it means that in all cases, the edge of the value is placed as close as possible to the trough or button (depending on whether the configuration creates a fixed-pos or 'floating' value). Thanks again!
I can update my patch later today if Cosimo doesn't have any objections (and implement the mentioned optimization at the same time).
Superb, thanks, I'll await the update. It'll be great to see the restored alignments combined with the various intentional refinements made in 3.20. Because for completion, to answer comment #11, unknowingly I was still on 3.18 till recently! Per Debian's logs, 3.20 hit experimental on Mar 23, but only migrated to testing on May 7. Till then, my testing system would've been 3.18. I didn't consider this, as most of my other GNOME components were at 3.20, so I assumed GTK+ was too. This explains why my month+ old Windows compile had the latest differences discussed herein. At the time, I thought this was because MSYS2 had /older/ GTK+! Very interesting that it leads testing. I might move to Debian unstable, which got 3.20 on Apr 16, so I'd have noticed this all sooner.
Created attachment 327597 [details] [review] Scale: Set correct value alignment
Review of attachment 327597 [details] [review]: Looks good to me, thanks.
Pushed both, thanks for the quick review.
Thank you Timm. Closing as FIXED.
Many thanks, Timm and Cosimo. Now the fun part: wait for my distros to catch up!
Please can I request this patch to be merged into 3.20? It'd be really helpful for myself and I'm sure many others to get correct alignment restored. Thanks.
Too late! https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-20&id=3659eb65d079c832e02a273757e2d72c408099ad
Haha, I checked the branch not very long before you did that, but obviously I'm not refreshing obsessively enough :) Thanks again.
Hi folks, any idea if we'll be able to take advantage of this soon, i.e. an ETA for 3.20.7? It's one of several significant visual issues that have been fixed in 3.20 since .6, giving substantial fuel for an update.