After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 624935 - Application title in panel
Application title in panel
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
2.31.x
Other Linux
: Urgent normal
: ---
Assigned To: Colin Walters
gnome-shell-maint
: 598461 601835 (view as bug list)
Depends on:
Blocks: 620464
 
 
Reported: 2010-07-21 15:19 UTC by Michael Monreal
Modified: 2010-12-08 19:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot (17.74 KB, image/png)
2010-07-21 15:19 UTC, Michael Monreal
  Details
try find desktop file based on executable name (3.48 KB, patch)
2010-07-21 17:25 UTC, Maxim Ermilov
none Details | Review
try find desktop file based on executable name (3.43 KB, patch)
2010-09-28 16:39 UTC, Maxim Ermilov
needs-work Details | Review
never fall back to the window title as application name (1.20 KB, patch)
2010-11-05 16:27 UTC, Maxim Ermilov
needs-work Details | Review
never fall back to the window title as application name (1.28 KB, patch)
2010-11-05 16:49 UTC, Maxim Ermilov
committed Details | Review

Description Michael Monreal 2010-07-21 15:19:39 UTC
Created attachment 166294 [details]
Screenshot

The application string on the top panel is often wrong. For Firefox, it displays the title of the current tab but after switching tabs, it still displays the old tab's title until you switch to another app and back to Firefox again.
Comment 1 William Jon McCann 2010-07-21 15:28:56 UTC
Yeah basically it should never fall back to the window title.  It may as well say "Something's fucked" :)
Comment 2 Maxim Ermilov 2010-07-21 15:58:40 UTC
(In reply to comment #1)
> Yeah basically it should never fall back to the window title.  It may as well
> say "Something's fucked" :)

May be we should display executable name?
We already have pid, so It will be easy to get it.
Comment 3 Maxim Ermilov 2010-07-21 17:25:24 UTC
Created attachment 166311 [details] [review]
try find desktop file based on executable name

if we don't have desktop file, use executable name as application name
Comment 4 Florian Müllner 2010-07-21 17:29:08 UTC
(In reply to comment #3)
> Created an attachment (id=166311) [details] [review]
> try find desktop file based on executable name

Hmm - I don't like drawing in another dependency just to make broken apps look less bad.
Comment 5 Michael Monreal 2010-07-21 17:35:39 UTC
(In reply to comment #4)
> ... just to make broken apps look less bad.

Could you sum up what exactly is broken in this case or how to fix it?

In the case of Firefox, the executable is called "firefox-bin" and commonly started by a script called "firefox". The launcher is called "mozilla-firefox.desktop", at least on Fedora. Would we need to rename the launcher to firefox-bin.desktop?
Comment 6 Florian Müllner 2010-07-21 18:44:30 UTC
(In reply to comment #5)
> Could you sum up what exactly is broken in this case or how to fix it?

We fail to make the correct association between a window and a desktop file. The safest fix is to have the window's WM_CLASS match the desktop file name (without extension). For all the pesky details, see http://live.gnome.org/GnomeShell/ApplicationBased ...

 
> In the case of Firefox, the executable is called "firefox-bin" and commonly
> started by a script called "firefox". The launcher is called
> "mozilla-firefox.desktop", at least on Fedora. Would we need to rename the
> launcher to firefox-bin.desktop?

We do actually have a work-around to recognize some vendor prefixes (as "mozilla"), so mozilla-firefox.desktop is fine if Firefox is used as WM_CLASS - the problem with Firefox is that the WM_CLASS is often set to something completely unintuitive (minefield, shiretoko, ...)
Comment 7 Michael Monreal 2010-07-21 18:51:44 UTC
Ah yes, this is actually a minefield build I run atm...

In this case, would renaming the .desktop file to "minefield.desktop" work?
Comment 8 Maxim Ermilov 2010-07-21 19:47:36 UTC
(In reply to comment #7)
> In this case, would renaming the .desktop file to "minefield.desktop" work?
yes
Comment 9 Michael Monreal 2010-07-22 15:31:17 UTC
Ok, tested and it works - kind of. As soon as the download manager pops up, the title (in the app "button" as well as the app well) is replaced by the title of the download manager...
Comment 10 Maxim Ermilov 2010-09-28 16:39:37 UTC
Created attachment 171280 [details] [review]
try find desktop file based on executable name

never fall back to the window title

(depend on patches from Bug 623688)
Comment 11 William Jon McCann 2010-10-02 21:13:06 UTC
*** Bug 598461 has been marked as a duplicate of this bug. ***
Comment 12 William Jon McCann 2010-10-02 21:14:01 UTC
*** Bug 601835 has been marked as a duplicate of this bug. ***
Comment 13 Colin Walters 2010-10-06 21:20:08 UTC
Review of attachment 171280 [details] [review]:

::: src/shell-app.c
@@ +13,2 @@
 #include <string.h>
+#include <glibtop/procargs.h>

Talked with Owen about this; what do you think about using the WM_CLASS instead of the binary?  Would be a lot easier, and avoids a dependency on libgtop.

@@ +666,3 @@
+
+      app = shell_app_system_lookup_heuristic_basename (shell_app_system_get_default (), t);
+

I don't like doing this here.  The _new_for_window should be the explicit fallback path if we're sure we can't match.

So if we were to do executable name matching, it would live in shell-window-tracker.c:get_app_for_window, not _new_for_window.
Comment 14 Maxim Ermilov 2010-10-07 02:57:15 UTC
(In reply to comment #13)
> what do you think about using the WM_CLASS instead of the binary?
I think, If it set we should use it.
What should we do in case WM_CLASS == NULL? (e.g. most of java applications)

In my opinion, It is better use binary name (may be with special handling for python, java ...).

> avoids a dependency on libgtop.
What is wrong with it?
Comment 15 Maxim Ermilov 2010-11-04 18:43:29 UTC
> what do you think about using the WM_CLASS instead of the binary?
After some testing, I think It is not a good idea.
Emamples of WM_CLASS
freemind-main-FreeMind
net-sourceforge-jnlp-runtime-Boot

There is two possible solution:
1. show binary name (and depend on libgtop)
2. show 'Unknown application'
   https://bugzilla.gnome.org/show_bug.cgi?id=624935#c1
Comment 16 Maxim Ermilov 2010-11-05 16:27:21 UTC
Created attachment 173893 [details] [review]
never fall back to the window title as application name
Comment 17 William Jon McCann 2010-11-05 16:30:33 UTC
Did you intend to use _() there since you included i18n.h?
Comment 18 Owen Taylor 2010-11-05 16:39:37 UTC
Review of attachment 173893 [details] [review]:

As discussed on IRC, this approach is not workable. My preference is to use the WM_CLASS value. I'm not completely opposed to libgtop, but it seems like a lot of work for minimal improvement.
Comment 19 Florian Müllner 2010-11-05 16:42:02 UTC
Review of attachment 173893 [details] [review]:

I assume that the string is intended to be translated:

::: src/shell-app-system.c
@@ +9,3 @@
 #include <gio/gdesktopappinfo.h>
 #include <gtk/gtk.h>
+#include <glib/gi18n.h>

This should be glib/gi18n-lib.h, or else the translation is expected in the mutter domain.

@@ +1005,3 @@
       return g_key_file_get_locale_string (info->keyfile, DESKTOP_ENTRY_GROUP, "Name", NULL, NULL);
     case SHELL_APP_INFO_TYPE_WINDOW:
+      return g_strdup ("Unknown");

This will either need a translator comment or a more descriptive string ("Unknown Application" maybe?)
Comment 20 Owen Taylor 2010-11-05 16:42:28 UTC
I guess I should be explicit about why the "Unknown" or "Unknown application" approach is not workable:

 - Users will encounter apps that aren't properly identified
 - Non-advanced users will have no way of working around that situation
 - So user's must be able to have minimal usability in that case
 - "Unknown" makes such windows not distinguishable in alt-Tab
Comment 21 Maxim Ermilov 2010-11-05 16:49:37 UTC
Created attachment 173895 [details] [review]
never fall back to the window title as application name

use WM_CLASS
Comment 22 Colin Walters 2010-11-09 16:55:33 UTC
Review of attachment 173895 [details] [review]:

This looks good, thanks!
Comment 23 Colin Walters 2010-12-08 19:05:42 UTC
commit 6df21fd5ff86702a9ccb2cb9cbccb60c0457b620
Author: Maxim Ermilov <zaspire@rambler.ru>
Date:   Fri Nov 5 19:47:50 2010 +0300

    never fall back to the window title as application name
    
    https://bugzilla.gnome.org/show_bug.cgi?id=624935