loud kfilemetainfo thinking
jpetso at gmx.at
Mon Jan 15 23:58:35 GMT 2007
On Tuesday, 16. January 2007 00:26, Jos van den Oever wrote:
> Hi all,
> You've probably looked at KFileMetaInfo and KFileMimeTypeInfo. In
> moving these classes forward to the semantic desktop, I think there is
> quite a bit of low-hanging fruit to be gotton by keeping large parts
> of the API but changing the implementation of metadata reading and
> I will give you a small idea of what i think should happen to these
> classes. In my opinion the prominent role of the mimetype should be
Note: It seems that Gnome developers also want to revamp the mimetype system,
even if a bit differently than you described it:
Maybe there's a chance to cooperate on this issue and keep improving the
fd.o mimetype database instead of undertaking a KDE-only solution.
> 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.
The mimetype already has this information in form of the X-KDE-IsAlso property
in the mimetype's desktop file. (For example, see any of the source file
mimetypes, say, kdelibs/mimetypes/text/x-java.desktop.)
One could make a point by saying that this information is not properly used,
but I wouldn't blame it on the mimetypes themselves.
More information about the kde-core-devel