I noticed that the width at which truncation occurs causes display oddness where the "remove workspace" text is somewhat longer than the truncated text. Also, it doesn't properly cope with UTF-8 because it assumes that one character == one byte. I noticed a question about why the active window isn't highlighted (in #xine) and decided to have a look... this is a trivial enhancement and is most easily done at the same time.
Created attachment 708 Use Pango native ellipsize; highlight the active window item
See also bug 2127 (xfdesktop's window list menu).
Ok, I'll have a look as soon as I can. Sounds like a nice improvement. Thanks.
I committed something, a bit simpler than your patch, similar to what the tasklist does. It's in revision 22718. Thanks!
There's a problem with the way the active window is highlighted (bold text): It's the same way that urgent windows are hightlighted.
(In reply to comment #5) > There's a problem with the way the active window is highlighted (bold text): > It's the same way that urgent windows are hightlighted. > Indeed, there is. Any suggestions for a solution?
Use underlining? if (netk_window_is_active (window)) { g_string_prepend (label, "<u>"); g_string_append (label, "</u>"); }
(In reply to comment #7) > Use underlining? > > if (netk_window_is_active (window)) > { > g_string_prepend (label, "<u>"); > g_string_append (label, "</u>"); > } > Eww ;-) I really don't like underline. Instead I made the active window always prelighted, as if selected. Not perfect, but it's the best I can do. It's in SVN revision 22752. Please reopen if there are still problems with this.
Navigation of the menu via the keyboard breaks the highlighting (but selection of the menu items via the keyboard is broken anyway due to the "activated" signal not being used - see attachment 717 for bug 2104). Personally, I'd rather have underlining or italic - I don't think that prelight really works there unless you happen to be using a theme which makes the highlighted menu item look somewhat like a highlighted button.
Yeah, I saw keyboard breaks the highlighting. I would consider italics, but not underline.
How about revision 22756? It's a fairly subtle effect now, but I think it is ok.
Well, at least it doesn't break anything now :-) Despite it being perhaps a shade too subtle (unlike, say, underlining) and the fact that tooltips appear for untruncated items, I'm happy to call this fixed...