Have a way to dynamically change software associations at distribution level

[Didier Roche-3]

Hello everyone,

Right now, GNU/Linux distributions (Debian, Ubuntu, from what I see it
seems to apply to Fedora, OpenSuse and Mandrake as well…) use a static
defaults.list file in $XDG_DATA_DIRS/applications shipped by the
distribution for associating a mimetype to a default application. We
currently, for Ubuntu, symlink it to /etc/gnome/defaults.list.
Consequently, we set a software as the default distribution default
dvd player for example. That means as well that if a user buy a better
player with codec they don't get this one used by default without
changing user's personal preferences. We want to change the system to
have a priority number rather than a default hardcoded, ie powerdvd
would have a higher priority than totem (for Ubuntu for example) so it
will be used when installed.

To handle application priorities, the idea is to rely on the .desktop
files having an optional InitialPreference=<Priority> (similar key to
what KDE is using), a default priority will be used if there is no
such key. We can setup a 100 priority for application currently
present in defaults.list for distros, and 50 as the default priority
if the key is not present in the .desktop file.

This is a proposal for changing
http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec
and http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec
specifications to handle those use cases. The main goal is to keep
retro-compatibility for people who don't want to change their
defaults.list. As we don't change the current layer of user choice in
$XDG_DATA_HOME > defaults choice in $XDG_DATA_DIRS/applications, I
will just emphasize about defaults.list and the cache: The priority
order would be:

    * mimeapps.list for sysadmin
    * defaults.list for distro and compatibility (at the end,
distribution wanted to use this dynamic association will no more ship
it)
    * mimeinfo.cache autobuilt

Updating mimeinfo.cache file will be made as of today, when executing
the shared-mime-info update-desktop-database tool. It will order the
list of desktop file in the same order than the priorities in desktop
files.

That would mean with that example:

    * application/ogg=gnome-mplayer.desktop;vlc.desktop;kde4-amarok.desktop;mplayer.desktop;rhythmbox.desktop;totem.desktop;

gnome-mplayer.desktop priority < vlc.desktop priority < kde4 amarok <
mplayer < rhythmbox < totem

We want also to take into account the current desktop environment. For
instance, with this example, if you are running KDE, the distribution
default choice (if no user choice is setup) would be totem instead of
amarok. To avoid this issue, categories will be used to prefer the
application matching the desktop when there are several choices (ie
KDE category when using KDE. Consequently, amarok will be used in a
KDE environment and totem in the GNOME one, if the user doesn't change
his/her own preferences). That would mean that we open the "default
candidate" .desktop file to see if we fit the current environment. If
not, we head to the previous one of the list, open the .desktop file…
So, the default choice rule (if the user didn't change anything and
the distro don't ship a defaults.list for this mime type) will be: the
last .desktop application file found in the list corresponding to my
mime type, having a category corresponding to my current desktop
environment. If no .desktop file corresponding to the current
environment is found, we fallback to the last entry.

What do you think about it? I only take a look at glib (more
precisely, the gio module) and update-mime-info and the code to write
to achieve that goal seems minimal.

Didier
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Tuesday 04 August 2009, Didier Roche wrote:
> Hello everyone,
>
> Right now, GNU/Linux distributions (Debian, Ubuntu, from what I see it
> seems to apply to Fedora, OpenSuse and Mandrake as well…) use a static
> defaults.list file in $XDG_DATA_DIRS/applications shipped by the
> distribution for associating a mimetype to a default application.

defaults.list is a gnome-only file, it is not part of a freedesktop standard and
not read by KDE.

> To handle application priorities, the idea is to rely on the .desktop
> files having an optional InitialPreference=<Priority> (similar key to
> what KDE is using), a default priority will be used if there is no
> such key. We can setup a 100 priority for application currently
> present in defaults.list for distros, and 50 as the default priority
> if the key is not present in the .desktop file.

In KDE the default priority is 1 and desktop files which set a priority
often use 5 or 9, but well ;)

> This is a proposal for changing
> http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec
> and http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec
> specifications to handle those use cases. The main goal is to keep
> retro-compatibility for people who don't want to change their
> defaults.list. As we don't change the current layer of user choice in
> $XDG_DATA_HOME > defaults choice in $XDG_DATA_DIRS/applications, I
> will just emphasize about defaults.list and the cache: The priority
> order would be:
>
>     * mimeapps.list for sysadmin
>     * defaults.list for distro and compatibility (at the end,
> distribution wanted to use this dynamic association will no more ship
> it)
>     * mimeinfo.cache autobuilt

I think mimeinfo.cache is also gnome-only. Or did you mean mime.cache as
specified in the shared-mime-info spec?

> Updating mimeinfo.cache file will be made as of today, when executing
> the shared-mime-info update-desktop-database tool. It will order the
> list of desktop file in the same order than the priorities in desktop
> files.

Sounds like gnome-specific code in update-desktop-database, but I don't
mind, if it leads to convergence - i.e. the goal is to generate a compatibility
file out of the primary source of information which would be InitialPreference,
right? That sounds good to me.

> That would mean with that example:
>
>     * application/ogg=gnome-mplayer.desktop;vlc.desktop;kde4-amarok.desktop;mplayer.desktop;rhythmbox.desktop;totem.desktop;
>
> gnome-mplayer.desktop priority < vlc.desktop priority < kde4 amarok <
> mplayer < rhythmbox < totem

Err don't you mean > rather than < ???
If the above is mimeapps.list syntax, then the first app (here gnome-mplayer.desktop)
is the preferred app. That's the syntax we adopted for mimeapps.list (where we is
basically Alex Larsson and myself on this list, nobody wrote a formal standard out
of it, unfortunately; volunteers welcome). At least I hope this is how he understood
it too :-)

> We want also to take into account the current desktop environment. For
> instance, with this example, if you are running KDE, the distribution
> default choice (if no user choice is setup) would be totem instead of
> amarok. To avoid this issue, categories will be used to prefer the
> application matching the desktop when there are several choices (ie
> KDE category when using KDE. Consequently, amarok will be used in a
> KDE environment and totem in the GNOME one, if the user doesn't change
> his/her own preferences). That would mean that we open the "default
> candidate" .desktop file to see if we fit the current environment. If
> not, we head to the previous one of the list, open the .desktop file…
> So, the default choice rule (if the user didn't change anything and
> the distro don't ship a defaults.list for this mime type) will be: the
> last .desktop application file found in the list corresponding to my
> mime type, having a category corresponding to my current desktop
> environment. If no .desktop file corresponding to the current
> environment is found, we fallback to the last entry.

So a user who wants to use amarok in gnome, just cannot, because the code
will always skip it due to a missing category?
Unless the parsing of the "global" mimeapps.list is different
from the parsing of the user-specific mimeapps.list, which sounds ugly.
Especially if you take into account that there is more than just "global" and "local",
one could set up groups of users by adding dirs in XDG_DATA_DIRS.

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 that,
since as soon as another web browser appears in the list, it would take priority,
with the above algorithm.


I thought the solution for "different defaults in different desktop environments"
was the current status-quo of "we share mimeapps.list but not the mechanism
for the global defaults (InitialPreference in kde, defaults.list in gnome)". I can
see how this makes the life of distributions slightly more difficult though, since
you have to set up defaults twice with different mechanisms.

Now would be a good time for me to offer a solution, after the above constructive
criticism, I guess.... Hmm. Maybe
InitialPreference-KDE=15
InitialPreference-Gnome=2
in amarok.desktop (for instance), as an alternative to a cross-desktop
InitialPreference=15 (in firefox.desktop for instance)?
However this requires distributors to patch a lot of desktop files, I'm not sure
that's workable? In fact I'm not sure of the requirements; editing a single file
like defaults.list doesn't make it very modular, while a key in the desktop file
is very modular but requires a lot of patching...

--
David Faure, faure@..., sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Francois Gouget]

Didier Roche a écrit :
[...]
> To handle application priorities, the idea is to rely on the .desktop
> files having an optional InitialPreference=<Priority> (similar key to
> what KDE is using)

Actually, this is not a 'similar key', but the exact key that KDE is
using to this day.

I think using the exact same key as KDE is the right thing to do, but
then they should be compatible. That means:
  * Increasing numerical value means increasing priority (no problem
here apparently).
  * Highest priority is (typically) 10 and lowest 1.

That last point is a problem if you want to dynamically assign
priorities to the defaults.list entries: in your example you already
have 6 entries which would cover a good part of the available priority
range already.

KDE has used InitialPreference since long before XDG existed. So that
causes me to wonder. Why didn't XDG use this scheme from the get-go? Was
it considered and ruled out? If so, what were the reasons at the time?
Don't they still apply?

--
Francois Gouget
fgouget@...

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Patryk Zawadzki]

On Tue, Aug 4, 2009 at 11:31 AM, Francois Gouget<fgouget@...> wrote:
> KDE has used InitialPreference since long before XDG existed. So that
> causes me to wonder. Why didn't XDG use this scheme from the get-go? Was
> it considered and ruled out? If so, what were the reasons at the time?
> Don't they still apply?

I think it doesn't solve the most common multi-desktop scenario:

* KDE should favor KDE/QT apps
* GNOME should favor GNOME/GTK+ apps
* XFCE should favor XFCE apps but probably prefer GTK+ to QT etc.

--
Patryk Zawadzki
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Francois Gouget]

Patryk Zawadzki a écrit :

> On Tue, Aug 4, 2009 at 11:31 AM, Francois Gouget<fgouget@...> wrote:
>> KDE has used InitialPreference since long before XDG existed. So that
>> causes me to wonder. Why didn't XDG use this scheme from the get-go? Was
>> it considered and ruled out? If so, what were the reasons at the time?
>> Don't they still apply?
>
> I think it doesn't solve the most common multi-desktop scenario:
>
> * KDE should favor KDE/QT apps
> * GNOME should favor GNOME/GTK+ apps
> * XFCE should favor XFCE apps but probably prefer GTK+ to QT etc.

defaults.list does not seem to solve that problem either... except by
being a mechanism that is not used by KDE. But specifying that each
desktop environment should use a different mechanism does not sound like
a good idea<g>.


--
Francois Gouget
fgouget@...

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Patryk Zawadzki]

On Tue, Aug 4, 2009 at 12:16 PM, Francois Gouget<fgouget@...> wrote:
> defaults.list does not seem to solve that problem either... except by being
> a mechanism that is not used by KDE. But specifying that each desktop
> environment should use a different mechanism does not sound like a good
> idea<g>.

I didn't mean to defent GNOME or criticize KDE, I just wanted to point
out that we might need more than just a list of apps to try in order
:)

Maybe something like:

X-Priority=10

...could solve it? Then for example XFCE could multiply priorities of
apps with KDE/QT in categories by 0.7 and priorities of XFCE apps by
1.5.

--
Patryk Zawadzki
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jannis Pohlmann-3]

On Tue, 4 Aug 2009 11:02:43 +0200
David Faure <faure@...> wrote:

> On Tuesday 04 August 2009, Didier Roche wrote:
> > Hello everyone,
> >
> > Right now, GNU/Linux distributions (Debian, Ubuntu, from what I see
> > it seems to apply to Fedora, OpenSuse and Mandrake as well…) use a
> > static defaults.list file in $XDG_DATA_DIRS/applications shipped by
> > the distribution for associating a mimetype to a default
> > application.
>
> defaults.list is a gnome-only file, it is not part of a freedesktop
> standard and not read by KDE.

It doesn't seem to be written by GIO anymore. It still reads
defaults.list for backwards compatibility reasons but I think it only
writes to mimeapps.list.

  - Jannis


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Didier Roche-3]

On Tue, Aug 4, 2009 at 11:02 AM, David Faure<faure@...> wrote:

> On Tuesday 04 August 2009, Didier Roche wrote:
>> Hello everyone,
>>
>> Right now, GNU/Linux distributions (Debian, Ubuntu, from what I see it
>> seems to apply to Fedora, OpenSuse and Mandrake as well…) use a static
>> defaults.list file in $XDG_DATA_DIRS/applications shipped by the
>> distribution for associating a mimetype to a default application.
>
> defaults.list is a gnome-only file, it is not part of a freedesktop standard and
> not read by KDE.

Ok, thanks for the clarification.

>
>> To handle application priorities, the idea is to rely on the .desktop
>> files having an optional InitialPreference=<Priority> (similar key to
>> what KDE is using), a default priority will be used if there is no
>> such key. We can setup a 100 priority for application currently
>> present in defaults.list for distros, and 50 as the default priority
>> if the key is not present in the .desktop file.
>
> In KDE the default priority is 1 and desktop files which set a priority
> often use 5 or 9, but well ;)

Ok, seems good to merge that :)
So, priority will be 1 for default priority, x for priority set in
desktop file where distribution wants to be it the normal default
application (x is to definied... 5 ?).
and the range will be 1 to 10?

>
>> This is a proposal for changing
>> http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec
>> and http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec
>> specifications to handle those use cases. The main goal is to keep
>> retro-compatibility for people who don't want to change their
>> defaults.list. As we don't change the current layer of user choice in
>> $XDG_DATA_HOME > defaults choice in $XDG_DATA_DIRS/applications, I
>> will just emphasize about defaults.list and the cache: The priority
>> order would be:
>>
>>     * mimeapps.list for sysadmin
>>     * defaults.list for distro and compatibility (at the end,
>> distribution wanted to use this dynamic association will no more ship
>> it)
>>     * mimeinfo.cache autobuilt
>
> I think mimeinfo.cache is also gnome-only. Or did you mean mime.cache as
> specified in the shared-mime-info spec?

mimeinfo.cache seems to be also GNOME only (cf Alex Larsson's post
http://lists.freedesktop.org/archives/xdg/2008-January/009111.html).
It has the same syntax as mimeapps.list.
You told on this post that you have a different cache for KDE
(ksycoca, right?). Is there an about anywhere in a file?

Maybe it's the time to merge those behaviors? Finding a good man in
the middle solution. I volunteer to give some help in that direction
even if I know very little about the KDE's platform. :)

>
>> Updating mimeinfo.cache file will be made as of today, when executing
>> the shared-mime-info update-desktop-database tool. It will order the
>> list of desktop file in the same order than the priorities in desktop
>> files.
>
> Sounds like gnome-specific code in update-desktop-database, but I don't
> mind, if it leads to convergence - i.e. the goal is to generate a compatibility
> file out of the primary source of information which would be InitialPreference,
> right? That sounds good to me.
>
>> That would mean with that example:
>>
>>     * application/ogg=gnome-mplayer.desktop;vlc.desktop;kde4-amarok.desktop;mplayer.desktop;rhythmbox.desktop;totem.desktop;
>>
>> gnome-mplayer.desktop priority < vlc.desktop priority < kde4 amarok <
>> mplayer < rhythmbox < totem
>
> Err don't you mean > rather than < ???
> If the above is mimeapps.list syntax, then the first app (here gnome-mplayer.desktop)
> is the preferred app. That's the syntax we adopted for mimeapps.list (where we is
> basically Alex Larsson and myself on this list, nobody wrote a formal standard out
> of it, unfortunately; volunteers welcome). At least I hope this is how he understood
> it too :-)

Oh right, I got puzzled by the invocation of inversing the Glist in
gio, but it's just an implementation detail :)
After performing some additional tests, yes, the current
implementation (for GNOME, at least, but you seems to confirm for KDE)
is >.

>
>> We want also to take into account the current desktop environment. For
>> instance, with this example, if you are running KDE, the distribution
>> default choice (if no user choice is setup) would be totem instead of
>> amarok. To avoid this issue, categories will be used to prefer the
>> application matching the desktop when there are several choices (ie
>> KDE category when using KDE. Consequently, amarok will be used in a
>> KDE environment and totem in the GNOME one, if the user doesn't change
>> his/her own preferences). That would mean that we open the "default
>> candidate" .desktop file to see if we fit the current environment. If
>> not, we head to the previous one of the list, open the .desktop file…
>> So, the default choice rule (if the user didn't change anything and
>> the distro don't ship a defaults.list for this mime type) will be: the
>> last .desktop application file found in the list corresponding to my
>> mime type, having a category corresponding to my current desktop
>> environment. If no .desktop file corresponding to the current
>> environment is found, we fallback to the last entry.
>
> So a user who wants to use amarok in gnome, just cannot, because the code
> will always skip it due to a missing category?
> Unless the parsing of the "global" mimeapps.list is different
> from the parsing of the user-specific mimeapps.list, which sounds ugly.
> Especially if you take into account that there is more than just "global" and "local",
> one could set up groups of users by adding dirs in XDG_DATA_DIRS.
>

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"). 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.

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.

> 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 that,
> since as soon as another web browser appears in the list, it would take 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.

>
>
> I thought the solution for "different defaults in different desktop environments"
> was the current status-quo of "we share mimeapps.list but not the mechanism
> for the global defaults (InitialPreference in kde, defaults.list in gnome)". I can
> see how this makes the life of distributions slightly more difficult though, since
> you have to set up defaults twice with different mechanisms.

Exactly, and if a distribution wants to add some others features like
this dynamic association, it makes life a little harder too :)
Again, if we can find a common solution, this will help distributions
and desktop environment too. I'm ready to give the needed help to
reach that.

>
> Now would be a good time for me to offer a solution, after the above constructive
> criticism, I guess.... Hmm. Maybe
> InitialPreference-KDE=15
> InitialPreference-Gnome=2
> in amarok.desktop (for instance), as an alternative to a cross-desktop
> InitialPreference=15 (in firefox.desktop for instance)?

So, you propose that every desktop environment would have its own
InitialPreference-whatever entry?
I don't really see how this can help regarding the previous example
about Firefox (both konqueror and firefox application having the same
priority, the distribution if she wants firefox by default in the KDE
environment has to patch it to bump it to 16). My modified proposition
(see a little above) has this drawback too, but does not propose
multi-InitialPreference* tag.

> However this requires distributors to patch a lot of desktop files, I'm not sure
> that's workable? In fact I'm not sure of the requirements; editing a single file
> like defaults.list doesn't make it very modular, while a key in the desktop file
> is very modular but requires a lot of patching...

Exactly, in both propositions a lot of desktop file (at least,
default's one) have to be patched.

Didier
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Didier Roche-3]

On Tue, Aug 4, 2009 at 2:25 PM, Didier Roche<didrocks@...> wrote:
>
> 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.

Of course, this create the following issue: application must have for
functional equivalent usage the same priority. It seems a fuzzy
solution so.
Consequently, if we don't take into account prorities if we are
looking at categories first, putting firefox and cross-desktop apps by
default is really tricky. I understand better now your specific tags
by environment, this can be the way to go (but it involves, as you
said, massive patching for desktop environment specific apps).

Didier
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Tuesday 04 August 2009, Patryk Zawadzki wrote:

> On Tue, Aug 4, 2009 at 12:16 PM, Francois Gouget<fgouget@...> wrote:
> > defaults.list does not seem to solve that problem either... except by being
> > a mechanism that is not used by KDE. But specifying that each desktop
> > environment should use a different mechanism does not sound like a good
> > idea<g>.
>
> I didn't mean to defent GNOME or criticize KDE, I just wanted to point
> out that we might need more than just a list of apps to try in order
> :)
>
> Maybe something like:
>
> X-Priority=10
>
> ...could solve it?

That's exactly the InitialPreference field.
("Initial" because the user or sysadmin can overwrite it with mimeapps.list)

> Then for example XFCE could multiply priorities of
> apps with KDE/QT in categories by 0.7 and priorities of XFCE apps by
> 1.5.

This could be a solution for "prefer native apps" indeed; but maybe it wouldn't
give enough control to the distributions?

--
David Faure, faure@..., sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Francois Gouget]

David Faure a écrit :
[...]
>> Then for example XFCE could multiply priorities of
>> apps with KDE/QT in categories by 0.7 and priorities of XFCE apps by
>> 1.5.
>
> This could be a solution for "prefer native apps" indeed; but maybe it wouldn't
> give enough control to the distributions?

Having a multiplier seems very complex opaque to me: if my application
has a priority of 7 and the XFCE application a priority of 5, which one
is the preferred one? There's the rounding issue of course, but there's
also an uncertainty on the multiplier value. Would XFCE, KDE and Gnome
all use the same multiplier? Would SUSE's Gnome multiplier be the same
as Fedora's or won't each Linux distributor be tempted to tweak it to
'solve' priority issues?

Why not just say that if two applications have the same priority, then
the desktop environment checks their category to select the 'native' one.

The Linux distributors can arrange to have the priorities set right on
the desktop files they ship. Ideally this would even be agreed upon
upstream for most applications (unless we see a priority race instead).

And at least, ISVs could trust the content of the InitialPreference
field instead of having to second guess the multiplier that's going to
be applied to them

--
Francois Gouget
fgouget@...

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Matthias Clasen]

On Tue, 2009-08-04 at 13:40 +0200, Jannis Pohlmann wrote:

> On Tue, 4 Aug 2009 11:02:43 +0200
> David Faure <faure@...> wrote:
>
> > On Tuesday 04 August 2009, Didier Roche wrote:
> > > Hello everyone,
> > >
> > > Right now, GNU/Linux distributions (Debian, Ubuntu, from what I see
> > > it seems to apply to Fedora, OpenSuse and Mandrake as well…) use a
> > > static defaults.list file in $XDG_DATA_DIRS/applications shipped by
> > > the distribution for associating a mimetype to a default
> > > application.
> >
> > defaults.list is a gnome-only file, it is not part of a freedesktop
> > standard and not read by KDE.
>
> It doesn't seem to be written by GIO anymore. It still reads
> defaults.list for backwards compatibility reasons but I think it only
> writes to mimeapps.list.
>

defaults.list is not meant to be written by session agents. It is is the
system-wide defaults. mimeapps.list is the per-user file that overrides
it. All this has been worked out on this list between Alex Larsson and
David Faure some time ago.

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Tuesday 04 August 2009, Matthias Clasen wrote:

> On Tue, 2009-08-04 at 13:40 +0200, Jannis Pohlmann wrote:
> > On Tue, 4 Aug 2009 11:02:43 +0200
> > David Faure <faure@...> wrote:
> >
> > > On Tuesday 04 August 2009, Didier Roche wrote:
> > > > Hello everyone,
> > > >
> > > > Right now, GNU/Linux distributions (Debian, Ubuntu, from what I see
> > > > it seems to apply to Fedora, OpenSuse and Mandrake as well…) use a
> > > > static defaults.list file in $XDG_DATA_DIRS/applications shipped by
> > > > the distribution for associating a mimetype to a default
> > > > application.
> > >
> > > defaults.list is a gnome-only file, it is not part of a freedesktop
> > > standard and not read by KDE.
> >
> > It doesn't seem to be written by GIO anymore. It still reads
> > defaults.list for backwards compatibility reasons but I think it only
> > writes to mimeapps.list.
> >
>
> defaults.list is not meant to be written by session agents. It is is the
> system-wide defaults.

... for gnome.

> mimeapps.list is the per-user file that overrides it.

mimeapps.list can also be used at any level in XDG_DATA_DIRS,
for cross-desktop mime-apps associations.

--
David Faure, faure@..., sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Tuesday 04 August 2009, Didier Roche wrote:

> >> To handle application priorities, the idea is to rely on the .desktop
> >> files having an optional InitialPreference=<Priority> (similar key to
> >> what KDE is using), a default priority will be used if there is no
> >> such key. We can setup a 100 priority for application currently
> >> present in defaults.list for distros, and 50 as the default priority
> >> if the key is not present in the .desktop file.
> >
> > In KDE the default priority is 1 and desktop files which set a priority
> > often use 5 or 9, but well ;)
>
> Ok, seems good to merge that :)
> So, priority will be 1 for default priority, x for priority set in
> desktop file where distribution wants to be it the normal default
> application (x is to definied... 5 ?).

x has multiple values. That's the whole point of this system.
The idea is: I have apps A and B, which are both good, so they
have an InitialPreference set. If both are installed, A is preferred,
so InitialPreference(A) > InitialPreference(B), but if only one is installed
then it will be used.
That's what I meant by modular: it accomodates for the fact that apps
can be installed at any time. A single file shipped by the distro doesn't
do this (it could list all apps that are packaged by the distro at the time
of the release, but it cannot list the apps that people can install on top
of it from other ISVs -- for instance CrossOver Office, hi Francois ;) ).

> and the range will be 1 to 10?

There is no upper value currently.

> mimeinfo.cache seems to be also GNOME only (cf Alex Larsson's post
> http://lists.freedesktop.org/archives/xdg/2008-January/009111.html).
> It has the same syntax as mimeapps.list.
> You told on this post that you have a different cache for KDE
> (ksycoca, right?).

Right.

> Is there an about anywhere in a file?

I don't understand this question.

> Maybe it's the time to merge those behaviors? Finding a good man in
> the middle solution. I volunteer to give some help in that direction
> even if I know very little about the KDE's platform. :)

I don't see a need to unify the caches. The point of a cache is performance,
not interoperability; interoperability is achieved by sharing the initial source
of the data, which is right now mimeapps.list and which could be anything else
we decide in this thread, like InitialPreference for instance.
Caches can and should be left implementation-dependent IMHO; it would
make no sense for me to try and convince other projects to use ksycoca
(which uses a very kde-centric binary format), and it would also make no
sense for KDE to use a less optimized cache.

But I'm starting to wonder if in gnome mimeinfo.cache is really a cache, or a
primary source of information?

> 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_DATA_DIRS
then?  (e.g. /usr/share/applications/mimeapps.list)
That would be a bug IMHO...

> 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...

> 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 information,
and desktop files pointing to uninstalled applications. Please let us
forget you even mentionned this possibility :-)

> > 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 that,
> > since as soon as another web browser appears in the list, it would take 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.

> > Now would be a good time for me to offer a solution, after the above constructive
> > criticism, I guess.... Hmm. Maybe
> > InitialPreference-KDE=15
> > InitialPreference-Gnome=2
> > in amarok.desktop (for instance), as an alternative to a cross-desktop
> > InitialPreference=15 (in firefox.desktop for instance)?
>
> So, you propose that every desktop environment would have its own
> InitialPreference-whatever entry?

Yes but only if some applications make more sense as default in that
desktop environment than in another. To take a neutral example, fvwm
wouldn't really care so there wouldn't be a InitialPreference-fvwm key ;)

> I don't really see how this can help regarding the previous example
> about Firefox (both konqueror and firefox application having the same
> priority, the distribution if she wants firefox by default in the KDE
> environment has to patch it to bump it to 16).

If the distro wants FF by default everywhere, it would just have a single key
InitialPreference=15 for FF (and less in other browsers).

On the other hand, if the distro wants konq in kde and firefox in gnome, it would write
in konqueror.desktop:
InitialPreference-KDE=20
InitialPreference-Gnome=5

This is more flexible than the use of categories alone, but indeed with your idea
of using categories only for InitialPreference equality, the distro can make an
app "preferred everywhere" and "preferred in this desktop only".
You just can't make k3b "preferred in gnome only", but I guess that wouldn't make much sense.

> My modified proposition
> (see a little above) has this drawback too, but does not propose
> multi-InitialPreference* tag.

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 better.

> > However this requires distributors to patch a lot of desktop files, I'm not sure
> > that's workable? In fact I'm not sure of the requirements; editing a single file
> > like defaults.list doesn't make it very modular, while a key in the desktop file
> > is very modular but requires a lot of patching...
>
> Exactly, in both propositions a lot of desktop file (at least,
> default's one) have to be patched.

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

--
David Faure, faure@..., sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Didier Roche-3]

On Wed, Aug 5, 2009 at 2:57 PM, David Faure<faure@...> wrote:

> On Tuesday 04 August 2009, Didier Roche wrote:
>> >> To handle application priorities, the idea is to rely on the .desktop
>> >> files having an optional InitialPreference=<Priority> (similar key to
>> >> what KDE is using), a default priority will be used if there is no
>> >> such key. We can setup a 100 priority for application currently
>> >> present in defaults.list for distros, and 50 as the default priority
>> >> if the key is not present in the .desktop file.
>> >
>> > In KDE the default priority is 1 and desktop files which set a priority
>> > often use 5 or 9, but well ;)
>>
>> Ok, seems good to merge that :)
>> So, priority will be 1 for default priority, x for priority set in
>> desktop file where distribution wants to be it the normal default
>> application (x is to definied... 5 ?).
>
> x has multiple values. That's the whole point of this system.
> The idea is: I have apps A and B, which are both good, so they
> have an InitialPreference set. If both are installed, A is preferred,
> so InitialPreference(A) > InitialPreference(B), but if only one is installed
> then it will be used.

Yes. In reality, I was speaking about a generic number shared between
upstream and pushed as a fdo spec. For instance, if we can say that
upstream projects has to put 5 as a default number.
1 will be automatically chosen for applications not pushing a value.
Of course, that's a place where distros can help upstreams to be aware
and push this default value as patch for them.

Then, distros can patch (or use whatever way they wish) to change the
defaults for them.


> That's what I meant by modular: it accomodates for the fact that apps
> can be installed at any time. A single file shipped by the distro doesn't
> do this (it could list all apps that are packaged by the distro at the time
> of the release, but it cannot list the apps that people can install on top
> of it from other ISVs -- for instance CrossOver Office, hi Francois ;) ).

Exactly. That's the reason why we are discussing now :)
Static lists are just... bad :p

>
>> and the range will be 1 to 10?
>
> There is no upper value currently.

Ok. we can define that there is no upper value in the spec.

>
>> mimeinfo.cache seems to be also GNOME only (cf Alex Larsson's post
>> http://lists.freedesktop.org/archives/xdg/2008-January/009111.html).
>> It has the same syntax as mimeapps.list.
>> You told on this post that you have a different cache for KDE
>> (ksycoca, right?).
>
> Right.
>
>
>> Maybe it's the time to merge those behaviors? Finding a good man in
>> the middle solution. I volunteer to give some help in that direction
>> even if I know very little about the KDE's platform. :)
>
> I don't see a need to unify the caches. The point of a cache is performance,
> not interoperability; interoperability is achieved by sharing the initial source
> of the data, which is right now mimeapps.list and which could be anything else
> we decide in this thread, like InitialPreference for instance.
> Caches can and should be left implementation-dependent IMHO; it would
> make no sense for me to try and convince other projects to use ksycoca
> (which uses a very kde-centric binary format), and it would also make no
> sense for KDE to use a less optimized cache.
>
> But I'm starting to wonder if in gnome mimeinfo.cache is really a cache, or a
> primary source of information?

From what I quickly saw in glib code, it seems to be acache built from
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_DATA_HOME
> then?  (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 information,
> 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 that,
>> > since as soon as another web browser appears in the list, it would take 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 better.
>
>

> OK. Maybe you guys (=all distros) can develop a .desktop-file-patching tool so the files
> can be modified at install time rather than keeping actual diffs (which break
> when a nearby translation is updated) in the packages... So you would put in
> the package description a call like
>  modify-desktop-file konqueror.desktop InitialPreference=15
> 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
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Wednesday 05 August 2009, Didier Roche wrote:
> > x has multiple values. That's the whole point of this system.
> > The idea is: I have apps A and B, which are both good, so they
> > have an InitialPreference set. If both are installed, A is preferred,
> > so InitialPreference(A) > InitialPreference(B), but if only one is installed
> > then it will be used.
>
> Yes. In reality, I was speaking about a generic number shared between
> upstream and pushed as a fdo spec. For instance, if we can say that
> upstream projects has to put 5 as a default number.

Well, that's a simplification. It works when each project provides *one* application
for a given job (mimetype).
But we already use multiple values of InitialPreference inside kde, for instance.
Let me find examples, then...
dolphin(10) > konqueror-as-file-manager(9)
kwrite(8) > kword(3) > kate(no key, so 1)   (and openoffice-writer has 5 it seems),
  as the default ordering for text/plain files. Remember that the "preferred app" is
not the whole story, we also need to order the apps in the RMB / "Open With..." submenu
(and of course to handle the case where an app is uninstalled, same thing).


Oh, this reminds me.
Of course the limitation of the InitialPreference approach is that it applies
to all the mimetypes that the app is associated with; this can create trouble
in some cases where a per-mimetype initial-preference would be needed.
That is, if app A handles mimetype M1 better than app B, but app B handles
mimetype M2 better than A, and yet they both support M1 and M2 in theory
(but for instance as "import only, no export", or "importing with losses").
To fix that there are two solutions: splitting out into two .desktop files
(we do that for konqueror's two "roles", for instance, but most of the time
this is an ugly solution because you want only one instance of the app in
the menu so you need to hide the other desktop file, and then if the user
makes some changes to the visible desktop file it wouldn't affect the other
half... well, corner case, maybe...).
The other solution is to invent a way to specify per-mimetype initial-preference
in desktop files. We have a hack with an ugly syntax for this in KDE's .desktop
file parser, but I certainly don't want to see it standardized.
(For the curious, it's MimeType=text/plain;5;application/msword;9;
Yes, ugly and non-standard, but we just blame the one who had the idea ;) ).

Well, maybe we just forget about this and split out .desktop files in the rare
case where this is necessary. We already split out .desktop files when the
app support for a mimetype depends on a plugin anyway (example: okularApplication_djvu.desktop)

> > Does gio ignore mimeapps.list files in other directories listed in XDG_DATA_HOME
> > then?  (e.g. /usr/share/applications/mimeapps.list)

Actually, thinking about it again, I'm almost sure Alex Larsson and I discussed that
aspect, so it doubt it ignores those files.

> 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 [right] with that definition? (I
> understood it in this way in the spec)

Yes.

> > 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.

In the simple case, yes, we could say "the preferred app for a given
desktop environment can get the value X" (actually I would say 10
rather than 5, see the list above of text/plain handlers, you can end up
with quite a few lower-priority apps, and yet you want to order them
correctly, so better have room under the preferred app).

> 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...

Yes, assuming the gio people agree, of course; I didn't see them involved
in this thread yet, but I don't want to "standardize" something without their okay ;)
Alex Larsson told me at GCDS that he was quite busy this summer, you might
have to ping him directly to get this moving forward.

>  I'm ready to give the needed help to reach that.

Oh, if you have time for this, maybe you could write the actual spec for mimeapps.list
itself while being at it... better for the long run than "read the discussion between Alex
and David on the list" ;-)
It certainly belongs to the same spec as the stuff we're discussing now; it's all part of
the mime-apps association and priority issue.

--
David Faure, faure@..., sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Didier Roche-3]

On Wed, Aug 5, 2009 at 10:17 PM, David Faure<faure@...> wrote:

> On Wednesday 05 August 2009, Didier Roche wrote:
>> > x has multiple values. That's the whole point of this system.
>> > The idea is: I have apps A and B, which are both good, so they
>> > have an InitialPreference set. If both are installed, A is preferred,
>> > so InitialPreference(A) > InitialPreference(B), but if only one is installed
>> > then it will be used.
>>
>> Yes. In reality, I was speaking about a generic number shared between
>> upstream and pushed as a fdo spec. For instance, if we can say that
>> upstream projects has to put 5 as a default number.
>
> Well, that's a simplification. It works when each project provides *one* application
> for a given job (mimetype).
> But we already use multiple values of InitialPreference inside kde, for instance.
> Let me find examples, then...
> dolphin(10) > konqueror-as-file-manager(9)
> kwrite(8) > kword(3) > kate(no key, so 1)   (and openoffice-writer has 5 it seems),
>  as the default ordering for text/plain files. Remember that the "preferred app" is
> not the whole story, we also need to order the apps in the RMB / "Open With..." submenu
> (and of course to handle the case where an app is uninstalled, same thing).
>

Yes, that was the next step I was planning to discuss about (but the
first implementation can be a first step until we find something
better).
In GNOME, IIRC, the order of applications showed in "Open with…" is
just ordered alphabetically.

>
> Oh, this reminds me.
> Of course the limitation of the InitialPreference approach is that it applies
> to all the mimetypes that the app is associated with; this can create trouble
> in some cases where a per-mimetype initial-preference would be needed.

I absolutely agree.

> That is, if app A handles mimetype M1 better than app B, but app B handles
> mimetype M2 better than A, and yet they both support M1 and M2 in theory
> (but for instance as "import only, no export", or "importing with losses").
> To fix that there are two solutions: splitting out into two .desktop files
> (we do that for konqueror's two "roles", for instance, but most of the time
> this is an ugly solution because you want only one instance of the app in
> the menu so you need to hide the other desktop file, and then if the user
> makes some changes to the visible desktop file it wouldn't affect the other
> half... well, corner case, maybe...).

Indeed, this seems to be suboptimal as when an user wants to edit a
menu, he/her can be confused by those multiple instances, one visible,
the other marked as hidden.

> The other solution is to invent a way to specify per-mimetype initial-preference
> in desktop files. We have a hack with an ugly syntax for this in KDE's .desktop
> file parser, but I certainly don't want to see it standardized.
> (For the curious, it's MimeType=text/plain;5;application/msword;9;
> Yes, ugly and non-standard, but we just blame the one who had the idea ;) ).

And this one is? :)
More seriously, if we replace text/plain;5 by text/plain,5 it makes a
little more sense (two kinds of separator). But it seems not to be the
right way either.

>
> Well, maybe we just forget about this and split out .desktop files in the rare
> case where this is necessary. We already split out .desktop files when the
> app support for a mimetype depends on a plugin anyway (example: okularApplication_djvu.desktop)
>

We can say, this is the first step which is well better for having
something standardized and using current environment even if it's not
the best one we can find.
Then, maybe, we can moving on in the future for something handling
mime type specific priorities.

We don't have to forget that users/admins can overwrite those defaults
when the defaults doesn't fit their needs.

>> > Does gio ignore mimeapps.list files in other directories listed in XDG_DATA_HOME
>> > then?  (e.g. /usr/share/applications/mimeapps.list)
>
> Actually, thinking about it again, I'm almost sure Alex Larsson and I discussed that
> aspect, so it doubt it ignores those files.
>
>> 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 [right] with that definition? (I
>> understood it in this way in the spec)
>
> Yes.
>
>> > 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.
>
> In the simple case, yes, we could say "the preferred app for a given
> desktop environment can get the value X" (actually I would say 10
> rather than 5, see the list above of text/plain handlers, you can end up
> with quite a few lower-priority apps, and yet you want to order them
> correctly, so better have room under the preferred app).

I think nobody will claim against taking 10 :)

>
>> 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...
>
> Yes, assuming the gio people agree, of course; I didn't see them involved
> in this thread yet, but I don't want to "standardize" something without their okay ;)
> Alex Larsson told me at GCDS that he was quite busy this summer, you might
> have to ping him directly to get this moving forward.

In fact, we discussed during last UDS with Alex Larsson by IRC, so
he's aware of those wishes and wouldn't be surprised :)
I hadn't the time to tackle this item before and I preferred to speak
with you, fdo's guys to make something upstreamable and that can
benefit everyone :-)
As the spec changed slightly, I will ping him directly so that he can
give some feedbacks there.

>>  I'm ready to give the needed help to reach that.
>
> Oh, if you have time for this, maybe you could write the actual spec for mimeapps.list
> itself while being at it... better for the long run than "read the discussion between Alex
> and David on the list" ;-)

Does something (even just a start) has already been written for
mimeapps.list or do I have to just rely on the thread link I posted
yesterday? If there is no template, I'll get some inspiration on the
other similar specs.

> It certainly belongs to the same spec as the stuff we're discussing now; it's all part of
> the mime-apps association and priority issue.

Agreed.

Didier
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Wednesday 05 August 2009, Didier Roche wrote:
> Yes, that was the next step I was planning to discuss about (but the
> first implementation can be a first step until we find something
> better).
> In GNOME, IIRC, the order of applications showed in "Open with…" is
> just ordered alphabetically.

Well I object to postponing the issue, since we already implement this :)
In addition, multiple values are also necessary for handling uninstalled apps:

We can tell desktops to use 10 for the preferred app and less for others,
but if the preferred app isn't installed and a second-preferred app has 9,
it will lose against the other-desktop-environment's preferred app which
will be there with 10. No magic bullet there, some adjustment by the distro
will be necessary IMHO.

> > The other solution is to invent a way to specify per-mimetype initial-preference
> > in desktop files. We have a hack with an ugly syntax for this in KDE's .desktop
> > file parser, but I certainly don't want to see it standardized.
> > (For the curious, it's MimeType=text/plain;5;application/msword;9;
> > Yes, ugly and non-standard, but we just blame the one who had the idea ;) ).
>
> And this one is? :)
> More seriously, if we replace text/plain;5 by text/plain,5 it makes a
> little more sense (two kinds of separator). But it seems not to be the
> right way either.

The reason for using ';' was that existing parsers (e.g. from other environments)
would parse the mimetype names correctly, and ignore the numbers. If you make
it text/plain,5 then older parsers will see that as the mimetype name and nothing
will work.

> > Well, maybe we just forget about this and split out .desktop files in the rare
> > case where this is necessary. We already split out .desktop files when the
> > app support for a mimetype depends on a plugin anyway (example: okularApplication_djvu.desktop)
> >
>
> We can say, this is the first step which is well better for having
> something standardized and using current environment even if it's not
> the best one we can find.
> Then, maybe, we can moving on in the future for something handling
> mime type specific priorities.

I like that you're pragmatic and want to get things done asap ;)
However now is still the right time for solving this kind of problems,
if we deem them worth solving, before we build more things on top of
incomplete solutions (e.g. InitialPreference) -- and standardize those
solutions, which makes it even harder to move away from, later.

> We don't have to forget that users/admins can overwrite those defaults
> when the defaults doesn't fit their needs.

I can tell you that when we had postscript files opened in karbon by default,
rather than kghostview, because of the global-ordering problem (karbon's
initial preference had been increased for a totally unrelated mimetype,
and that made it preferred above kghostview even for its poor postscript import),
the users and admins didn't say "no problem we'll adjust it", they said "kde is buggy" :)

In fact that's the issue with the global initialpreference key; it doesn't only
break with conflicts (the A/B/M1/M2 case of my previous email), it also
means that the ordering is global (among all mimetypes), so it's easy
to make a change that breaks things (for other mimetypes).
So maybe we want to standardize on a better solution instead :-)

... but I don't really have one.

Well, if nobody else has a better idea, maybe we can keep the text/plain;5;image/gif;8;
solution, it certainly beats the fragile solution of
MimeTypes=text/plain;image/gif;
Priorities=5;8;
(which becomes unmaintainable with 30 mimetypes; a number that is not uncommon
with image viewers and multimedia apps).

> >>  I'm ready to give the needed help to reach that.
> >
> > Oh, if you have time for this, maybe you could write the actual spec for mimeapps.list
> > itself while being at it... better for the long run than "read the discussion between Alex
> > and David on the list" ;-)
>
> Does something (even just a start) has already been written for
> mimeapps.list or do I have to just rely on the thread link I posted
> yesterday?

We only have the thread[s] AFAIK.

> If there is no template, I'll get some inspiration on the
> other similar specs.

I don't really know about templates and the process for writing a spec overall
(we have them in CVS, and in a git repo that seems still unofficial), this is
exactly why I didn't write it ;). I'd suggest using shared-mime-info-spec.xml, I guess.

--
David Faure, faure@..., sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Didier Roche-3]

On Wed, Aug 5, 2009 at 11:24 PM, David Faure<faure@...> wrote:

> On Wednesday 05 August 2009, Didier Roche wrote:
>> Yes, that was the next step I was planning to discuss about (but the
>> first implementation can be a first step until we find something
>> better).
>> In GNOME, IIRC, the order of applications showed in "Open with…" is
>> just ordered alphabetically.
>
> Well I object to postponing the issue, since we already implement this :)
> In addition, multiple values are also necessary for handling uninstalled apps:
>
> We can tell desktops to use 10 for the preferred app and less for others,
> but if the preferred app isn't installed and a second-preferred app has 9,
> it will lose against the other-desktop-environment's preferred app which
> will be there with 10. No magic bullet there, some adjustment by the distro
> will be necessary IMHO.

That solution can only be reachable by distros at first glance. I
don't see solution at first glance a solution for this use case
directly brought by upstream.

>
>> > The other solution is to invent a way to specify per-mimetype initial-preference
>> > in desktop files. We have a hack with an ugly syntax for this in KDE's .desktop
>> > file parser, but I certainly don't want to see it standardized.
>> > (For the curious, it's MimeType=text/plain;5;application/msword;9;
>> > Yes, ugly and non-standard, but we just blame the one who had the idea ;) ).
>>
>> And this one is? :)
>> More seriously, if we replace text/plain;5 by text/plain,5 it makes a
>> little more sense (two kinds of separator). But it seems not to be the
>> right way either.
>
> The reason for using ';' was that existing parsers (e.g. from other environments)
> would parse the mimetype names correctly, and ignore the numbers. If you make
> it text/plain,5 then older parsers will see that as the mimetype name and nothing
> will work.

ok. The current parser just void the result if it doesn't look like a
true mime-type. Understood
- Show quoted text -

>
>> > Well, maybe we just forget about this and split out .desktop files in the rare
>> > case where this is necessary. We already split out .desktop files when the
>> > app support for a mimetype depends on a plugin anyway (example: okularApplication_djvu.desktop)
>> >
>>
>> We can say, this is the first step which is well better for having
>> something standardized and using current environment even if it's not
>> the best one we can find.
>> Then, maybe, we can moving on in the future for something handling
>> mime type specific priorities.
>
> I like that you're pragmatic and want to get things done asap ;)
> However now is still the right time for solving this kind of problems,
> if we deem them worth solving, before we build more things on top of
> incomplete solutions (e.g. InitialPreference) -- and standardize those
> solutions, which makes it even harder to move away from, later.
>
>> We don't have to forget that users/admins can overwrite those defaults
>> when the defaults doesn't fit their needs.
>
> I can tell you that when we had postscript files opened in karbon by default,
> rather than kghostview, because of the global-ordering problem (karbon's
> initial preference had been increased for a totally unrelated mimetype,
> and that made it preferred above kghostview even for its poor postscript import),
> the users and admins didn't say "no problem we'll adjust it", they said "kde is buggy" :)
>
> In fact that's the issue with the global initialpreference key; it doesn't only
> break with conflicts (the A/B/M1/M2 case of my previous email), it also
> means that the ordering is global (among all mimetypes), so it's easy
> to make a change that breaks things (for other mimetypes).
> So maybe we want to standardize on a better solution instead :-)
>
> ... but I don't really have one.
>
> Well, if nobody else has a better idea, maybe we can keep the text/plain;5;image/gif;8;
> solution, it certainly beats the fragile solution of
> MimeTypes=text/plain;image/gif;
> Priorities=5;8;
> (which becomes unmaintainable with 30 mimetypes; a number that is not uncommon
> with image viewers and multimedia apps).

I looked at vlc.desktop and totem's one. That's why I didn't proposed
ordering the Priorities entry in the same order than MimeTypes. It's
not manageable.

Hum, a solution can be:
- use a global Priority entry
- if we have a specific value for some mime-type to set. we can use
mime;priority; format.

For instance (I took vlc as it handles a lot of mime types):
Priority=10;
MimeType=video/dv;5;video/mpeg;7;video/x-mpeg;video/msvideo;video/quicktime;video/x-anim;video/x-avi;video/x-ms-asf;video/x-ms-wmv;video/x-msvideo;video/x-nsv;video/x-flc;video/x-fli;application/ogg;application/x-ogg;application/x-matroska;audio/x-mp3;audio/x-mpeg;audio/mpeg;audio/x-wav;audio/x-mpegurl;audio/x-scpls;audio/x-m4a;audio/x-ms-asf;audio/x-ms-asx;audio/x-ms-wax;application/vnd.rn-realmedia;audio/x-real-audio;audio/x-pn-realaudio;application/x-flac;audio/x-flac;application/x-shockwave-flash;misc/ultravox;audio/vnd.rn-realaudio;audio/x-pn-aiff;audio/x-pn-au;audio/x-pn-wav;audio/x-pn-windows-acm;image/vnd.rn-realpix;video/vnd.rn-realvideo;audio/x-pn-realaudio-plugin;application/x-extension-mp4;audio/mp4;video/mp4;video/mp4v-es;x-content/video-vcd;x-content/video-svcd;x-content/video-dvd;x-content/audio-cdda;x-content/audio-player;video/x-flv;

So, vlc will be associated with a 5 priority for video/dv and 7 for
video/mpeg. All others mime type will have the Priority entry value,
that is 10 in this case (and 1 if not specified).

Does that makes the syntax a little bit easier? (ok, I'm sure you will
tell me it's already working like that in KDE ;-))

>> >>  I'm ready to give the needed help to reach that.
>> >
>> > Oh, if you have time for this, maybe you could write the actual spec for mimeapps.list
>> > itself while being at it... better for the long run than "read the discussion between Alex
>> > and David on the list" ;-)
>>
>> Does something (even just a start) has already been written for
>> mimeapps.list or do I have to just rely on the thread link I posted
>> yesterday?
>
> We only have the thread[s] AFAIK.
>
>> If there is no template, I'll get some inspiration on the
>> other similar specs.
>
> I don't really know about templates and the process for writing a spec overall
> (we have them in CVS, and in a git repo that seems still unofficial), this is
> exactly why I didn't write it ;). I'd suggest using shared-mime-info-spec.xml, I guess.
>

Ok, I will.

Didier
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Thursday 06 August 2009, Didier Roche wrote:
> Hum, a solution can be:
> - use a global Priority entry
> - if we have a specific value for some mime-type to set. we can use
> mime;priority; format.
>
> For instance (I took vlc as it handles a lot of mime types):
> Priority=10;

InitialPreference=10, please, no point in changing the name of the existing key ;)
(no trailing ';', either, this isn't a list but a single number)

> MimeType=video/dv;5;video/mpeg;7;video/x-mpeg;[...]
>
> So, vlc will be associated with a 5 priority for video/dv and 7 for
> video/mpeg. All others mime type will have the Priority entry value,
> that is 10 in this case (and 1 if not specified).
>
> Does that makes the syntax a little bit easier? (ok, I'm sure you will
> tell me it's already working like that in KDE ;-))

Yes, this is _exactly_ how it works in KDE :-)

Well, maybe it wasn't such a bad solution after all :)

--
David Faure, faure@..., sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg