Re: [Evolution-hackers] UI proposal: remove next/prev buttons on external view

[Not Zed <notzed ximian com>]

On Tue, 2005-06-14 at 08:36 -0400, JP Rosevear wrote:
> On Tue, 2005-06-14 at 10:12 +0800, Not Zed wrote:
> > Silence is compliance?
> > 
> > On Wed, 2005-06-08 at 10:19 +0800, Not Zed wrote:
> > > All,
> > > 
> > > Basically, the requirements driving the next/prev buttons on the popup
> > > mail view mean that we take a pretty major performance and memory hit
> > > every time we open up a window.  We have to build an entire hidden etree
> > > to manage it.
> 
> Does it have its own tree because the folder can change out from under
> it?

A number of reasons actually.
 - yes the folder can change, so it needs to track that
 - since etree does the sorting, we need to use it to sort the tree to
match so we navigate in the same order as when the tree was opened.
afaik there isn't even a way to get this info so we could sort
ourselves, and even if we did it is still a major overhead.
 - all the navigation in the main view is inherited in the other, based
on etree selection/cursor, etc, so it needs the tree to navigate.  we
can't really re-use the base tree view either ... I think.

I've seen people use groupwise and they tend to hit return on each
messge as they're using it, outlook seems to work like this too (i was
using it on a friends pc a few weeks ago).  Currently it just makes
evolution look like a real slow fat pig when you do it on any folder
bigger than about 1000 messages.

I guess if it would be possible to re-use the original tree view and
navigate 'by hand' over that, it might work and not entail this massive
extra overhead.