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

List:       kde-commits
Subject:    Re: proko2: kdepim/kmail
From:       David Faure <faure () kde ! org>
Date:       2005-04-11 17:23:14
Message-ID: 200504111923.15357.faure () kde ! org
[Download RAW message or body]

On Sunday 10 April 2005 14:18, Ingo Klöcker wrote:
> On Saturday 09 April 2005 14:18, Marc Mutz wrote:
> > CVS commit by mutz:
> >
> > Add "Decrypt With Chiasmus..." action to context menu of .xia
> > attachments. I am so fed up with this hack that I consider making a
> > plugin interface for this kind of mimetype-dependant attachment
> > context menu entries.
> 
> Since this is very much the same as mimetype-dependant file context menu 
> entries in Konqueror we should think about making use of the 
> infrastructure that already exists. The problem with simply showing the 
> same entries as Konqueror is that some actions might not make sense in 
> the context of KMail, e.g. "Encrypt File", "Create foo Archive" don't 
> make sense. So we need a way to distinguish reasonable actions from 
> nonsensical actions. Maybe a special KMail-specific entry in 
> the .desktop files?
> 
> Of course, this only makes sense for actions which involve external 
> applications. I guess "Decrypt With Chiasmus" should be done by KMail 
> itself(?). Could we probably still use the existing .desktop file 
> infrastructure in this case somehow? I really don't want to duplicate 
> the complete file association infrastructure for KMail.

There are three things.

* File associations. That's about associating external *applications* to files, by their 
mimetype, like what happens in konqueror, and what kmail uses for RMB/Open and Open With.

* Service menus. "Encrypt file" and "Create foo Archive" are konqueror-specific servicemenus
(they are even stored in share/apps/konqueror/servicemenus), so completely unrelated to kmail.
Of course they are just another incarnation of "a .desktop for a mimetype" kind of thing,
but anyway those are, like file associations, about launching external apps given a file or URL.

* App plugins. It sounds to me like what you want is not to launch external apps,
but to kmail plugins. This decrypt-with-chiasmus thing is kmail code, which could possibly
become a plugin, but not really an external app, right? (e.g. if the result of the decryption
has to be shown inside kmail...)

I think that all you need is to apply the standard "defining a plugin system for my application"
mechanism: a plugin base class (interface), a servicetype, .desktop files for the plugins,
and filling the popupmenu for an attachment by doing a KTrader query.

http://www.klaralvdalens-datakonsult.se/~dfaure/n7y/Trader/index.html


In addition to that, you can always add items based on file associations (trader query for "Application")
if you want something more precise than RMB/Open, and if you were thinking about
service-menus, I see increasing demand for making konq's servicemenus available
more widely, but that needs some thinking about how to only show the right ones
in each application, which seems a bit tricky. From your examples above it looks like
a distinction is that kmail wants readonly servicemenus only, i.e. not those which
transform an input file into an output file. Well, this flag is already in the
servicemenus, I called it X-KDE-Require=Write. So you should only look at the
servicemenus which konq pops up in a readonly directory.
But this is totally unrelated from kmail having its own plugins for treating data
directly in kmail, let's not mix both things :)

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

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