Re: Mime Type Analysis

[David Faure <david mandrakesoft com>]

On Friday 01 December 2000 06:44, you wrote:
> 1) Allowing a preference list for apps and components to handle
>    various types, based on availibility; this means if the most
>    preferred app for a type is not on the system, the next most
>    preferred will be used, etc. This approach allows this to be done
>    in a centralized way, as opposed to having each app specify it's
>    own priority, which trusts all app authors to set an appropriate
>    priority independently.

This is interesting. It's probably one of the flaws in the KDE system:
the fact that we trust application authors with the initial preference.
OTOH, it's the most flexible solution (i.e. the desktop doesn't have
to know about all the applications out there).

> 2) It provides a reduced list of applications for a mime type that can
>    be displayed in an Open With menu by Nautilus or other apps. This
>    means that if you have 100 text editors on your system, you won't
>    by default get an unusable menu with all of them in it (although of
>    course, which show up in the list is configurable by the user).

This is an interesting idea too. No need for a global list for that, though.
The application's desktop file can come with "InitiallyHidden=true" or so.

> 3) It allows specifying these things per user level; although right
>    now only Nautilus uses user levels, this concept will become
>    GNOME-wide in time.

Everything in KDE is configurable at the user level. All those desktop
files (mimetypes and applications, servicetypes and services) can be
overriden in the user's directory.

> Looking at the description for how KDE does things, I have a few
> specific concerns. The first few are technical issues with the
> contents of the format:
> 
> * We like having application defaults and priority order per mime type
>   kept centralized with the info about the mime type, rather than
>   decentralized and kept with the info about the applications. This
>   allows a consistent set of default applications to be carefully
>   thought out, instead of trusting app authors not to fight over who
>   gets a higher InitialPriority.

Kurt forgot to mention something quite important. Let me explain a bit
more how the application (generally, service) selection works.

There is a "user profile", which is ~/.kde/share/config/profilerc.
This profile is created when the user changes its preferences for
a given mimetype. The profile basically stores :
for this mimetype, the user wants to see the applications A, B, C
and not D, and he wants them in that order.

The InitialPreference is only _initial_, as its name says. It's the
default order, used in absence of a profile.

So yes, we do centralise this information too. The InitialPreference
field is only there to ship sensible defaults.

The format of the profile file is currently something like

[application/pdf - 1]
AllowAsDefault=true
Application=Graphics/kghostview.desktop
GenericServiceType=Application
Preference=3
ServiceType=application/pdf

[application/pdf - 2]
AllowAsDefault=true
Application=WordProcessing/ghostview.desktop
GenericServiceType=Application
Preference=2
ServiceType=application/pdf

[application/pdf - 3]
AllowAsDefault=true
Application=WordProcessing/acroread.desktop
GenericServiceType=Application
Preference=1
ServiceType=application/pdf


This is the "application" section, i.e. which application to launch when
clicking on a pdf file. As the preference field shows, kghostview is preferred
above ghostview, which is preferred above acroread.
The group names are dummy, they are just here to improve readability.

[application/pdf - 4]
AllowAsDefault=true
Application=Graphics/kghostview.desktop
GenericServiceType=KParts/ReadOnlyPart
Preference=1
ServiceType=application/pdf

And that one defines which component (KParts/ReadOnlyPart)
should be associated with PDF files, so that konqueror - and any
other KParts application - finds the preferred component to load.


> * We like having things per-user-level; it's likely that different
>   defailt apps are appropriate to an expert vs. a novice.

Sure, any desktop file can be changes at the user level.

> * We like being able to specify the bonobo components desired for a
>   given mime type (and I'm sure KDE likes having the same feature for
>   KParts).

We haven't talked much about it, but the way it works in KDE is :
a "servicetype" is the generalisation of the "mimetype" concept.
An example is "KOfficePart", which is the servicetype that all
KOffice components implement. The component itself is a "service",
and it's associated to servicetypes (and to mimetypes).

The profile actually contains a section for mimetypes->applications
and one for servicetypes->services.

> * It seems to me that there is value to specifying how to detect files
>   as of a given mime type separate from describing the properties mime
>   type (icon, apps, human-readable name). This needs to be doable both
>   for extensions and for magic strings (perhaps we will want to keep
>   the magic string aspects non-portable between the desktops...)

We use the "file" magic file for this, and I guess Gnome does too.
This is centralised too. The extensions are part of the mimetype .desktop file,
though, obviously.

> * Being able to specify a bunch of mime types in one file is appealing
>   for people trying to create a system default.

This is just the same as installing a bunch of mime type desktop files.
I don't see why installing them in a single file makes it any easier.

> The next few are semi-political issues arising from sharing this info:
> 
> * Each desktop needs to be able to specify preferred and default
>   applications by itself. The last thing we need is huge political
>   fights over whether gnumeric or KSpread is the default spreadsheet
>   program. So these settings need to be per-desktop, not global.

That's a very good point, and it's the reason why the current "standard"
isn't enough anyway. There needs to be a way to select the preferences
per desktop. Hmm, maybe it means the profile could be desktop-dependent.
But this wouldn't be nice, it breaks the whole idea of configuring one's 
associations for both desktops at once. Maybe it's rather the initial preferences
that should be desktop dependent.

Actually, gnumeric and kspread don't have the same file format, so
the example isn't really well chosen. But take any text file, or image,
and the problem appears :-)

> * Each desktop may want to provide .desktop files for legacy
>   applications that don't ship with them. We need to avoid having
>   install conflicts when it happens (one way might be to have a
>   project hosted by freedesktop.org that both KDE and GNOME people
>   contribute to which is .desktop files for random apps that don't
>   have them).

Very very good idea. I definitely support that.

> I'd like to find a way that we can address these concerns and still
> have compatibility (most likely by using a .desktop-based
> approach). Any ideas? One starting point I can think of is that each
> desktop has it's own database of info about mime types installed in a
> desktop-specific location (with fallback to the mime type database of
> the other desktop if the mime type is not known natively), but
> information about applications is shared and installed in a common
> location, since the way that is stored is less likely to be
> politically controversial. Just a starting point to kick off
> discussion...

Why do it this way ? An application that provides its own mimetype
(e.g. application/x-kword) would have to install it in both locations.
This defeats the whole idea, doesn't it ?
I think it would be better to share the mimetype definitions, so that
when a mimetype is known to the "system", it's known by both
desktops.

> BTW, I was never involved in the original Desktop Entry Standard, but
> I am the person who is responsible for the current incarnation of the
> GNOME mime code, and most likely for future incarnations, so I think
> you can trust my promise that anything we agree to here will be
> implemented for GNOME 2.

And I have implemented a good part of the current system used by KDE
(maintaining and bugfixing Torben's design, rather :-)
so I'll be happy to improve it again towards a common solution.


-- 
David FAURE, david mandrakesoft com, faure kde org
http://www.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today
See http://www.kde.org/kde1-and-kde2.html for how to set up KDE 2