[desktop entry spec] new FullName key

[David Faure]

On Tuesday 21 July 2009, Frederic Peters wrote:
> Hello all,
> 
> In preparation for GNOME Shell a question has been raised about the
> way we display the name of the applications; the situation at the
> moment in the GNOME Panel is simply to display the Name but it would
> be nice to go further, using the GenericName, for example to have menu
> items set as:
>   <b>D-Feet</b>
>   D-Bus Debugger
> 
> It would already be possible if Name and GenericName were used in a
> consistent way, but as we put whatever we wanted to be displayed in
> the menu in Name, we find ourselves with the Name embedding the
> GenericName, such as:
>   Name=Brasero Disc Burner
>   GenericName=Disc Burner

Bad .desktop file, bad ;)

> A first proposal was to fix our desktop files (in our official suites
> there are only three occurences of this problem) but the issue is 
> broader (looking at other popular GTK+/GNOME applications, it appears
> at least in Banshee, F-Spot, Gnumeric, Liferea, Rhythmbox, etc.)

Bad desktop _files_ then.

Indeed evince.desktop 2.26 says
  Name=Document Viewer
  GenericName=Document Viewer
Just fix the file, the Name field should not be generic.

> and it is not certain all of them can be fixed.

Why? There's a limit on the number of files your text editor can open? :-P

> Moreover with just Name and GenericName we could end up with having to
> concatenate both keys, which would raise unknown translation issues.

Simple concatenation is bad, I agree. We use "GenericName (Name)" by default
in KDE, have been doing so for many many years and I don't remember
a single complaint from translators about it.
More precisely, the default is  "GenericName (Name)", but users can also configure
another solution among those four possibilities:
- "Name"
- "GenericName"
- "Name (GenericName)"
- "Name - GenericName"
You don't have to support all these, of course. But the point is that the Name/GenericName
separation is useful so that the menu (implementor, or user) can choose whether to
show short or long descriptions for each entry.

> Therefore comes this proposal to add a new FullName key, which would
> typically be a combination of Name and GenericName, but could also be
> a variant, for example:
>   Name=Glade
>   GenericName=User Interface Designer
>   FullName=Glade Interface Designer

How many ways to we need to call an app? Isn't 5 enough? (2 in the file, 5 for the user
using the above combinations).

> How does it sound ?

It sounds like adding a workaround in a perfectly fine spec, just to accomodate
broken desktop files. How about fixing the desktop files instead? We have a fine
spec, and it's working well, there's no good reason to add yet another key.
I don't understand why editing desktop files to use Name/GenericName properly
is deemed impossible, while editing them to add a new key is no problem; it's
the same amount of files to edit in the first place. And in a way that doesn't
break other desktop environments (currently our menu code has lots
of hacks to accomodate those broken .desktop files you describe... like
"the user selected to see name+genericname, but the broken desktop file
makes the genericname contain the name already so skip the name"... urgh).
There's an easy solution to that problem and to your problem: fixing the desktop files.

-- 
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).