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

List:       kmail-devel
Subject:    Re: RFC: Multiple selection support for the filter dialog
From:       Don Sanders <sanders () kde ! org>
Date:       2004-08-30 5:26:06
Message-ID: 200408301526.09691.sanders () kde ! org
[Download RAW message or body]

On Monday 30 August 2004 06:56, Ingo Klöcker wrote:
> On Sunday 29 August 2004 10:42, Don Sanders wrote:
> > Finally I take it that at least at this stage, no one objects to
> > adding a 'for this account' combobox. That's really what I need
> > for client side imap filtering. As I said the multiple selection
> > idea is just about making it easier for existing users to
> > upgrade. I guess unless you have a change of opinion or another
> > core developer supports the idea of multiple selection and
> > tri-state checkboxes I'll just drop that idea for now, and
> > instead focus on getting a 'for this account' combobox working.

Minor point, I meant to write 'for the account' instead of 'for this 
account'.

> A combobox is a very bad idea because that would mean that the user
> can bind a filter to exactly one IMAP account.

No, I seem to have failed to communicate a fundamental idea clearly. 
The idea of a 'for the account' combobox is to allow per account 
filtering settings for each filter. So if a user has two IMAP 
accounts they could choose to enable a filter for one account and 
turn it off for another. The state of the checkboxes would be updated 
depending on which account is selected in the combobox.

At least that's the flexibility I'm seeking. I guess I've been a bit 
imprecise here. Maybe it makes sense to consider each of the 'apply 
this filter to' checkboxes in turn.

For 'to incoming messages' it makes sense to allow this to be turned 
on/off for each incoming (Local, POP, or IMAP) account  for each 
filter. 

For 'to sent messages' it doesn't make sense to allow this to be 
turned on/off for incoming accounts. It might be nice to allow this 
to be turned on/off for each sending (SMTP or sendmail) account.

For 'on manual filtering' I guess it makes sense to allow this to be 
toggled on/off for IMAP accounts, and for 'All Local Folders'.

I guess rather than having a single 'for this account' combobox an 
alternative would be to have one combobox for each of the 'apply this 
filter to' checkboxes, but that would take up more space than a 
single checkbox.

> Sure, for most users 
> that would probably be sufficient, but I'm not in favor for such an
> inflexible solution.

I see the solution I've proposed as being very flexible. That's why I 
also advocate allowing multiple selection in the list box and 
tri-state checkboxes, so that it's possible for the user to manage 
this increase in flexibility in an easy way. e.g. so that it's 
possible to activate all filters for a particular IMAP server with 
just a few clicks.

> As I see it we basically have two options: 
>
> a) Make all filters depend on exactly one account (POP or IMAP).
> One possibility to do this would be to show all accounts as top
> level entries in the filter list and all filters as second level
> entries below the corresponding accounts.
> Problem: Lots of filters are duplicated. If one filter is changed
> then all its twins probably also need to be changed.
> So a) is basically out of question IMO.

I think I follow your logic here.

> b) Add a checkbox (apply to all accounts) and some other widget for
> individual selection.

Yes, that's the kind of solution I'm after. Maybe a single 'apply to 
all accounts' checkbox makes sense. That may well be sufficient to 
cover all the common cases.

I think it makes sense to consider using a single combobox as the 
'other widget'. This combobox could list all known accounts (sending, 
receiving ) and also list an 'All Local Folders' item.

This combobox would only be enabled when the 'apply to all accounts' 
checkbox is turned off. It could be labeled something like 'for the 
account'. If for example the user selects an IMAP account in this 
combobox then the 'to sent messages' checkbox could be disabled, 
leaving the other checkboxes enabled.

> One really though problem is the addition of new IMAP accounts.
> What should happen? Should all filters work for the new account?
> Should only filters which are associated with at least one IMAP
> account be associated with the account?

I would say no filters should be applied to the new account. I think 
that would be the behavior most users would expect.

None of the 'file in folder' filter actions could reference folders on 
the new account, instead they could only reference local folders and 
remote folders on other accounts. So applying existing filters 
automatically to the new account could surprise the user by 
unexpectedly moving mail out of their new account into some other 
arbitrary account.

> Hmm, I think the only sensible option is to add a checkbox "Also
> apply on IMAP folders".
>
> I'm not really lucky with any of the solutions. Do we actually need
> such an option? What's wrong with simply using the value of the
> "Apply on incoming mail" setting? After all, new IMAP messages are
> incoming mail.

I think people who use filters for POP accounts but rely on server 
side filtering for IMAP accounts aren't going to find that 
acceptable, (because clearly they want filters to be applied to mail 
from their POP accounts but not their IMAP accounts). I'm such a 
person.

So basically I don't think this would be flexible enough.

How about a 'Apply to all accounts' checkbox with a complementary 'for 
the account' combobox. Please also reconsider your objection to 
allowing multiple selection and tri-state checkboxes, unless you have 
some other suggestion for how to allow the user to easily activate 
multiple filters for a single account.

If there's some alternative solution that is simpler but still 
sufficiently powerful I'm interested.

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]