--===============0527767928==
Content-Type: multipart/signed;
  boundary="nextPart1620849.mO8kD7NCEO";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1620849.mO8kD7NCEO
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 exampl=
e,
> > 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...
>

=46rom what I gather, KMimeMagic uses a "magic" file modeled after
the one used by the "file" command. There is a smaller number of handled fi=
les=20
than those currently handled by file itself, and I don't know if this is du=
e=20
to the magic file being unmantained or if the number of rules is kept low o=
n=20
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 inf=
o.
> >
> > 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 ti=
me
> 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=20
structure to find out where the metadata begins.=20
This kind of file is not usually too large, and there is not much processin=
g=20
done, but lots of seek.

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

The problem is that there are lots of file formats that do not make our lif=
e=20
too easy.=20

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

Luciano=20

=20

=2D-=20
Luciano Montanaro //
                \X/ mikelima@cirulla.net

--nextPart1620849.mO8kD7NCEO
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBDUkLlaeOY6B53J4URAuT7AKC5yrVy8DTwvtWH7Z5nBv6BbyOZ8wCfR3vQ
xBw8C0ZAybFiLVaCZeks3p8=
=wa2A
-----END PGP SIGNATURE-----

--nextPart1620849.mO8kD7NCEO--

--===============0527767928==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0527767928==--