On Thu, 2008-04-17 at 04:07 +0930, Tim wrote: > On Wed, 2008-04-16 at 07:44 -0700, Daniel B. Thurman wrote: > > I have found in certain situations, that Evo sometimes 'un-reads' > > messages before the user actually reads it, > > That doesn't make any sense. You seem to be crossing over "read" and > "unread". > > > because new messages are the first message read on the current line, > > assuming of course that Evo is running and the account running idle. > > I've seen Evolution, and other mail clients, mark the first listed > message as *READ* simply because it's selected by default, and > displayed. Which bears no indication whether you've read it or not. > > That's a pain, because any re-arrangement of the message list, and this > "marked as read" but not "actually read" message disappears out of site. > Which can be that's just moved into a different spot in the list, and > you simply lose your place; or you've got a client set with that > annoying "hide all the read messages" feature (so it's not listed, at > all). > > All this reminds me of the *STUPIDITY* of various usenet clients, which > play silly buggers with the read flag. You end up being unable to tell > which messages that *YOU'VE* read, because the client is using the flag > for other purposes. There should be separate flagging for read and > ignored messages. Likewise clients should just hide old messages (if > you want them to), without changing their read status. > > In short: > * If I read a message, it should be marked as read. > * If I haven't read one, it should not be. > * If I've got a client automatically ignoring some messages, it > should flag them as being ignored, and act on that flag alone > (hide them from site, dull the messages, etc.). > * If I've got a client hiding the older messages from a list, then > it should simply hide them and not play with statuses. > * I can tell which have been read, or not, out of those ignored > messages, should I need to go back and find something (e.g. one > gem in a stupid thread). > * I can opt to stop hiding old messages, if I need to find > something that I missed, and still tell which messages I've read > or not read. > * It's a right pain in the neck trying to find the message that > you missed reading the other week if your client has falsely > marked all of the messages as being read. > > > Furthermore, on a different machine where I actually read my messages > > and under Outlook, the messages are all un-read. > > Only if you read your mail using something like IMAP will two different > clients be able to tell what's a read message from an unread message. IMAP servers support a number of message flags: \Recent: the current session is the first one to be notified about the message. Once notified, the flag is unset *by the server*. Evolution only automatically filters messages with the \Recent flag set, which accounts for a lot of "why are my filters not working?" questions. (There's also an IMAP action allowing the client to peek at some message data without unsetting \Recent). \Seen: the IMAP client marks messages which it has shown to the user as being \Seen, but this is highly configuration and client-dependant. Many clients set the \Seen state after a configurable number of seconds. Some allow you to turn this off completely (Evo does, TB doesn't). In any case, this state is reflected on the server so other clients can see it, *depending on when a server sync is done*. \Seen and \Recent are the internal names of these flags on IMAP. Clients may present them to the user with different names. One of the problems with comparing email clients is that they often don't state precisely what they mean by these things. Note that Evolution supports multiple server types, but as a general rule it tries to make them all look as much like IMAP as possible (see the way it deletes messages for example). Some clients also implement a "New" flag, stored internally, to mark those messages which *they* haven't seen before. The client can set/unset this flag as it likes, but the state is not reflected on the server so other clients will not be aware of it. > And, often, only is you do not use the clients simultaneously. > Evolution seems to write the statuses on exit, and if it doesn't exit > nicely, the last set of statuses that should change, aren't changed. Evo updates status when you change folders (or exit cleanly). This is a pain sometimes but that's how it is. poc
