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

List:       kmail-devel
Subject:    Architectural problems shown by the anti spam wizard
From:       Andreas Gungl <Andreas.Gungl () osp-dd ! de>
Date:       2004-01-28 19:45:59
Message-ID: 40181177.70007 () osp-dd ! de
[Download RAW message or body]

Hi,

for those who are interested I want to describe some problems I came 
over while I worked on some details for the anti spam wizard.


Current situation:

   The concept of ad-hoc filters allows dynamic plugging of marked 
filters into the KMail menu with a slightly modified menu item name 
(derived from the filter name) plus an icon (both defined in the filter 
dialog). When the configuration has changed, all items get removed from 
the submenu and each marked ad-hoc filter gets added then into a "clean" 
submenu.
You can now use the toolbar editor to include some of the (dynamic) menu 
items (actually actions) into the toolbar. This will work fine as long 
as you don't remove the menu items by e.g. deleting or renaming the 
filters. In this case the action entry in the XMLGUI config file will 
stay but the toolbar icon is no longer shown because the corresponding 
action can't get found.
Here the XMLGUI definition and the filters get out of sync which can be 
a source for problems later on.

   The wizard plugs the action into the toolbar and to make the change 
persistent it modifies the XMLGUI file. This is done by manual 
manipulation of the XMLGUI file, currently there is no API which would 
support automatic write back of the current config by the toolbar itself.
Of course the user will face the sync problems described above sooner or 
later. Another problem might be based on translation (i18n) issues when 
e.g. the user switches the language, but I have no concrete scenario for 
this, it's just a guess.

Possible solution:

   We might add an option to the filter definition which depends on the 
filter being marked as ad-hoc so that then it can additionally marked as 
"include in toolbar". This would support the idea of dynamic actions 
based on the current filter configuration. It also would eliminate the 
sync problem between filters and XMLGUI ressource.
A drawback is that the user can't make persistent changes to the 
position of these actions in the toolbar, which is really no good UI 
design. A special filter toolbar is bloat, IMO.


I've thought about the possibility to have some predefined default 
actions which might be disabled or hidden as long as no action provider 
is bound to them.
Let's say that we have a default action "mark as spam". The appropriate 
filter should register to this action making the action active. After 
that the user may configure the action regarding the toolbar position.
My conclusion was that this (up to now) a very special case. It's more 
complex to implement than the solution above. And I still have no clear 
picture about what would this imply for other parts of KMail.

I would like to know what is your opinion about this problem? What are 
your (the core developers') plans regarding changes to the filter system 
in the near future? How do this ad-hoc filters fit into a concept of 
using sieve to support filtering on the server side? Does anybody has 
plans for a plugin system and how could it deal with the problem 
described above?

Thanks for reading,
Andreas
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel
[prev in list] [next in list] [prev in thread] [next in thread]