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

List:       kmail-devel
Subject:    Re: Architectural problems shown by the anti spam wizard
From:       Don Sanders <sanders () kde ! org>
Date:       2004-01-29 5:00:27
Message-ID: 200401291500.27434.sanders () kde ! org
[Download RAW message or body]

Hi Andreas,

On Thursday 29 January 2004 05:45, Andreas Gungl wrote:
> 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.
>

I'll try to answer your questions as best I can. But I'm having 
difficulty because I don't understand the intended workflow for 
setting up the anti-spam stuff you have been working on.

Don't get me wrong it's a critical feature in my opinion, but I'm 
lacking clarity on how exactly it is meant to work from the end users 
point of view. Is it intended to work like the Mozilla ant-spam 
stuff? (I haven't used that either, but I see lots of people saying 
good things about it).

I don't understand what value the new spam/ham statuses have for 
instance.

> 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.

Are we talking about KMMainWidget::initializeFilterActions() here?

Yes in my opinion there is an implementation weakness here, rather 
than deleting the old KActions (mFilterActions.clear()) existing 
KActions should be reused where possible. This may be possible by 
using the normalizedName.local8Bit() which is passed into the KAction 
constructor and hence is the QObject::name() for that KAction.

At least I was experiencing a problem due to this clearing of existing 
KActions, and this is the solution I was thinking of to fix it. Are 
thinking about the same thing here?

> 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.

I wonder what these 'problems later on' are. I guess they are 
important as you mention them?

>    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.

Not completely sure I understand the sync problems.

> 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.

If you look at the KAction constructor in initializeFilterActions() 
the QObject::name() is not i18n()'d so this should be invariant in 
the case of the user switching the language.

> 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.

Why would if eliminate the sync problems, it seems I'm missing 
something or not following clearly.

> A drawback is that the user can't make persistent changes to the
> position of these actions in the toolbar,

Why?

> 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.

What are you referring to by action provider? A KAction, based on a 
filter in the filter dialog?

> 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 think default actions make sense.

> 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?

Unfortunately I don't understand the proposed anti spam wizard well to 
understand what 'this problem' is well enough to be able to answer 
these questions.

I should be on #kontact till about at least GMT 9:00am if you want to 
discuss things on irc.

Don.
_______________________________________________
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]