How to deal with .desktop renames (recommended for dbus activation) and users configs (launchers, mimetype handlers, ...)

[Ryan Lortie]

hi,

On Wed, Nov 26, 2014, at 05:00, Sebastien Bacher wrote:
> Should applications keep shipping a .desktop with the old name and
> NoDisplay or something around those line? Should a new "alias" kind of
> key be added that would allow the new .desktop to declare claiming other
> names as well (would require updating parsers and it might make handling
> of conflicts non trivial)

I agree that this is a problem and I'm sorry that we didn't address it
before now.

It's my opinion that we want to at least add an Aliases= key to desktop
files.

My reason for thinking this is because it's the least-effort thing for
application authors to do (nobody would object to adding a single line
to a file).  It also puts the metadata about these renames where it
belongs: upstream.

Meanwhile, any other thing that we want to do can be based on this.

There are a few possibilities:

One is that we could attempt to 'migrate' the old data that we find in
the user's session.  There are hook mechanisms in place for this sort of
stuff already (Ubuntu features 'session-migration').  This would involve
at least updating the user's mime associations to the new names, but
applications (mostly launchers) would probably also want to provide
hooks for updating their databases as well.

Another possibility is to create a copy of the original desktop file
marked NoDisplay=true, with an additional key like
X-FreeDesktop-IsAlias=true or such.  update-desktop-database would use
this extra key to garbage-collect the file once the original app is
uninstalled (or once it stops advertising the Alias=).  We might also
consider adding a new public key like CanonicalName= that points back to
the file that this is an alias for.  That would give applications a
mechanism by which they could update their settings.

Another possibility is to collect all of the aliases into a cache
(similar to the mimeapps one) and teach the various desktop file parser
implementations about this.

A final possibility is to implement the idea with the NoDisplay=true
copy of the desktop file at package build time -- there could be a dpkg
(etc.) hook for creating a second copy of the desktop file that gets
installed under the old name as part of the package.


I don't have a strong opinion on which is the best way forward here and
I welcome the thoughts of others.  One thing I'm quite sure of, though,
is that any solution is going to begin with an "Aliases=" line in the
desktop file installed by applications.

Cheers