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

List:       koffice
Subject:    Re: KWord filters
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-03-20 10:31:27
[Download RAW message or body]

On Tuesday 20 March 2001 08:04, Werner Trobin wrote:
> Unfortunately you are a victim of our sloppy mimetype handling. We
> "recognized" WinWord documents only by their .doc extension. As you
> probably know there are lots of .doc documents out there which aren't
> WinWord documents. Therefore Coolo removed the extension from the
> mimetype to highlight the problem and point out that this should be
> fixed. There has been some discussion on how it should be done, but
> up to now nothing happened, unfortunately.

I don't think this is Brett's problem, since he should have all the other
filters in the combo, and importing msword files should still work
(see below). But the problem you're raising indeed exists in CVS HEAD.

> I'm very clueless about this mimetype issue, but this has to be solved.
> David, Coolo, Simon,...: Any hint? I'd try to implement/fix it if you
> give me some pointers to documentation or tell me how it should be done.

There are two things here.
Recognizing MSWord files from their contents instead of their extension has
already been fixed, by adding the appropriate line to the "magic" file
(kdelibs/kio/magic). So if I open kword on a .doc file, it will recognize it
as such, and import it - and sometimes it will work :)

OTOH what doesn't work, is that:
since the mimetype doesn't have any pattern anymore (*.doc removed),
there is no entry for it in the file dialog's filter combo (I made kofiltermanager
skip an entry if there is no pattern for it because it would be quite useless
with the current file dialog).
What needs to be done is: using KMimeMagic (or KMimeType::findByURL
which ends up calling KMimeMagic when necessary) in the file dialog.
That is, allowing to recognize files by their contents as well as by their
extension, like Konqueror does, and like any program calling findByURL
does (for instance KoDocument, and that's why the actual import works fine).

The KFile authors (Carsten and Stephan) mention performance issues,
but in this case I think that exactitude is more important than performance,
and konqueror isn't that slow. It simply applies the "in depth analysis" in
a delayed way. KFile does that too, for the icons, but the problem is with
"filtering by mimetype" (the filter combo) : some files that initially were
not matching the current filter, will suddenly match it (because kmimemagic
says they are of that mimetype). So they will need to appear when they
are found as matching.
The other change is in the actual API, so that the app tells KFileDialog
which mimetypes this is about (currently there is only description and
"*.blah" pattern, not the actual name of the mimetype, that would then be 
needed).

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

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