GNOME Bugzilla – Bug 426196
Creating launcher inconsistency
Last modified: 2020-11-06 20:23:44 UTC
When creating launchers on my menu via alacarte I am presented with Icon, Name, Comment and Command. When editing launchers in alacate I can only change the Icon, Name and Comment. Also the Description attribute of Launchers is missing, which means I must manually edit the files, or use the nautilus launcher properties to add a description field into the .desktop file for the item to appear with a description in SLAB main menu. Other information: This is also related to #426195 which concerns a related inconsistency in .desktop editing in Nautilus.
gnome-panel is responsible for the dialog alacarte displays when you edit something.
*** Bug 426195 has been marked as a duplicate of this bug. ***
This is an important feature for the SLAB main menu being introduced into GNOME. I have spend about an hour today putting together a patch. This patch essentially adds the field Description in the same way Comments are manipulated. I tested the patch and it correctly creates the description field in the .desktop files.
Created attachment 86781 [details] [review] proposed patch to add description field .desktop files As nautilus, alacarte and gnome-panel seem to use the same method for creating and editing .desktop files, I have made the changes to gnome-panel. Needs translating.
Description??? It's not in the desktop entry specification. Where is it defined?
http://bugzilla.gnome.org/show_bug.cgi?id=432096 Oops, I looked at the nautilus dialog but I didn't even check the file... I'll modify the patch, looks like it should be using GenericName
Created attachment 87595 [details] [review] Modified patch, GenericName not Description This should be more like it ;)
Hrm. Basically, the issue here is that we're not using GenericName anywhere in GNOME. It doesn't make sense to edit it if we don't use it. So before accepting this patch, we'd need to make use of it. It makes sense. See http://mail.gnome.org/archives/desktop-devel-list/2003-October/msg00590.html for discussion about this. Would you be interested in pushing for a change in all the .desktop files of GNOME?
I suppose the question is how many desktop files require a change. I'd be happy to follow up on the subject, as this .desktop option is used by slab main menu I think the patch should go through, simply to expose that functionality to developers and users. I don't mind doing a % of the work load to add the generic names to the icons. However I would rather stay out of the discussion as to how this should be represented to the user. I think once the functionality exists and the data exists then we have metadata for the indexes and that is more important than how we can display all of this information in a single menu item.
Well, the thing is, we'll probably need to come with a solution on how to use this to convinve maintainers that they should commit a patch for GenericName :-) I suggest you contact the GNOME Goals people by sending a mail to the gnome-love mailing list. This could make a good GNOME Goal. Thanks!
any chance we can get my patch reviewed? I'd like to see this bug move as we're stuck in a chicken and egg situation with GenericName
Seems like this bug got stuck. Vincent pointed out that GenericName is not being used in GNOME. It is used in the GnomeMainMenu for example. And I don't know about other desktops, but having a spec which includes GenericName suggests that some other spec compliant desktop uses it. The whole point is desktop interoperability, so what GNOME does and what not is not the only question involved here. The problem is that... a) The spec seems to imply a combined use of Name and GenericName b) GNOME apps mostly use Name+GenericName or only GenericName as Name c) The panel and Nautilus only use Name, while GnomeMainMenu uses both Name and Generic name together The d-d-l thread from 2003 goes back and forth but does not seem to reach a consensus, leaving GNOME in the messy state it still is today, 5 years later. The main problem is this post from Havoc¹. Basicly, he says the spec (which he wrote) is wrong. But the spec has not been changed. Also, Havoc says: --- The UI guidelines (and I agree they are correct) say the menus should contain "Mozilla Web Browser" or "Totem Media Player" --- I think there is at least an agreement to not use the Name for core applications. Totem itself is the best example, the desktop file only uses "Movie Player" today, which seems to be the right thing. So, there are two possible ways we can go from here: a) Set Name and GenericName correctly in desktop files, as advertised by the spec. Firefox would be Name=Firefox and GenericName=Web Browser. For core modules, we would set the Name to a GenericName value, so Epiphany would only have Name=Web Browser and no GenericName at all. This small change is not really spec-compliant but we can probably live with it easily, as it is whatwe want for GNOME and other desktops probably don't use GNOME code applications. This would however need code changes in the Panel and Nautilus. I'm not sure about i18n issues, but the thread did not really list anything, other than "maybe". This is no problem until some of the translators stands up and actually shows a case where concatenating Name and GenericName does not work. b) Only use Name AND get rid of GenericName for *all* desktop files. For example, use Name="Web Browser" for Epiphany and Name="Firefox Web Browser" for Firefox. This is what some apps seem to do already, but it would mean changing the spec (or knowingly breaking spec and possibly cross-desktop compliance). On the bright side, no code changes for Panel and Nautilus, but only for GnomeMainMenu Option a) seems to be the saner way IMHO. Both ways need code changes somewhere and both need a lot of desktop file changes. Way a) would ensure we don't screw other desktops that maybe rely on GenericName and also makes it possible for other desktop's apps to show correctly in GNOME menus. If only core-GNOME is interesting, either way is fine as long as we finally agree on one solution here so that we can fix all the parts involved. But don't forget that there are many other 3rd party GTK apps that many GNOME users use, regardless of them not being core apps, where devolopers probably don't want to break spec compliance. Those apps would not show up in GNOME menus as we would want them to show up. [1] http://mail.gnome.org/archives/desktop-devel-list/2003-October/msg00592.html
Micheal its great to see someone else taking an interest in this bug, I think we need to get this patch reviewed and inserted ASAP in order to fill the consistency gap between gnome-panel and nautilus' launcher editor. Once the patch is applied then it will be possible for people to modify the desktop entries from a more sensible place in the desktop (alacarte & panel) to include the generic name tag. For me it seems that the blockage on this appears to be that nobody has reviewed the patch in order to get it included so we can then approach a decision on the application of the GenericName tag, if we want to use it. I personally think that 'a' is the best approach, but haven't been able to drum up more interest in getting this _minor_ patch reviewed and committed in order to move forward on it.
Thing is, if GNOME wants to do b), this patch would be obsolete as GenericName should be removed from all desktop files and there should certainly be no way to edit it in the GUIs. We really need an agreement to go for a) and face/resolve the i18n issues we (probably, not even certainly) face. IMHO Vincent or some other Panel maintainer should post a mail to the translators mailing list, explaining the possible change and asking for which language this could cause problems. If noone speaks up we could push your patch in as the first thing for 2.23 and start fixing .desktop files and work on the presentation of Name + GenericName in the Panel menu etc. Don't let the old d-d-l posts impress you. Sure, many of the "superstars" commented back then, but some of them are not even a part of GNOME anymore and the desktop has taken some steps since then. Once the direction is clear, solving this 5 years old problem should be no problem until 2.24. Let's just do it.
Well there's an easy way to fix the i18n problem, if we set it up so you get <bold name> <generic name> surely that would allow adequate separation to prevent language difficulties.
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.