loud kfilemetainfo thinking

[Jos van den Oever]

2007/1/16, Thiago Macieira <thiago at kde.org>:
> Jos van den Oever wrote:
> > In my opinion the prominent role of the mimetype should be
> >abandoned. We cannot continue working on the assumption that mimetype
> >always accurately predicts which files contain which fields and that
> >one mimetype maps to one KFilePlugin. A mimetype is just one of many
> >metadata that can be associated with a file. It is well possible that
> >a file has multiple mimetypes. An openoffice text document arguably
> >also has the mimetypes application/x-zip and application/octet-stream.
> >When getting data from this file you might be interested in the
> >zipfile aspects of it.
>
> I can accept that as long as there is one main MIME type. Whenever we need
> to deal with the file in a context-poor medium (for instance, if we're
> mailing it) we need to know the official MIME type for the file.
>
> Other things that we now associate with the MIME type (icon, actions,
> especially the "open" action) can probably be better told by the semantic
> desktop. Or, at the very least, from the many MIME types possible.
Yes, the semantic desktop should e.g. know which applications that can
accept the specific file are running and what type of actions are
available to them. Initially, this behavior must use the mimetype. One
could image a dbus call to running apps like this:
     getPossibleUsesForFile(QString/KUrl/KFileMetaInfo)
Using the mimetype database for this would, however make more sense
for simplicity and performance.

> Also note that KDE has had for a while the IsAlso relationship of MIME
> types. So, having multiple MIME types for a given file is not new. Nor is
> there being a main type.

This is new to me and from the top of my head is cannot thinks of a
file that has two mimetypes that do not have an IsAlso relationship.
This means the list of mimetypes in KFileMetaInfo could be sorted to
put the main mimetype first.

> What bothers me is the implication that your work has on the file
> association database. In theory, we want(ed) to switch to the fd.o MIME &
> file type database. So, please clarify this subject: how does your work
> and Sebastian's work affect the MIME & file association database?
I think that in most cases the associations from that database hold
and that more detailed information could be added there or in nepomuk
about what certain files can do with a specific file in a certain
context. E.g. if user is running KWord, the default action would
presumable be to open an ODT also in KWord. Or when xmms is running,
maybe an mp3 should maybe be enqueued to it as a default.
Such ideas have UI implications: this behavior should be clear to the
user and sensible. So in the near future the behavior as it is now
should be preserved.

I would prefer a solution where the executable associations end up in
a KFileMetaInfo and not in a KFileMimeTypeInfo. Most of the
information would come from a file association database, however.

Cheers,
Jos