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

List:       kde-devel
Subject:    Re: KFile plugins
From:       Egon Willighagen <e.willighagen () science ! ru ! nl>
Date:       2005-10-15 19:21:18
Message-ID: 200510152121.18966.e.willighagen () science ! ru ! nl
[Download RAW message or body]

On Thursday 13 October 2005 17:59, Thomas Kadauke wrote:
> Recently, I uploaded several KFile plugins to kde-apps.org:

Hi Thomas,

interesting reading below... I'm working (with a few others) on kfile plugins 
too, in the field of chemistry. First KDE work too:

http://www.kde-apps.org/content/show.php?content=28995

(the sources are in SVN in playground/utils/kfile_chemical/)

<snip>

I also did a kfile plugin for R (www.r-project.org) in 
playground/base/kat/src/

> I got several requests to include these plugins into the main KDE
> distribution. However, I'm new to KDE development and don't even have an
> SVN account for that. So if you think these plugins are useful, feel free
> to include them into KDE SVN.

I do have a SVN account, but was wondering about this... is there any policy 
on where the plugins would go, and who decides when they can go into 
mainstream KDE?

At this moment the source is in playground/utils, and for now I'm perfectly 
fine with that, but it would like to aim at inclusion in a few months, and it 
would be nice to know the requirements in advance...

Thomas (or anyone on this list), do you know how that works, or where some 
docs on this are? 

> While implementing these plugins, I encountered several problems/bugs:
>
> - Documentation. To be honest, the documentation for KFilePlugin et.al.
> sucks. Most of the interesting methods are not documented at all. This
> wouldn't really be a problem, were there a descent tutorial about KFile
> plugins. This is *really* needed, because a KFile-plugin is *the*
> opportunity for KDE/QT-newbies to produce something useful quickly without
> digging too deep into kdelibs. But since complaining isn't helping anyone,
> I volunteer on updating/completing the relevant documentation.

How do you document your plugins? Just ApiDox, or did you write user 
documentation too? I've started a bit of that, but could not find any kfile 
documentation in the KDE help... where should I look?

> - Four of the five plugins deal with text files. I'm planning on writing
> even more kfile-plugins, among them: kate-project, python source, quanta
> webprj, icalendar, docbook, rtf, java, vcalendar (if not already there) and
> vcard (if not already there). All these are actually (more or less)
> human-readable text files. So these could benefit from the meta information
> of the generic kfile_txt plugin that extracts line count, word count, etc.
> However, the current KFile/KDE API does not permit
> "mimetype-specialization", which would be needed to e.g. declare a
> text/x-latex file to be a specialization of text/plain. This would also
> solve the file association problem when e.g. a new text editor is installed
> and you want to update all text-based formats to use this new editor.

Is there a overview of what plugins are exactly available already?? So that we 
do not duplicate work?

> - What happens if two mimetypes contain the same filename pattern? AFAICS,
> this is handled on a first-come-first-serve basis. 

Good point. Some of the plugins I work on are for mime types which use file 
extensions used by other mime types too...

First-come-first-serve is not the way to go.

> This, however, is not 
> satisfactory, as e.g. the types text/x-tex and text/x-latex contain the
> same pattern (*.tex), but are completely different in nature. I'm proposing
> to use the filename pattern only as a hint, and determine the actual
> filetype based on the content.

<snip>

> - I guess Tenor in KDE4 will use KFile-plugins (or whatever there will be
> for KDE4) to extract meta information from files. However, the current API
> is not sufficient for that. 

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. 

> Say that I'm a java-programmer who uses Javadoc 
> and want to use the KDE search-tool to look for a certain Java-method. I
> know that I just could use the fulltext search from text-files but that
> will most probably return a lot of noise, 

Agreed. But note that full text is dealt with differently in Kat than meta 
data.

> when the generated documentation 
> is searched. So here the kfile-plugins should be able to extract a list of
> Java-Methods from a Java-file (it would be cool to even extract the method
> signature :) and assign a high priority to that information, since it's
> more relevant than the same words in the documentation. Right now, they are
> restricted to extract only a summary of a file's content (such as the
> number of methods in a java file, which is rather uninteresting)

<snip>

> So I'm proposing the following (for the upcoming KDE4, obviously):
>
> - use the filename pattern as a hint for the mimetype, especially when no
> context is given (e.g. in konqueror). When a context IS given (e.g. in
> krita, you're most probably dealing with image files), but the pattern is
> unknown, try a context-specific list of mimetypes based on the file
> contents.

I had the feeling that the file browser determines the file type, and the 
right kfile plugin is then picked based on this file type as represented as 
the mime type.
 
> - use a KFile-plugin to determine if the contents of a file match the
> mimetype, regardless of the filename pattern.
>
> - allow mimetypes to be a specialization of another mimetype (I think there
> is no need to allow "multiple inheritance"). The benefit here will most
> obviously be in text files. But it would also help to extract meta
> informtaion from all these XML-based file types out there. The KFile-plugin
> for a more specialized mimetype must extract all information that the
> KFile-plugin for the less specialized mimetype claims to extract.
>
> - allow kfile-plugins to extract lists of meta-information (see above).
> This could be generalized to the full text extraction: the kfile_txt plugin
> could extract the meta-field "words" which contains the list of word in the
> documents. Besides, you get the word count for free.

Kat uses full text plugins for this. Having those in different plugins is a 
good decision I think, because the will be heavier weight than meta data 
plugins.

> - allow to assign a priority to meta information. The more specialized a
> mimetype (and therefore a kfile-plugin) is, the more important tends the
> extracted information to be.
>
> OK, i guess that's it for now. Please tell me what you think. And thanks
> for your patience :)

Good thought, thanx for bringing it up. I can appreciate these issues as I am 
new to KDE too, and was struggling with similar things.

Egon

Disclaimer: I'm (rather part-time) participating in Kat development.

-- 
e.willighagen@science.ru.nl
PhD student on Molecular Representation in Chemometrics
Radboud University Nijmegen
http://www.cac.science.ru.nl/people/egonw/
GPG: 1024D/D6336BA6
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]