GNOME Bugzilla – Bug 99604
Better abbreviation of titles when space is tight
Last modified: 2018-01-24 13:20:05 UTC
Suggestion from a Sun customer (I'm sure there was another title-abbreviation bug open somewhere but I can't remember if this is what it was suggesting and I can't find it now...): "It would be nice if (the window list) used the Mozilla/Netscape algorithm for abbreviating newsgroup names in the left folder pane based on the amount of space available. E.g. I see s.gnome-interest for sun.gnome-interest s.a.os for sun.ambassador.os In the example above I might see T.host1 for "Terminal host1" T.host2 for "Terminal host2" Or if I were also running other T windows then I might see Te.host1 for "Terminal host1" Te.host2 for "Terminal host2" Tr.java for "Truss java" Tr.gcc for "Truss gcc"
Sounds like a good idea. Adding bugsquad keyword.
See also bug 155868.
I'm not sure Calum, in our 'document titles are window titles' world it seems like this method won't provide that much improvement over just ellipsizing the text. Take for example my epiphany web browser title, which right now reads: "Bug 99604 - Better abbreviation of titles when space is tight" In the task bar it is simply cut off at the word abbreviation, which seems fine. Shortening this to something like "B.99604-B.a.o.t.w.s.i.t" doesn't actually help; but I'm probably being over critical in my example. ;-) My wonder is that assuming applications use only the document title for the window title, which I believe they should, is there a part of the title more or less important than the other parts of it? My feeling is that this isn't true. However, when evil applications such as evolution fails to conform to this, shortening their application name to be "E-Mail.INBOX" instead of "Evolution - Mail INBOX" does seem to make sense. (it even spells e-mail!) I wonder if it's currently programatically possible do this on all application or if libwnck would need specific meta-data about the titles to determine this.
One thing that'd be nice would be if common prefixes would be suppressed (for example, I have a lot of terminals which all have titles starting: anthony@bohr:/home/anthony and that generally takes up the entire width of the tasklist button :-(
The title is usually composed of two parts--the application title and the document/task title. The document/task title is the most important because the application can generally be ascertained by the icon. Whatever the case may be, since the title is cropped from the right, the least important information should be placed there. This format should be part of the HIG.
Okay, after thinking a bit about this issue, I'd tend to agree with Bryan. There's not much we can programmatically do since we don't know what we can expect from the window titles. Also, we have a tooltip on each button, which should help when the names are ellipsized.
"There's not much we can programmatically do since we don't know what we can expect from the window titles." Oh, but you can, and the algorithm is fairly simple. Let's say we have four windows open: 1. "The Hound of the Baskervilles" - Chapter 1 2. "The Hound of the Baskervilles" - Chapter 2 3. Calculator 4. "The Hound of the Baskervilles" - Table of Contents This might appear in the window list as: ["The Hound of...]["The Hound of...][Calculator ]["The Hound of...] Not particularly useful. First, determine which of these windows have exactly the same visible characters: 1, 2, and 4. Then, determine which of those three have actual different titles: all of them. Then, starting at the beginning, remove tokens from each title in the group, dropping each title from the process as its visible portion becomes unique. By "token" I mean a string of non-alphanumeric or whitespace characters, or a string of alphanumeric characters plus its trailing punctuation and/or trailing whitespace if any. If you actually redrew the window list after each iteration (which of course you wouldn't), you'd see something like this: ["The Hound of...]["The Hound of...][Calculator ]["The Hound of...] [The Hound of ...][The Hound of ...][Calculator ][The Hound of ...] [Hound of the ...][Hound of the ...][Calculator ][Hound of the ...] [of the Basker...][of the Basker...][Calculator ][of the Basker...] [the Baskervil...][the Baskervil...][Calculator ][the Baskervil...] [Baskervilles ...][Baskervilles ...][Calculator ][Baskervilles ...] [- Chapter 1 ][- Chapter 2 ][Calculator ][- Table of Co...] Voilà! Unique and useful labels. (There may be two or more such groups of similar titles in the window list, so here's where you loop back and look again for different-but-visibly-identical titles, stopping only once you've run out of things to do.) As a Gnome developer you may have a personal incentive to fix this: if you have a dozen Bugzilla bug reports open, this will make their buttons in the window list show the actual bug number, instead of just showing "Bug..." a dozen times.
Pretty smart, I like it.
I agreed with Vuntz when he marked it WONTFIX, but I do like the new idea suggested by mpt (hadn't ever thought of anything like that before) and think it's worth a shot. And if both mpt and calum agree on this new idea, we should probably try it out. :-) So I'll reopen. However... (In reply to comment #7) > As a Gnome developer you may have a personal incentive to fix this: if you have > a dozen Bugzilla bug reports open, this will make their buttons in the window > list show the actual bug number, instead of just showing "Bug..." a dozen > times. Um, tabs? There'd only ever be a couple at most; it's firefox that would need to be fixed for the bugzilla use case. ;-)
I've reported bug 549729 on implementing this algorithm in GTK for more widespread use.
-- 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/21.