GNOME Bugzilla – Bug 83393
window list should honor focus line width, but still have two rows
Last modified: 2018-01-24 13:13:33 UTC
If I use a theme with focus-line-width set to 4 it has no effect for the toggle buttons in Window List. This is because the WnckTaskList class init function sets the focus-width for the style to be used for the toggle buttons to be zero.
Created attachment 9602 [details] [review] patch: unsets focus-line-width
In the patch i have removed the lines that set the focus-line-width to zero. So that the focus-line-width would be taken from themes. I noticed from the ChangeLog that this was set to make tasklist fit two lines in 48 pixels. If that's the reason for overriding themes, then can it be done in any other way ?
Maybe an alternative approach to making the buttons fit is to shrink the font for them slightly.
I noticed that if I use a theme with font set to sans 18 i.e basically a _large_ font, the tasklist applet appears in _one_ line. So harcoding focus-line-width = 0 does not ensure tasklist to appear in 2 lines. Havoc, please correct me if I am totally wrong here :/. If I am right then can we remove the hardcoding ? Shrinking font size would not obey themes.
We have two requirements: - there are two rows of window buttons by default on common setups - honor the focus line width There's really no way around doing both. The options I see are to shrink the font a bit (relative to the theme) or shrink the focus line width a bit (also relative to the theme). I don't know how to implement the second one.
I think I didn't convey my thoughts well in the previous post. 1) I noticed that on a common setup : There are two rows of window buttons by default. (Which is want we want and the font size is normal, meaning not large) 2) If I set the focus-line-width to 1/2/3, the window buttons appears in 2 rows. (provided the font size is normal like - sans 12. This is after I applied the above patch, so that focus-line-width would be taken from the theme.) Only _if_ we _increase_ the font size beyond a certain point then the window buttons appear in a one row. So I think this caters well for the default theme.
Ah, I see. It probably depends on your font... Not sure where the happy medium lies. Alex is on vacation, he originally did this code and would probably have insight.
This whole problem is font dependent. With the fonts I tested i needed the extra pixels in order to get two rows. This problem gets worse when you have fonts which cover CJK, because they tend to have larger metrics.
well, * we have to have onscreen focus indication * we need to respect user's font size * we need to allow thick focus lines for users who specify themes with thick focus lines also * we need to support two rows of windowlist items. For users with "special" font size or focus line requirements, I think the requirement about two rows of windowlist items, at least for 48 pixel panels, does not hold. Such users may well want a larger panel. So the sticky problem is perhaps the 'default' case. I don't think it's acceptable to remove a keynav feature (focus indication) just because something "doesn't fit"! It may be OK, though suboptimal, to shrink the font in cases where the font metrics won't fit... but really if the user picks a font that won't fit, it makes no sense to force it. Do you think there is an issue with the 'default' font Alex? And just what would you have done if you didn't have those two pixels to steal ;-)
Yes. I don't care much about the case when you have some modified state. But we have to be able to fit two rows on the window list in the default configuration, or the windowlist will be pretty useless. What i would do if the pixels weren't there is a pretty bogus question. The pixels *are* there, since gnome 1 and all other desktop environments fit two rows at that panel size. There are some technical problem with font metrics here though. Some fons have a large max height, even though with most characters you'll use (say latin characters for a european user) the font will be pretty small. This may happen when you have a font with full unicode coverage (or a combined font), and some japanese glyphs are tall. If you just look at the fontsize and shrink it if it's large you'll get really unreadable fonts... So the solution may involve thinking about pango, fonts and language tags.
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
I don't think this is so complicated really - we just need to patch this code so that the default single-pixel focus linewidth results in the current behavior, and larger focus line widths result in larger allocations (possibly causing only one row to fit). We definitely do NOT want to shrink font sizes to fit, which is what Alex seems to be thinking of and which is causing the complication RE pango, etc. But we need to make this patch ASAP.
No, that is not what i'm thinking about wrt pango. Many default fonts in use are actually unions of various fonts, in order to support many languages. If the union contains a CJK font this will typically mean the font max-height is quite large, as some CJK characters are pretty tall. However, the designed-for font-height might not be that large. I guess we need to make sure that we pick the actual rendered height of the strings in the tasklist buttons instead of something from the font metrics. That might help fix this.
This a11y stopper bug would be good to fix before the July 7th UI freeze, if possible
*** Bug 99201 has been marked as a duplicate of this bug. ***
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Now that we don't have 'fixed' panel sizes (i.e. small, medium, large), but instead can choose any integer size, there's no reason not to fix this, nor is there need to ensure two rows for all cases where two rows would be presented in "normal" themes. IOW, using a three-pixel focus line will require (3-1)*4 = 8 pixels more vertical space than a one-pixel focus line, in order to see two rows.
Something to look at for 2.7.x?
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Moving to the right component. Sorry for the spam.
(patch doesn't apply cleanly anymore, marking as obsolete)
Just a note here. A possible workaround in the theme would be to override the setting from the tasklist again. This would work by doing something similar to: style "tasklist focus-line-width" { GtkWidget::focus-line-width = 4 } widget_class "*.PanelApplet.WnckTasklist.*" style : highest "tasklist focus-line-width"
Removing GNOME2.x target milestone for these bugs since this milestone hardly makes sense now.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libwnck/issues/8.