No subject

mime.cache + desktop files when calling udpate-desktop-database. I'm
certainly wrong though, don't take it as Bible :)
So yes, it's really a cache and then gio in glib call it.

So, ok, no need to unify this cache file, we just have to agree on the
opening rules.

>
>> Hum, that's was not the intention. The parsing is made twice (in gio
>> at least): one for mimeapps and one for mimeinfo.cache (the "global
>> mimeapps.list").
>
> Does gio ignore mimeapps.list files in other directories listed in XDG_DA=
TA_HOME
> then? =A0(e.g. /usr/share/applications/mimeapps.list)
> That would be a bug IMHO...
I'm not sure about mimeapps.list that can be reached from there,
appart from the ~/.local/...
I will have to test it and take a look in the code. mimeapps.list is
not a cache file but a static one that administrators and users can
edit to overwrite defaults, am I write with that definition? (I
understood it in this way in the spec)

>
>> I was thinking about using Category only for the latter file.
>> The other is platform independent and only rely on user's
>> choices, whatever the environment is used (we can use also QT/GTK
>> Category depending on the environment).
>> and that's right that's not a very good option if we set up group of
>> users by adding dirs in XDG_DATA_DIRS, I wasn't aware of this use
>> case.
>
> And it mixes up two things, no? Adjusting categories for this purpose
> would also have an effect on the vfolder menu which uses the categories
> in the first place...

Right, but I don't see other solution at the moment (see below for my
proposition summary)

>> The other possibility is to copy locally desktop files changing their
>> priority and using this one. If I understood it right, that was how
>> KDE3 was behaving, right? But again, that not seems to be very
>> comfortable.
>
> mimeapps.list allowed us to finally stop copying desktop files locally,
> and I would certainly NOT want to go back to that horror.
> It leads to tons of problems, including desktop files with outdated infor=
mation,
> and desktop files pointing to uninstalled applications. Please let us
> forget you even mentionned this possibility :-)

Hehe, let's say I have already forgotten it :-)

>
>> > Also, this would break with desktop-independent apps, like firefox; it=
 doesn't
>> > have KDE or Gnome in Categories, and yet some distros might want to
>> > make it the default web browser; but they would have no way of doing t=
hat,
>> > since as soon as another web browser appears in the list, it would tak=
e priority,
>> > with the above algorithm.
>>
>> I was thinking that distros will bump priorities for their defaults
>> (and remove then defaults.list for GNOME). For instance, FF in Ubuntu
>> would have a priority of 9 and epiphany, which is not our default, 5
>> or 1. So, the logic might be:
>> First: user choice
>> Then: Priority
>> Finally: if max(priority) is not unique, use the Categories to look at
>> the best suited application.
>
> That seems quite reasonable.
>
> It requires quite some coordination (or work from the distro) though:
> if epiphany ships with 5 and konqueror ships with 6, then konqueror would
> always be preferred and gnome users won't like it; either upstream
> gnome and kde need to agree on a standard initial preference, or
> all distros need to adjust those by hand to achieve desired behavior.

Of course, this solution has the drawback to require coordination.
That's why we have to choose a default value from value (5 seems quite
reasonable) to push as a Priority fot the InitialPreference entry.

So, to sum up the current proposition status, for a given mime-type:
- we look first if user has overwritten it, that is to say, an entry
for this mime type exists in mimeapps.list in XDG_DATA_HOME
- then, we look for mimeapps.list in other paths of XDG_DATA_DIRS.
This take into account the case where administrators wants to change
the defaults.
- finally, choose the application associated with this mime-type
having the higher InitialPreference entry in the .desktop file
  -> if there are more than one candidate with the maximal
InitialPreference value, each library binding choose the default
environment using the Category entry (KDE, QT, GNOME, GTK, XFCE ...)
in their prefered way...


>[...]
>
> Right. I guess I'm withdrawing my InitialPreference-* idea then, since it=
 requires
> changes to the desktop entry standard, so if we can do without, all the b=
etter.
>
>

> OK. Maybe you guys (=3Dall distros) can develop a .desktop-file-patching =
tool so the files
> can be modified at install time rather than keeping actual diffs (which b=
reak
> when a nearby translation is updated) in the packages... So you would put=
 in
> the package description a call like
> =A0modify-desktop-file konqueror.desktop InitialPreference=3D15
> Just an idea ;)
>

Yes, or each distros can update a tool that specifically change the
value when building it, which doesn't use a patch system. Well...
that's distroeries :)

Didier