Re: Mime Type Analysis

[David Faure <david mandrakesoft com>]

On Friday 01 December 2000 14:21, Maciej Stachowiak wrote:
> 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.

This is still unflexible :-)
It's very related to this :

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

In KDE 1 we used to store the default application for a mimetype in
the mimetype desktop (.kdelnk at the time) file. This is, as you say,
an easy way to have the desktop "provide sensible defaults".
But then it turned out that this was really unflexible. For instance,
if someone installs parts of the desktop only, then he's going to miss
the application that is said to be the default, and then there's no
way to tell which other app should be preferred if that one is
not there. That's what InitialPreferences are for. As part of the
desktop files provided by the desktop, those including an initial-preference
determine the defaults for the desktop, but in a more flexible way
than having an app's name in the mimetype file. If the app
isn't installed, there's no mention of it anywhere.

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

No, sure. I was talking about for instance the desktop files that would
come from the common repository on freedesktop. I don't think that for
instance xedit should be shown as default. Actually, both concepts are
quite wrong - they rely on something better being there. Just like in
your reduced list, if none of those applications are installed, then the
resulting list is empty.
Once again, the concept of an initial preference solves this, because
if the top 10 apps aren't there, the 11th one is still going to appear.
It's all about defining an order, in fact.

But I see your point about the order being decided by the desktop people
and not by the application authors...... Hmm. In the end it's more the 
distributor that should set that up...

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

Ah I see.. Well, that's obviously something that we don't have in KDE,
and I'm not sure we want to go that way. To me, categorising people
never really works, so all users are equal, they all get KWrite :-)
Well, let's not go there. If you "import" KDE settings, then they would
be imported the same into the tree level, and the other way round,
if KDE "imports" settings from gnome, then it should take the ones 
corresponding to the user's settings (level).

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

It's interesting how much this seems to be a problem for you,
when it hasn't been one for us, even know that KDE 2 is out ;-)
I think the point is that there aren't that many KDE apps that 
duplicate each other's functionality, so they don't "fight for
the same mimetype". And all those in CVS are centrally controlled
anyway, so no problem there. Those not in CVS might come with
a high initial preference because the author wants it so, but that's
logical too. If I download application xyz, I want to use it :-)

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

The only difference here seems to be that we don't have a global
profile, but that the global settings are more scattered into the desktop
file, for more flexibility.

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

Ok, I think the most important is indeed to determine "what do we want".
We said we don't want to share the same _default_ associations
(between mimetypes and applications), those should remain desktop-dependent.
But we would want to share
* the application definition (desktop files) - we almost do that already
* the mimetype definition. Well IMHO we should share them, but you didn't
seem convinced :)
* the _user_ preferences for which application should be preferred for which
mimetype. Sounds like the profile thing for us and the .keys files for you.

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

Yes, the components aren't compatible anyway, so this should probably
remain specific.

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

Yes, sorry, that's what I meant. It's a magic file with the same syntax as
the one used for "file", but with mimetypes instead of english names.
It actually comes from apache...

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

Well, if you keep all of them in the same directory in the sources
(for us it's kdelibs/mimetypes), maintaining is not a problem.

> Gnumeric can open Excel files, I assume KSpread can too (or will in
> time).
Yes, it can. Ok, good example then :-)

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

But if the mimetype definition comes with "this is the mimetype for *.kwd",
it's very easy to support it directly... I'm not talking about the magic file 
here. A simple recognition based on the extension is easy to do.

I guess this is where we have to choose between centralising the
mimetype definition, or importing each other's. And to avoid
"make install" overriding the other desktop's files, I guess you're right,
it's simpler to keep them separated and to import the other desktop's
files for complementary information. It's a lot less nice though.
Imagine a third desktop comes into the picture... Huh.

IMO it would be better to use the exact same mimetype files (i.e. exact
copy in both CVSs, and a flag to not install them if they're already there,
for distributors).... Otherwise (if we just "import" stuff from the other desktop),
we'll end up with crap like image/png vs image/x-png, etc.

> 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).
I am sometimes, but I think it's better if those discussions remain public,
so that others can participate. For instance, I was only planning to explain
a bit better the gray areas in Kurt's initial post (like the user profile), and I
end up trying to design a solution, but I was hoping he would be the one
working on that :-)

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