Bug 72010

Oh. Definitely! I created bounce aliases for this purpose, but still need mutt because KMail does the "by the way of" mangling.

Subject: Re:  New: Context menu plugin system like KonqPopupMenuPlugin, Please

You can do this by creating an ad hoc filter (one with a condition 
that always matches) and checking the 'Add this filter to the Apply 
Filter Actions menu' in the filter dialog. Then in the context menu 
in the reader window an apply filter actions menu will appear with a 
submenu for each ad hoc filter.

I realize this is clumsy UI wise I'm definitely open to advice on how 
to improve the UI here. The best I can probably do now is to document 
the existing behavior.

Having said that I would love to support plugins for the context menu 
as suggested. I think in the long run this could be a great 
combination of XMLGUI and dcop.

Don.

As Don said that's already possible in KMail 1.5.94+. I don't think that we need a plugin system for this and propose to close this wish.

He said it was a clumsy way of doing it. Is it your plan to make KMail a clumsy app to use?

Not FreeBSD specific.

Subject: Re:  Context menu plugin system like KonqPopupMenuPlugin, Please

Am Wednesday 07 January 2004 22:41 schrieb Neil Stevens:
> He said it was a clumsy way of doing it. Is it your plan to make KMail a
> clumsy app to use?

Oops, it were the maintainers of KMail which were discussing the current 
possibility to use the menu item. Be sure that work is already on the way 
to make the UI better, but coding takes some time.
If you can come up with a serious patch pretty fast, then they certainly 
will appreciate your contribution.

@Ingo, I'm aware of the menu item problem and try to solve it by at least 
establishing toolbar buttons for the spam/ham definition. So we could 
really close the wish.

If you're going to close it, make sure you close it WONTFIX as a message to anyone else who wants KMail plugins.

What's with the aggressive undertone, Neil? Plugins are completely unnecessary for the use case you gave. With the KDE 3.2 version of KMail you can easily setup toolbar buttons to mark messages as spam or ham and to teach the spam filter program of your choice. The post-3.2 version will have a Spam Filter Setup Wizard which solves the problem that setting the actions up is a bit involved currently.

Please come up with a use case that can't be solved with KMail's current capabilities if you want us to consider your wish.

My attitude came from the fact that you came in and called for the bug to be closed, even after two people agreed that my feature would be useful to be added...

Anyway, uses that aren't covered by two fixed toolbar items:

* Giving access to more advanced features of bogofilter, like *un*-registering as spam or non-spam

* Viewing the details of why a mail was marked as it was

* Configuring Bogofilter (this would better be put in the Tools menu than a context menu)

* Adding any kind of mail processing other than spam filtering, or even using two different spam filters

Example: I could imagine a situation where advanced mail flagging features were done with a plugin that hooked into a conext menu and into something else that allowed the plugin to be responsible for painting the list view item.

Subject: Re:  Context menu plugin system like KonqPopupMenuPlugin, Please

One idea that I can't get out of my head it using a combination of 
KPlugin, XMLGUI, and DCOP to provide pluggable functionality.

Currently we don't use XMLGUI for the context menu but we could, and 
it does make some sense. (I mean in the appropriate.rc file you can 
list KActions that should appear for the readerwindow and 
messageheaders contextmenu).

KPlugin could be used to load modules that create new KActions. So I 
could modify my .rc, add a new readerwindow context menu item 
KAction, write a KPlugin that implements this KAction and then put 
this KPlugin in some predefined directory. KMail/Kontact will load 
all plugins in this directory at start up.

The plugins could talk to KMail or other components via their dcop 
interfaces (maybe via a wrapper library rather than directly). 
Possibly using private dcop interfaces KActions like remove duplicate 
messages could be moved out of the core KMail code into a plugin 
directory, as time goes on maybe some private dcop interfaces could 
mature into public ones.

In the long run I kind of have a mental picture of gimp like plugins 
for Kontact, where organizations can implement specialized 
functionality to suit their communication needs. Only unlike gimp 
plugins the basic gui (Menus, toolbars, context menus) could be 
changed.

Maybe these plugins could be programmed in a high level language like 
python or ruby.

Don.

Yeah, XMLGUI is great for this stuff.

For ideas on implementation, take a look at KonqPopupMenu in libkonq.  It's just so powerful and easy to write those context menu plugins.

* Giving access to more advanced features of bogofilter, like *un*-registering as spam or non-spam

That's exactly what ad hoc filters in KDE 3.2 can be used for. Furthermore that's exactly what Andreas' Spam Filter Setup Wizard sets up for the user, i.e. menu options (and later also toolbar buttons) for teaching spamassassin or bogofilter about spam/non-spam.
 
 * Viewing the details of why a mail was marked as it was

View->View Source?
 
 * Configuring Bogofilter (this would better be put in the Tools menu than a context menu)

As you pointed out yourself this doesn't belong into a context menu. It doesn't even belong into KMail. Anyway, the solution for this problem is trivial: Write a KControl module for configuring Bogofilter and then show this kcm in KMail's configuration dialog. Till is currently converting the complete KMail configuration dialog to kcms so adding more kcms will be a no-brainer.

 * Adding any kind of mail processing other than spam filtering, or even using two different spam filters

That's exactly what ad hoc filters with a pipe through action can be used for. And of course the scripts the messages are piped through can be written in Python or Ruby.


I don't see why we would need plugins for anything of the above. But I won't close this bug report. I will just mark it as IWONTFIXIT.

Now that KMail has a nice gui to create custom filters and associate them to menus/shortcuts, could this bug be closed?

@Ingo: the whole idea of allowing plugins is not knowing what extra functionality would be useful and why an app would need them, so you provide a framework for third-party developers and let them sort it out.

Well, special context menu plugin system is not needed, as this is already possible through a hack.
KParts::Plugin allows you to add plugin to any kpart. KMail too is now a kpart.
Get the pointer of parent windows and search for child KPopupmenu, which gets displayed, when you right click.
Through mix of event filters, it is 100% guaranteed to work.
KonqPopupMenuPlugin only adds text to context menu, when nothing is selected on KHTMLPart. I needed context menu plugin addition for my "Google Suggest Toolbar" (http://kde-apps.org/content/show.php?content=15163) when text is selected.
So, this hack came in my mind !
Once you have pointer to mainWindow, you can do anything in any part of GUI! Just keep in mind, that your tricks dont create any bug.

So, can now this bug be closed?

Now that this bug has changed from requesting a specific feature to requesting a general plugin interface (Similar to Thunderbird's wonderful extensions) I suggest that this bug be marked a dupe of bug #33670.

I personally think that Plugins are a wonderful idea.

*** This bug has been marked as a duplicate of bug 33670 ***