[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KFile plugins
From:       Luciano Montanaro <mikelima () cirulla ! net>
Date:       2005-10-16 12:08:57
Message-ID: 200510161409.09559.mikelima () cirulla ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 16 October 2005 11:13, Egon Willighagen wrote:
> On Sunday 16 October 2005 00:49, Luciano Montanaro wrote:
> > By the way, currently, all my mime types rely on the extension to
> > recognize the file content. This is not satisfactory, since, for example,
> > many z-machine games have a ".dat" extension, which is too generic to be
> > useful. So I would prefer using the magic file, but my experiments in
> > that direction do not seem to work. Do I have to specify anything
> > particular in the mimetype.desktop file to trigger file examination?
>
> Does KDE use this mechanism at all?

There is a class KMimeMagic in kdelibs/kio/kio/kmimemagic.{h,cpp}
that is supposed to do that. But I'm not sure it's used at all, in fact.

>
> > The file command already has the rules needed to identify the files, and
> > I tried adapting them to the `kde-config --prefix`/share/mimelnk/magic
> > syntax, but that does not seem to work on its own.
>
> Can you elaborate a bit? I don't quite understand how you wanted to glue it
> together and with what goal...
>

From what I gather, KMimeMagic uses a "magic" file modeled after
the one used by the "file" command. There is a smaller number of handled files 
than those currently handled by file itself, and I don't know if this is due 
to the magic file being unmantained or if the number of rules is kept low on 
purpose.

> > [lots of interesting stuff deleted]
> >
> > > Kat, which is told to be the working implementation of Tenor, or at
> > > least heads that way, *indeed* uses kfile plugins to extract meta info.
> >
> > Interesting. So these plugins will get much more use in the future.
> > While writing one of the plugin I was a bit concerned with the fact that
> > it should not do too much. For stuff like the file tip, you do not want
> > to scan a multimegabyte file... but if it is used in a low priority
> > batch, it could extract more informations.
>
> I totally agree there... Somewhere else in this thread someone proposed to
> put all file type related extraction in one plugin, but I agree that meta
> data extraction should be rather light weight...
>
> The chemistry kfile plugins I did only parse the first 25-ish lines or so,
> though there is one that reads the whole file too, which can be rather time
> consuming for larger files...
>
> Egon

Two of my plugins just read a few bytes from the beginning of the file.
The tads 2 and tads 3 files have an optional rich metadata section embedded
in the file, usually near the end, and it is necessary to parse the file 
structure to find out where the metadata begins. 
This kind of file is not usually too large, and there is not much processing 
done, but lots of seek.

But I had konqueror almost frozen when hovering on a kword (I think?) file 
once. 

The problem is that there are lots of file formats that do not make our life 
too easy. 

And there are "classes" of file types, e.g. files using the IFF file format, 
which could be handled by one single plugin, at least in principle.

Luciano 

 

-- 
Luciano Montanaro //
                \X/ mikelima@cirulla.net

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]