Re: [Evolution] Re: [Evolution-hackers] Feature request summary 1/27

[Not Zed <NotZed Ximian com>]

On 29 Jan 2001 23:08:21 -0500, Ben FrantzDale wrote:
> On 28 Jan 2001 19:12:52 -0500, Duncan Mak wrote:
> > On 29 Jan 2001 10:43:18 +1030, Not Zed wrote:
> > > Ouch, that sounds like an awful interface.  I think its actually hard to
> > > write too, since currently the code doesn't do dynamic columns like
> > > that.  I would have thought a better one would be to have something show
> > > up when you click on the message itself, in the viewing window, where
> > > you can add keywords or whatnot.
> >
> > I think this sounds great. As someone also suggested for a right click
> > menu within the message view, a menu item to do this could also be put
> > in there.
> >
> > To go back to the thread issues, people have been mailing me left and
> > right about how Outlook handles threads and how it indicates
> > read/unread.
> >
> >  In Outlook: if a collapsed thread has any unread messages in it, the
> > head of the thread is marked unread.


I dont really care what outlook does in this regard, because as far as
i've heard, outlooks 'threading' is really crap.

> > We don't actually do this right now, and I think this is a fairly
> > consistent thing to do. 


Not really, if a message is read its read.  The pseudo nodes which
everyone hates behaves exactly this way, FWIW.

> > Another bit I'm noticing is some questions on how to handle heads of
> > threads that are actually not avaliable. Some people think it's
> > confusing that the message list shows a listing  that looks just like a
> > message, but it's actually just an 'anchor' for the thread, they
> > requested a change of icon for differentiating between the anchor and
> > real messages.


There is already code in there to remove these phantom nodes.  There's
just a couple of cases it doesn't catch though.

> I'd agree. One other thing on the subject of threads, though: I find
> that the threading algorithm isn't perfect. I havn't looked over the
> code, but I keep finding messages that should be in another thread in
> the wrong thread and messages out of their thread.  One solution would
> be to work on the algorithm (though it can't be perfect since it's
> extrapolating.) The other option I was thinking would be this: Some sort
> of HTML or XML tag that the sender would add that contained what message
> (sender, subject, time) it was in response to. It would only get good if
> such a standard could be used across mailers, but it would be the right
> way to do it, I think. Any comments?


This is already part of the message, defined by the References tag.  It
isn't actually extropolating at all, the only thing it does that with is
orphaned messages with the same subject root.

Messages out of their thread are probably duplicates.

 !Z