Re: Mime Type Analysis

[Maciej Stachowiak <mjs eazel com>]

David Faure <david mandrakesoft com> writes:

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

Yes, but for common mime types, the desktop probably knows the top few
best choices for that desktop.

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

You could do that, but if you're writing an app, would you ever put
InitiallyHidden=true in your own .desktop file? I know I wouldn't. So
I think it's better to have the system specify a preferred set of
apps, then for app authors to be expected to decide their app should
be hidden.

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

Sorry, I was a bit unclear here. Nautilus (and soon, GNOME) has a
concept of user levels: Beginner, Intermediate and Expert. At higher
user levels, more detail is shown in the UI, while at lower user
levels more settings are hidden and things are kept simpler. The way
this applies to applications is that the default for beginners might
not be the same for experts. For instance, in GNOME we might want
gedit as the default for beginners, but vi as the default for experts
(it's not really set up that way, but this is an example).

I didn't mean configuration by the actual end user, which is a
separate issue.

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

That's pretty nice. We also allow customizing anything that is set in
the database (although our control center applet for this is currently
not as nice as KDE's). However, most users never change the
defaults. So getting the defaults right is crucial. I guess when I
speak of centralizing the information, I mean centralizing the
defaults, and not trusting app authors to decide for themselves how
important their app is relative to others by default.


> The format of the profile file is currently something like
> 

[... snip ...]

We keep this information in more or less the same format as the system
default and app-provided .keys files; arguably this is an advantage
we'd want to carry over to a new system for user preferences.

Do you think making mime setting preferences also shared between the
two desktops is worthile? In some ways it seems like that might have
more value than sharing the defaults, in some ways. I was considering
using GConf for this for GNOME 2 so we can have live updates and the
like, and configurable back ends, but I think KDE interoperability is
more important if we can manage it (I imagine even Havoc would agree).

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

See above for what I meant by 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.

I don't think that will map at all well to how GNOME does things. (The
GNOME system for activating components keeps a bunch of
meta-information about the component, including implemented IDL
interfaces and such in XML files and allows SQL-style queries based on
component attributes, but specifying the preferred components for a
mime type is done by the mime database, not the component database).

We'll just have to make sure the system can have desktop-specific
extensions for components and other such things.

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

We don't use the magic file provided by file, we use one that maps to
mime types (I assume KDE does something similar).
 
> > * 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.

It's not about installing, it's about maintaining. It's more effort to
look throguh hundreds of files instead of just one to change some
application settings. I admit this is not a huge issue though, and it
doesn't matter that much to me.

> > 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 :-)

Gnumeric can open Excel files, I assume KSpread can too (or will in
time).

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

Great! Havoc tells me there is cvs space available at freedesktop.org,
so this will be easy to do when the time comes.

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

No, I don't think it would - if GNOME doesn't recognize the mime type
natively, it looks in KDE's database.

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

But that means we'd have to keep preferred/default application
mappings separate from mime types - this is somewhat annoying, but I
guess livable.

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

Excellent! Are you ever on IRC? Would love to chat about these issues
sometime (although I don't know where the right location to talk about
them would be).

If we can get this resolved, it will be a huge step forward for
GNOME/KDE interoperability.

I'm really looking forward to it!

Maciej