Re: [Evolution] About "hide read messages"
- From: Not Zed <notzed ximian com>
- To: Andrew Conkling <andrewski fr st>
- Cc: evolution lists ximian com
- Subject: Re: [Evolution] About "hide read messages"
- Date: Wed, 19 May 2004 09:00:19 +0800
On Tue, 2004-05-18 at 12:55 -0400, Andrew Conkling wrote:
On Tue, 2004-05-18 at 22:18 +0800, Not Zed wrote:
> You're not a coder are you? Or even a software engineer.
>
> Deal with it.
>
> > I'm not trying to instigate or point fingers, just to vent a bit of
> > frustration about the nature of this list (or perhaps about my
> > misunderstanding of the function of this list?).
>
> Well, how much did you pay for this software?
OK. I think it's fairly obvious that I've made you (and perhaps others)
angry by my comments. (That or I'm dealing with sarcasm too thick for
my thick head.) If so, that was not my intention and I apologise. I
was trying to open doors to dialogue about the development of this
particular piece of software.
Best thing around here is not to take anything too serious (we do, and look how we turned out), and if you have a real problem or solution, it will eventually get listened to - even if it takes a while. I think the fact we take it serious means we care about the product, but the priorities might be different. Calling stuff crap is the best way for it to remain crap though ...
As to the thread at hand, basically, i see the hide read message statefulness as about the best compromise with ease of use, and implementability. If you have a folder option like 'hide deleted' works, then you will also still need some manual 'update now' button/menu item, since you will otherwise have the mailbox 'reading itself', and messages vanishing before you can read them just by viewing them. So, sure the menu item might be called something else, but the only real difference you're gonna get is the first time you view the folder. Unless you can think of some wildly different way to do it which will provide a consistent user experience and can be implemented for reasonable effort.
And usually when this is explained (which it was in much more brief language), the users nod and get on with their lives and don't even notice that feature exists. Explaining it over, and over ... and over and over. Gets tiring and wastes a lot of time. Hopefully we'll have a FAQ soon which will address most of the FAQ's - far too long a time in coming.
Once (if) we get vFolders being more lightweight, it might be practical to just have 'shadow' folder trees automatically setup for things like this.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]