structure of desktop file directories

[David Faure]

On Friday 04 October 2013 11:20:27 Ryan Lortie wrote:
> fwiw, I actually plan to modify update-desktop-database to generate the
> cache, so applications that are already using that during install will
> automatically regenerate the cache.

Sounds good. 
 
> I considered another point, also: the cache files (the new index, plus
> the mimeinfo cache) are really a different kind of data from the
> mimeapps.list (which is configuration).

Yes, but it refers to the desktop files from that very directory, so it kind 
of goes together with it.

.desktop files in ~/.local/share are also kind of "configuration", since they 
are typically the result of the user modifying the Exec line for a given 
application...

> If the update-desktop-database tool updates both of the cache files and
> ensures that the timestamps are sane at the point that it does so, then
> there is no problem leaving those files where they are.

Yep.

> mimeapps.list is a different story, though, since this gets written to
> (at least in ~/.local/share) whenever the user changes their
> associations 

Yes.

> (or even runs an app, since GIO maintains a MRU list here),

Oh. So manually running a given image viewer makes it the default image 
viewer? That's kind of "the user changing their associations" then, too.

> and we don't want to have to regenerate the cache in that case.

Right, the cache doesn't include the settings from mimeapps.list, I assume?

In KDE, it does -- but that's kind of annoying, having to regenerate the cache 
when changing associations (the user is presented with a progress dialog...)
On the other hand, it obviously makes things even faster when using the cache.

> It's not exactly clear to me why mimeapps.list is in the applications/
> directory at all.  This is configuration data and maybe the real
> solution here is to consider moving it to ~/.config.  The only weird
> part about this is that there seems to be some layering system whereby
> the mimeapps.list files from each of the XDG directories are merged (but
> I notice that I don't have this file in my system directories, so I'm
> not sure what the point is)...

The point is that the base dir spec supports more than "local and global". You 
can set $XDG_DATA_DIRS to contain 2 directories, which results in three 
overall (when adding XDG_DATA_HOME).

The typical use case is that the intermediate layer contains apps and settings 
for a whole group of users, while another group of users uses another value 
for the intermediate directory in XDG_DATA_DIRS.

Distros (e.g. kubuntu) use this to provide distro-specific defaults without 
messing up with the files in /usr (which can they remain "as they are 
upstream") -- making the whole distro-settings things easy to turn off, too.

As a developer I also often have two layers in XDG_DATA_DIRS, but ok, not with 
a mimeapps.list in the intermediate layer, typically. 

Anyhow, this doesn't prevent moving mimeapps.list to config dirs, actually. 
The weird corner case with 3 data dirs and 2 config dirs still works, since 
the mimeapps.list files simply contain .desktop file names, which resolve to 
"most local" anyway, for the current user.

We defined mimeapps.list with Alex Larsson, so we need his OK for moving it 
(plus a way to handle the migration, like your symlink idea, provided that 
apps don't replace the symlink with a real file, which would be disastrous).

> I think we should definitely put an agenda point for the next
> freedesktop Summit to get this mess sorted out.  Until then (unless we
> can find an agreement on the list for substantial changes), I think I
> want to put my original plans on hold, because they may end up being
> useless.

Let's see if my reply helps moving things along :-)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5