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

List:       kde-devel
Subject:    Re: KFile plugins
From:       Thomas Kadauke <tkadauke () gmx ! de>
Date:       2005-10-16 16:46:49
Message-ID: 200510161846.49582.tkadauke () gmx ! de
[Download RAW message or body]

Am Sunday 16 October 2005 17:38 schrieb Egon Willighagen:
> What if some other program uses this extension too? I don't know other mime
> types that use *.h, but have seen other clashes... (think of .log)
>
> extension -> mime type is not the option KDE (4.0) should aim at... IMHO

I agree. Guessing the file type from content won't be a problem, because in 
KDE 4 files will be indexed anyways. So if you hover over a file in 
Konqueror, the meta information will be extracted from the Tenor database, 
which means Konqueror will only block if for some reason the file is not yet 
in the index.

My proposal for KFile-plugins in KDE is:

- a KFile plugin is responsible for extracting ALL information from a file, be 
it meta information or full text.

- There should be a quick way that a KFile-plugin can tell if it supports 
parsing of a given file, regardless of the filename pattern.

- there should be several different modes for extracting information. If the 
background indexer searches for information, it should extract all possible 
information. If Konqueror wants to know meta information of a file not yet 
indexed, a KFile plugin should extract all meta information. In addition, the 
file should be scheduled for full examination by the background indexer.

- KDE should be fully aware of the semantics of any file in the filesystem (or 
at the very least in the user's home directory). For example, KDE should know 
the table of contents of an oo.writer file, or the list of methods in a Java 
class. This also means that KFile-plugins for source files of some 
programming language need full-blown parsers (note: for background indexing).

- different information should have different priorities assigned. If I'm 
looking for some string which is part of a document's table of contents, then 
this is definitely more important than some full text in some webpage I 
browsed a couple of weeks ago. I think (but this will have to be tested) that 
full text information is less important that other textual information (such 
as "Author", "Table of Contents" etc.)

For example, if a header file (*.h) is found by the indexer, the following 
should happen:

- Based on some magic detection, a list of possible KFile plugins which could 
handle the file is determined.

- The filename pattern should be used as a hint for which KFile plugins to try 
first. This will result in the C, C++, and ObjC parsers. For the pattern 
*.hpp, the C++ parser would come first.

- The file is parsed by the KFile plugins in the list. On first success, the 
process stops.

Please tell me what you think,
--Thomas
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]