Version: 1.5.4 (using KDE 3.1.4) Installed from: compiled sources Compiler: gcc version 2.95.4 20020320 [FreeBSD] OS: FreeBSD (i386) release 4.9-RELEASE One can make Konqueror plugins that are inserted into the context menus of files in the file manager, to allow for added actions to files. To be able to do this in KMail would be wonderful. In particular, I'd like to be able to make a KMail plugin that lets me right-click a mail and select a menu item to register it with bogofilter as spam or non-spam. That feature, combined with existing filters, would make KMail the ultimate spam fighter.
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 ***