After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 83393 - window list should honor focus line width, but still have two rows
window list should honor focus line width, but still have two rows
Status: RESOLVED OBSOLETE
Product: libwnck
Classification: Core
Component: tasklist
0.x
Other Solaris
: Normal normal
: ---
Assigned To: libwnck maintainers
libwnck maintainers
AP2
: 99201 (view as bug list)
Depends on:
Blocks: 155905
 
 
Reported: 2002-05-29 13:56 UTC by padraig.obriain
Modified: 2018-01-24 13:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch: unsets focus-line-width (1.55 KB, patch)
2002-07-03 07:08 UTC, deepa
none Details | Review

Description padraig.obriain 2002-05-29 13:56:57 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.
Comment 1 deepa 2002-07-03 07:08:54 UTC
Created attachment 9602 [details] [review]
patch: unsets focus-line-width
Comment 2 deepa 2002-07-03 07:43:22 UTC
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 ?
Comment 3 Havoc Pennington 2002-07-25 04:04:15 UTC
Maybe an alternative approach to making the buttons fit is to shrink the 
font for them slightly.
Comment 4 deepa 2002-07-25 10:11:58 UTC
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.
Comment 5 Havoc Pennington 2002-07-25 16:43:15 UTC
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.
Comment 6 deepa 2002-07-26 11:26:35 UTC
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.
Comment 7 Havoc Pennington 2002-07-26 13:20:06 UTC
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.
Comment 8 Alexander Larsson 2002-08-06 09:52:16 UTC
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.
Comment 9 bill.haneman 2002-09-13 16:18:53 UTC
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 ;-)

 
Comment 10 Alexander Larsson 2002-09-16 08:07:07 UTC
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.


Comment 11 Calum Benson 2003-04-03 13:04:15 UTC
Updating status_whiteboard field to reflect A11Y team's assessment 
of accessibility impact.
Comment 12 bill.haneman 2003-06-26 11:26:45 UTC
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.  
Comment 13 Alexander Larsson 2003-06-30 11:13:08 UTC
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.
Comment 14 Brian Cameron 2003-07-02 10:07:07 UTC
This a11y stopper bug would be good to fix before the July 7th UI 
freeze, if possible
Comment 15 Rajkumar 2003-07-15 09:59:56 UTC
*** Bug 99201 has been marked as a duplicate of this bug. ***
Comment 16 Calum Benson 2003-08-07 16:05:10 UTC
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)
Comment 17 bill.haneman 2003-09-12 12:41:09 UTC
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.

Comment 18 Kjartan Maraas 2004-04-18 20:51:52 UTC
Something to look at for 2.7.x?
Comment 19 Calum Benson 2004-10-21 16:50:45 UTC
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
 Filter on "SUN A11Y SPAM" to ignore.
Comment 20 Vincent Noel 2005-01-28 14:37:23 UTC
Moving to the right component. Sorry for the spam.
Comment 21 Elijah Newren 2005-07-18 07:52:41 UTC
(patch doesn't apply cleanly anymore, marking as obsolete)
Comment 22 Benjamin Berg 2006-01-01 16:12:00 UTC
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"
Comment 23 Vincent Untz 2006-01-22 22:22:24 UTC
Removing GNOME2.x target milestone for these bugs since this milestone hardly makes sense now.
Comment 24 Calum Benson 2006-04-26 17:13:53 UTC
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Comment 25 GNOME Infrastructure Team 2018-01-24 13:13:33 UTC
-- 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.