Have a way to dynamically change software associations at distribution level

[Alexander Larsson]

On Wed, 2009-08-19 at 19:15 +0800, PCMan wrote:
> Here are some comments.
> On Wed, Aug 19, 2009 at 5:15 PM, Alexander Larsson<alexl at redhat.com> wrote:
> > The current system works by each desktop having its own way of
> > specifying the default (if the shared user and sysadmin preferences
> > did not take effect). Incidentally the gnome version is static and
> > some people want to make it dynamic, but this is not inherently
> > connected with standardizing/sharing how this is done, so lets ignore
> > that for now.
> But we still have a common way for other desktops or window managers
> who don't have their own way to set defaults.

Not sure what you mean here.

> If we are going to solve the "common way to set defaults" problem now,
> can we solve the problem with "default web browser and terminal
> emulators" at the same time? This is just as important and more or
> less a similar issue with the currently discussed one.

I have nothing against solving this issue. But I do have something
against "solving" it by hacking up the mimetype system by adding fake
mimetypes. This will lead to even more confusion to what mimetypes are
as these type end up in weird places, plus its not certain that they
have exactly same requirements as mimetype defaults, so it needs a bit
of research. The result may be similar, but please don't use the
mimetype system for it.

> Agree with this proposal. Other projects from Portland project like
> xdg-utils can also benefit from this. For us, currently we use
> environment variable DESKTOP_SESSION in LXDE. Having
> XDG_CURRENT_DESKTOP is a good idea. But what if the users don't use
> any DE? Some poeple are still using fluxbox, window maker, or
> icewm...etc?

If you don't use a WM then by default no env var is set and all the
priorities are combined into a shared priority space. If you have one of
the desktops installed and prefer their apps you could also manually set
the env var.

> > * I don't believe in sharing the default priorities between desktop as
> >  some kind of global property that has to be negotiated between
> >  desktops, etc. The priorities are often used in-desktop to
> >  differentiate between two different apps in one desktop, and this
> >  doesn't work well if the same priority scale is used by another
> >  desktop too. (See the nautilus in kde example above.)
> > Where does this leave us? One possible solution would be to tag each
> > application with a set of desktops that is was "designed" for
> > (DesignedFor=KDE). I.e. it would be KDE in core KDE apps, unset in
> > "normal" apps and possibly have both KDE and GNOME in some special
> > distro things that want to override desktop specific core apps in both
> > distros.
> I would prefer using existing and backward compatible solution rather
> than introduce a new key.
> Categories=KDE; or GNOME; basically can solve this already.

Categories already have a very specific usecase. They are for menus. I
don't think we should mix them up, as then changing menus affect
mimetype defaults and vice versa. Furthermore, take the example of
firefox for a distro with it as default. The distro would patch it to
say DesignedFor=gnome;kde; which makes no sense for a category.

> > Implementation wise this could be done pretty simply by storing for
> > each mimetype implemented by a desktop file both the mimetype as-is,
> > plus a copy of it prefixed with each of the DesignedFor keys. So, we'd
> > do lookups for defaults first by looking for e.g. "KDE-text/plain" and
> > then "text/plain".
> This would make things even more complicated. Properly setting
> Categories can already solve this. Under GNOME implementation should
> give applications with Categories=GNOME; higher priority, and vice
> versa in KDE. This can cleanly solve the problems when two apps have
> the same priority. The only concern was performance since search in a
> string list is slower than direct comparison of two strings. However
> the difference is minimal in real world use case.

The performance difference is not at all wrt string searches. The
difference is that to do the category comparison you need to read all
the desktop files and look at the category, while a KDE-text/plain
lookup would not do that. This is important since a file read is very
very very much slower than any kind of cpu matching you can imagine.

> Besides, I think desktop-utils can also create a cache named
> categories.cache with content like this.
Yes, you can of course add an extra file with the same info, but its
more files to read and more lists to keep in memory. Prefixing with the
desktop name is fully backwards compat with deployed file formats, and
needs no extra files, which is why I like it.