GNOME Bugzilla – Bug 608125
Long window title will overlap with time at top of screen.
Last modified: 2010-02-23 16:52:29 UTC
Created attachment 152291 [details] screenshot Screenshot shows it best. Long window title will overlap time at top of screen, meaning I can't see the time. Also, this title doesn't change unless application changes e.g. changing tabs in firefox, but I probably need to open another bug for that one.
(In reply to comment #0) > Screenshot shows it best. > Long window title will overlap time at top of screen, meaning I can't see the > time. This is a real bug, but note that the window title isn't supposed to be showing in the panel, but rather the application name; in your case, it should either show "Minefield" or "Firefox". The problem is that gnome-shell cannot locate a desktop file for minefield, so it falls back to the window title. (Note that the name of the desktop file has to match the wm class (minefield); it also must be in a location which is monitored by gnome-shell (e.g. $XDG_DATA_DIR/share/applications) > Also, this title doesn't change unless application changes e.g. changing tabs > in firefox, but I probably need to open another bug for that one. Nope, you don't need to: it's bug 605536.
Actually some of them do have a desktop file, but it still not works for all applications. xprop | grep "WM_CLASS(STRING)" gives the wm class of the window. If the desktop file has a name according this wm class it works for many applications, but unfortunately not for all. But at the moment I cannot see any difference between them. But, it seems that if the application was manually added to the application menu, they get a desktop file with the name you gave to the entry instead of the wm class. For example if I have manually added Firefox to the application menu and named it Browser, you get a Browser.desktop instead of firefox.desktop. Therefore it does not work. Is it possible to look for desktop files which match to the name of the entry too? Such that if I'm opening Browser it looks for Browser.desktop and firefox.desktop.
I played a while with the desktop files and finally found out that they need to be lowercase... so a wm class of tvbrowser-TVBrowser needs a tvbrowser-tvbrowser.desktop to work correctly. But I could not figure out what the StartupWMClass in the desktop file is used to, because setting the wm class there seems not to have an effect. So now it works for the most important applications, except nautilus which still does not find it's desktop file for some reasons. Is there a way to handle applications which do not provide a useful wm class? Because some applications seems to use a general wm class (ie. sun-awt-X11-XDialogPeer) instead of something specific.
*** Bug 610292 has been marked as a duplicate of this bug. ***
*** Bug 610841 has been marked as a duplicate of this bug. ***
meh. actually, "doesn't get truncated" is bug 592640 and "doesn't get updated" is bug 605536 *** This bug has been marked as a duplicate of bug 592640 ***