GNOME Bugzilla – Bug 648570
Mnemonics don't show under some letters
Last modified: 2014-07-20 06:12:58 UTC
gedit, baobab, devhelp, glade, mines, totem, all are affected. None show the mnemonic under the 'Quit' menu option. Using Ubuntu 10.10 The mnemonic works, but the underline doesn't show on some letters, I've narrowed it down to the letters that are drawn under the baseline. 'q' 'y' 'p' 'g' 'j' 'ç' 'Q' 'Ç'
This is caused by 2 things: 1) the underline coordinate is determined by the ink extents, so with letters that go below the baseline, the underline will be lower 2) the low underline is drawn outside of the logical extents of the layout. Because a label determines its size based on this (and actually gets cairo_clip()'ed to it), the underline becomes invisible. In GTK2 this did not happen because we had draw rectangles and the draw rectangle was always set to be 1 px bigger than the actual layout and that resulted in the underline to become visible, as long as it wasn't directly at the corner of a (GDK) window. So how do we best solve this? Use the union of ink and logical rectangle when requesting sizes?
(In reply to comment #1) > So how do we best solve this? Use the union of ink and logical rectangle when > requesting sizes? I don't think you'll find any attractive solution other than letting the low underline extend out into adjacent padding: - You don't want to preemptively make all labels 1 pixel taller just because they might get a low underline - The height of a menu can't bounce when you hit alt and the underlines appear - You can't drop the low underline feature - it just looks awful to underline single letters with a normal underline that bumps into or intersects the descender.
The problem then still remains that there might not be any padding available that we could use. We'd basically rely on themes to add enough pixels of padding to menu items or menu bars and buttons, so that mnemonics do appear. We also cannot rely on the mnemonic to be just 1 pixel I guess because when using larger fonts it can easily grow to multiple pixels... The easiest thing would be if we could find a nice way to layout the mnemonic that does not involve drawing outside of the extents, but I guess we can't have that...
There's at least two related issues to consider while looking for solutions: 1. Alignment: we don't want items in a menubar to start jumping up and down if some of them have a low underline while others don't. This is really a special case of baseline alignment 2. There are other situations where we don't want a labels size allocation to change due to temporary font/text/style changes. One i've recently run into is marking an item as 'current' by making its text bold. You don't want the list of all items to change width due to this; each label should reserve enough space for its text in bold, even if it is not currently bold
The second problem occurred in bug 648136 , and has been worked around in the usual, cumbersome way: duplicating all labels, and switch between the bold/normal versions by controlling widget visibility.
Proposed quickfix: Switch from low underline to normal underline for mnemonics until we have a fix for this. I think it's way better if we do show the mnemonic then if we don't.
I think I'd rather bring back draw-border as a special case just for labels
(In reply to comment #7) > I think I'd rather bring back draw-border as a special case just for labels This has been done now. Leaving this bug open to deal with more general issues.