Bug 218615 - unable to render '_' if shortcut key is 'g' 'p' or 'q'
unable to render '_' if shortcut key is 'g' 'p' or 'q'
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gtk2 (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Clasen
David Lawrence
: i18n, Reopened
: 220580 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-06 09:55 EST by Lawrence Lim
Modified: 2014-03-25 20:54 EDT (History)
5 users (show)

See Also:
Fixed In Version: 5.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-27 06:35:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
testcase (680 bytes, text/x-csrc)
2006-12-06 10:00 EST, Akira TAGOH
no flags Details
screenshot for example application in fr_FR (44.44 KB, image/png)
2006-12-06 10:07 EST, Lawrence Lim
no flags Details
working fine (22.17 KB, image/png)
2006-12-22 07:14 EST, A S Alam
no flags Details

  None (edit)
Description Lawrence Lim 2006-12-06 09:55:05 EST
Description of problem:
Noticed that when a lower case char is defined as shortcut keys, the underline
cannot be seen. As a result, user will not be able tell from the UI. 

Version-Release number of selected component (if applicable):
gtk2-2.10.4-5.el5

How reproducible:
Always

Steps to Reproduce:
1.tried with im-chooser in RHEL5
2.LANG=fr_FR.UTF-8 im-chooser
3.Alt+p
  
Actual results:
4th radio button selected but shortcut key is not underlined 

Expected results:
4th radio button selected and shortcut key is underlined 

Additional info:
Comment 1 Lawrence Lim 2006-12-06 09:58:49 EST
Narrowed down to 'g' 'p' or 'q'
Comment 2 RHEL Product and Program Management 2006-12-06 10:00:30 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Akira TAGOH 2006-12-06 10:00:32 EST
Created attachment 142955 [details]
testcase

It seems to happen on GtkCheckButton and inherited widgets. however
GtkToggleButton that is parent widget of GtkCheckButton was ok.
Comment 4 Lawrence Lim 2006-12-06 10:07:10 EST
Created attachment 142958 [details]
screenshot for example application in fr_FR

String from im-chooser.po

msgid "Use _custom input method"
msgstr "Utiliser une méthode de saisie _personnalisée"
Comment 5 Matthias Clasen 2006-12-06 15:45:48 EST
I asssume this happens because we use underline-low for this, and the underline
gets clipped away...
Comment 6 Behdad Esfahbod 2006-12-06 15:48:37 EST
(In reply to comment #5)
> I asssume this happens because we use underline-low for this, and the underline
> gets clipped away...

Correct.
Comment 7 Behdad Esfahbod 2006-12-06 16:00:27 EST
Normally we don't really care if a glyph is clipped (say in a menu name), we
don't want to change the height of the menu bar because of a low glyph.  What we
want however is to make sure the low underline fits in the line boundary
(ascent/descent).  Two solutions pop to mind:

  1. Add a new underline mode.  Ugly.
  2. Make underline-low clip its position to the line descent.  Ugly too.

Should find the lesse or the two evil.  Adding Owen.
Comment 8 Owen Taylor 2006-12-06 16:58:31 EST
Well, underline-low is basically "underline as for menus", so I don't
see 1. as a reasonable choice... if 2. is the correct thing for menus,
then we should just do it for underline-low.

Does this occur for menu items, or just for the menu bar?

Have we considered removing a pixel of padding under menu items, and
then making GtkAccelLabel allocate a pixel more to its child?
(Is there any padding under menu items?)
Comment 9 Owen Taylor 2006-12-06 17:03:21 EST
Sorry, missed that the original example here was a GtkCheckButton, not
a menu item. (I think there is a GTK+ bug open about GtkMenuBar?)

The only thought other than the "squish underline upwards" is to take
advantage of the "draw border" mechanism we have to allow widgets to
draw outside their allocation ...that is, make GtkLabel clip a pixel
bigger on the bottom when there is a mnemonic set, and then stick
a draw border of 1 at the bottom of GtkLabel into the default RC style text 
we parse (currently used for the tooltip background)... a real theme
is unlikely to set a draw border on GtkLabel. Might work, but definitely
hacky!
Comment 10 Matthias Clasen 2006-12-07 02:08:48 EST
I can confirm that adding

style "label"
{
  GtkWidget::draw-border = { 0,0,0,1 }
}
class "GtkLabel" style "label"

does indeed seem to fix the issue.

Maybe it would be less hacky to derive the draw-border from the ink rectangle in
gtk_label_size_request (assuming the ink rectangle includes underlines), but
just putting the above hack in the default rc style is probably good enough in
practice.
Comment 11 Matthias Clasen 2006-12-07 09:54:18 EST
Fix is in gtk2-2.10.4-9.el5
Comment 12 Behdad Esfahbod 2006-12-07 18:29:43 EST
(In reply to comment #10)

> Maybe it would be less hacky to derive the draw-border from the ink rectangle in
> gtk_label_size_request (assuming the ink rectangle includes underlines), but
> just putting the above hack in the default rc style is probably good enough in
> practice.

The ink rectangle includes the underlines indeed.  Should we move upstream?
Comment 13 Matthias Clasen 2006-12-07 18:33:43 EST
I've committed the draw-border hack upstream. If we can come up with something
based on the ink rectangle, we can just replace the hack.
Comment 14 A S Alam 2006-12-22 07:14:55 EST
Created attachment 144272 [details]
working fine
Comment 15 A S Alam 2006-12-22 07:16:55 EST
it is working fine with following version (check screenshot for details):
gtk2-2.10.4-11.el5
Comment 16 A S Alam 2006-12-22 07:18:42 EST
Package is part of following Tree:
RHEL5-Client-20061221.nightly
Comment 17 Matthias Clasen 2006-12-22 08:29:35 EST
Reopening since this change uncovers a relatively serious memory leak in  GTK+,
which is a REGRESSION
Comment 18 Matthias Clasen 2006-12-22 08:30:47 EST
*** Bug 220580 has been marked as a duplicate of this bug. ***
Comment 19 Matthias Clasen 2006-12-22 09:05:42 EST
Memory leak fixed in 2.10.4-14.el5
Comment 21 A S Alam 2006-12-27 06:34:35 EST
All supported languages are working normal and shortcut keys are available
 with following version:
gtk2-2.10.4-14.el5
Comment 22 A S Alam 2006-12-27 06:35:53 EST
Package is part of following Tree:
RHEL5-Client-20061226.nightly

Note You need to log in before you can comment on or make changes to this bug.