GNOME Bugzilla – Bug 501087
Show GenericName if different from Name
Last modified: 2020-11-06 20:25:38 UTC
According to http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html applications should put their proper name in the Name field in the desktop file, and a general description in the GenericName field. In GNOME, most applications include the generic name in the Name field, and often the GenericName field is not used at all. This way, the GNOME HIG desktop item name spec (http://library.gnome.org/devel/hig-book/stable/desktop-application-menu.html.en#menu-item-names) is implemented. However, non-GNOME applications (even GTK+ applications like The Gimp or Transmission (see http://transmission.m0k.org/trac/changeset/3342)), stricly follow the freedesktop.org spec and only put the generic name in the GenericName field. This way, no generic name is invisible when using GNOME menus, which is against the GNOME HIG. A solution would be that the GNOME menus also show the GenericName field on the condition that the GenericName field is not (case insensitive) part of the Name field. That way, for GNOME applicatons nothing will change, but for applications strictly following the freedesktop.org spec, the generic name will also be shown, like is the case for GNOME applications.
See the Third Task in this usability test where exactly the example I gave above, causes user confusion: http://contentconsumer.wordpress.com/2008/04/27/is-ubuntu-useable-enough-for-my-girlfriend/ transmission.desktop has Name=Transmission GenericName=BitTorrent Client Comment=Transfer files via Peer to Peer It should be easy to detect that no part of the GenericName is included in the Name field, so in that case gnome-panel should show both: Transmission Bittorrent Client. You can't blame Transmission for this problem, it is doing exactly what is defined in the the freedesktop.org SPEC.
It's been discussed at length. We can't dynamically create a new string based on the strings in Name and GenericName. Whatever we do, it will fail for some languages. We need to fix the specification here.
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=21465
> We can't dynamically create a new string based on the strings in Name and > GenericName. Whatever we do, it will fail for some languages. One thing that I've proposed in the past, short of 'fixing' the spec (which runs into some opposition), is to use a translatable template for combining the Name and GenericName. It puts your user experience a bit at the mercy of the translators, but it allows translators to e.g. fix up RTL/LTR issues, or pick a more appropriate separator for their language: g_strdup_printf (_("%s - %s"), name, generic_name);
Created attachment 139763 [details] [review] patch to append generic name when it differs Maybe something like this? Though a hyphenation point U+2027 "‧" may also be an option.
It certainly needs a translator comment, but looks fine to me otherwise.
Created attachment 139793 [details] [review] patch Use bullet hyphen and add translator comment.
This patch depends on *all* desktop files that exist now being changed, otherwise we'll get e.g. "Pidgin Internet Messenger Internet Messenger" which is a pretty awful failure case. Which is why I suggest that we add a new key, like AppName/ShortName.
Or another possible option here is to try to detect this case and work around it; i.e. if the Name field includes GenericName, just display Name. I think KDE has a hack like this.
Colin, if you actually look at the patch, it already tries to do that. Just maybe not hard enough. We should probably use the english strings, and strstr instead of strcmp
I did look at the patch, and noticed pidgin as an example of something that would break. The Name=GenericName case is another common (but different) case, and yes the patch does handle that.
I'm updating this patch now.
Created attachment 139812 [details] [review] Bug 501087 - Show Name - GenericName in panel In accordance with the desire to fix .desktop files to use Name=Name instead of Name=Name GenericName, update the panel to show GenericName. One issue here is backwards compatibility; if a .desktop file has Name=Foo Browser GenericName=Foo Browser then we definitely don't want to show Foo App - Foo App. Another case is Name=Foo Browser Generic Name=Browser Avoid both of these by only showing name if it contains the GenericName in the untranslated English.
This patch depends on the gnome-menus patch in bug 590670. On my Fedora 11 install with unmodified .desktop files, it's generally OK. The biggest ugly is Evolution Mail and Calendar - Groupware Client. But Evolution most often comes with the desktop (and the GenericName in this case should just be deleted anyways).
One thing I do want to open for discussion though is using two lines, i.e.: Name GenericName (and provide the ability to reverse them with a GConf key).
While the two-line approach is probably an interesting one to pursue for the shell, I think it will not work as well as a short-term fix for the panel, for a number of reasons: 1) Our menus are already prone to running out of vertical space. Blowing each item up by a factor of 2 is not going to help that... 2) This will be sucky for apps that don't have a generic name. You either end up with varying-height items, or with odd gaps 3) For making this work well, you probably need larger app icons that we currently have, to allow the icon to stretch over both lines
Ok, then we probably need your idea from comment #4. Also, I'm going to dup this bug for gio so we figure out what to do for g_app_get_name.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.