Proposal: Inharitance for Desktop Entry Spec

[cobaco (aka Bart Cornelis)]

On Thursday 17 April 2008, Vincent Untz wrote:
> Le jeudi 17 avril 2008, à 08:48 +0200, cobaco (aka Bart Cornelis) a 
écrit :
> > On Thursday 17 April 2008, 洪任諭 wrote:
> > > I have a proposal for the current "Desktop Entry Spec".
> > > Let desktop entry files derive from another desktop file.
> > > Desktop entry files get widely used today, but there exists some
> > > serious problems.
> > >
> > > If the user want to override an system-wide dekstop_id, normally,
> > > he/she should create a desktop entry files with the same name, and
> > > put it in $XDG_DATA_HOME. Currently, the best way to do this is to
> > > copy the system-wide desktop entry file to ~/.local/applications, and
> > > do the modification you want. At first this looks good and
> > > reasonable. It, however, is problematic. Imagine the following
> > > senario:
> > >
> > > 1. The program has a new release, and it installs a new desktop file
> > > with different Exec or TryExec keys. Apparantly, the user-created one
> > > is broken.
> > >
> > > 2. Having to copy the system-wide desktop files to make a custom one
> > > is not only quite dirty, but also make unnecessary duplicated files.
> > > For desktop files containing a lot of translation (like the desktop
> > > files owned by gnome), this does matters.
> > >
> > > 3. If the new releases of programs have new names, or change the
> > > description (comment) in their new system-wide desktop file installed
> > > in /usr/share/applications, these changes will never be reflected in
> > > the user custom one.
> > >
> > > 4. The user custom one, will lack some translation. When the users
> > > login to desktop in another language, they can only get English names
> > > even if new translation is already available in the system-wide one
> > > after system update. Any change to the system-wide desktop entry
> > > files will never be reflected in the user custom one.
> > >
> > > So, current approach is some what dirty, problematic, and hard to
> > > implement and maintain.
> >
> > second that, I've run into this problem also
>
> Yeah, I've been hit by this in the past too. I believe it was already
> (at least partly) discussed, when talking about the autostart
> specification. Can't find the thread, though.
>
> > > Here is a proposal trying to fix these problems by adding a new key
> > > named "Inherit".
> >
> > I don't think we actually need a new key, we already have the base-dir
> > spec to determine which .desktop file will take precedence.
>
> Agree that if done, it should be done with the base-dir spec.
>
> However, there's a big issue: if I put totem.desktop in $XDG_DATA_HOME
> just to change the name (so I just put a Name key there), what happens
> if totem is deinstalled? How can I know totem.desktop should be ignored?

simple: 
- if the resulting combined totem.desktop file misses one or more of the 
required fields (Type and Name) it should not be displayed.
- if the combined file has all the required fields it should be displayed 
unless there's a 'TryExec=' that results in exclusion
--
Cheers, cobaco (aka Bart Cornelis)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20080417/44d7cd35/attachment.pgp