[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic