Re: Simplification of preferences

["M. Thielker" <balsa t-data com>]

Hello,

On 2002.11.14 10:17 Toralf Lund wrote:
> Or maybe you wold like it even more because it would be more stable, run 
> faster, be easier to use etc.

If any of the prefs that I consider "must have" are hardcoded any other way 
than the way I set them up for myself now, it would render Balsa utterly 
and complete unusable for me.

> The mailbox isn't open (from a GUI perspective) or "current" then, is it?

But apparently, when checking IMAP is turned on, a check is performed when 
mail is dropped into it, because for a brief period it seems to be open, 
not from an UI point of view, but n the libmutt level.....
Basically, there's room for change there. To me it's only important that 
there remains an option to turn off checking completely. A "check only 
open" or "check only viewed" in combination with "check inbox always" for 
example:

IMAP
(*) Never check for new mail
( ) Check only opened folders
( ) Check only currently viewed folder
[ ] Always check INBOX, too

That would be acceptable and may be more flexible, yet clearer.

> I've actually partially implemented my options in Balsa 1.4, and I have 
> many IMAP folders with several 1000 messages. No problem, as those 
> usually won't be checked - they are included only if I happen to be 
> viewing them, in which case I *want* to check them.

The latter is true. Unfortunately, see above, when new messages are dropped 
into a closed IMAP mailbox, ut appears a check is made. See, there are two 
ways to check IMAP: RECENT, which is what used to be there, and UNSEEN, 
which is what I changed it to, a long time ago. UNSEEN makes more sense 
because it will only return those messages that have been added since the 
last UNSEEN check. Yet, when a message is moved into a folder, it's both 
recent and unseen. So, really, that message's status needs to be set to 
"seen" when it's moved. I have once done some work to that effect, but I 
don't know if I submitted that or if it was committed. If it was, the 
problem would be gone, I don't know because I keep the IMAP options off, so 
I don't see the problem anymore.
Even when a folder is open, a message should not be new, and thereby 
trigger a new mail sound/popup when it's moved there, because the message, 
having been received in another folder, already was "new" there and can 
never again be "new mail". This issue would have to be addressed, then 
checking the currently viewed folder would be OK.

> The default preference setup gives me a lot more pain as I can *never* 
> check anything but INBOX because checking *all* mailboxes (the only other 
> alternative) is simply not an option.

See above, it could be addressed.

>> work as much as possible. If a software cramps my style, I have to look 
>> for another that doesn't. Software shouldn't force people to do things 
>> in certain ways, it should adapt to all the various way peoples minds 
>> are organized.
> Yes. In an ideal world, at least.

Well, it's up to us to get close to that and not strike down prefs settings 
that are needed. We may represent a fair share of the opinions that desktop 
users would hold. Anything anyone here needs to have should remain in.

> In the real world, more prefs mean more things that can go wrong, more 
> code that has to be understood if you want to make changes (and more room 
> for misunderstandings), more test cases etc. They also make it harder to 
> design a simple and efficient user interface.
>> There can never be enough prefs. Some can be moved to "Advanced..." 
>> sub-dialogs, but removing prefs is, IMHO, always a bad choice.
> KISS, remember?

Well, we're designing this program for users, to be used, not for us 
coders, to make our life easier. Anything that detracts from usability is 
therefore a BadThing(tm). SImplify and streamline, yes, but not at the cost 
of functionality.

> 
>> Also, I think that on none of these options you are considering to 
>> remove, all people on this list could agree to a hardcoded setting.
>> There are so many differences in the way even the few people on this 
>> list work that I don't think that a sensible setting for each can be 
>> found, that all can agree to.
> Of course everyone wouldn't agree. The downside to removing options would 
> be that some of *my* favourites might be gone. The idea of doing it would 
> be that everyone would benefit from a leaner, more stable and 
> easier-to-use app.

Well, it's not about favourites. It's about usability. Just the lack of a 
single option I need makes Balsa unfit for my needs. Anything that would 
prevent me keeping Balsa open 24/7 without it disturbing my work, yet 
alerting me to all I need to know would do that.

Besides, in a Mozilla-style tree view controlled dialog, we could fit even 
more prefs easily and with much better organizations. Restructuring what we 
have is, in my Opinion the best way to do this. That includes moving 
options to different categories, possibly combining, as in the case of 
IMAP, several options into one easy setting, but not dropping options 
completely.

Regards,

Melanie