Yeah basically it should never fall back to the window title.  It may as well say "Something's fucked" :)

(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.

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

(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.

(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?

(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, ...)

Ah yes, this is actually a minefield build I run atm...

In this case, would renaming the .desktop file to "minefield.desktop" work?

(In reply to comment #7)
> In this case, would renaming the .desktop file to "minefield.desktop" work?
yes

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...

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)

*** Bug 598461 has been marked as a duplicate of this bug. ***

*** Bug 601835 has been marked as a duplicate of this bug. ***

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.

(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?

> 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

Created attachment 173893 [details] [review]
never fall back to the window title as application name

Did you intend to use _() there since you included i18n.h?

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.

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?)

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

Created attachment 173895 [details] [review]
never fall back to the window title as application name

use WM_CLASS

Review of attachment 173895 [details] [review]:

This looks good, thanks!

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