Re: [Evolution-hackers] Status of mail-refactor-2 branch todo

[Not Zed <notzed ximian com>]

On Fri, 2003-09-05 at 14:43, Ettore Perazzoli wrote:
> > I'm not sure if i made it clear, the 'status bar' i was referring to
> > here is the abominationational waste of space at the top of the screen.
> 
> I see.
> 
> According to Anna's design, that just goes on the side of the search bar
> now:
> 
> 	http://primates.ximian.com/~anna/evo2/evo2_buttons_on_top.png
> 
> It shouldn't be quite as abominationatinationational in that case. 
> Also, it has to be implemented in the mail component, and doesn't
> require shell work. (Although, you probably want to wait for the
> new-ui-branch to be merged before this happens.)

Yeah i knew it was going to be totally different now, just clearing up
what i meant.

> > >       * Come up with a different interface, and possibly a different UI
> > >         way of doing it.
> > 
> > I proposed an alternative interface some time ago, which would simplify
> > things a bit and reduce some of the overhead.
> 
> I can't find it right now, do you have a pointer?

Rather was some time ago ...

                             From: 
Not Zed <notzed ximian com>
                               To: 
evolution-hackers ximian com
                          Subject: 
[Evolution-hackers]
EvolutionActivityClient
                             Date: 
02 Dec 2001 06:50:20 +1030


> > Different ui could be an option too (although i dont see what else would
> > be very practical).
> 
> I don't know, for example Apple mail has it at the top, under the
> toolbar.  Anyway, it's probably not worth it to try changing this stuff
> at this point.

Well i was thinking possibly panel applet.

> > Well i meant the internal ones, which are all done.  Remember on our
> > branch we still have the existing shell stuff.  Adding new (extensible)
> > popups in the mailer is now so trivial ...
> > 
> > Do we have to use EStorageSetView at all?
> 
> That widget handles the folder tree, drag and drop, and updates when the
> folder list changes.  Do you have a better idea?

Well, just a simpler version of the same.  There's a lot of glue code in
the mailer to make all the updates work (i.e. almost all of
mail-folder-cache.c), particularly when you do things like rename or
delete folders.  And it precludes the possibility to do things like
incremental folder discovery/expansion.

> > > BTW while you are massaging this code, can we make it so it jumps to the
> > > first unread message when you first click on the folder?
> > 
> > Shouldn't be too hard.  Gotta be optional though.
> 
> Where does the setting go?

Sounds like a good question for the GUI department, dont you think?

> > > You just need to provide an EStorageSet for these to work, and I already
> > > have the mailer handling that on the branch.
> > 
> > FWIW i'm not really fond of these interfaces, but i guess it'll do.
> 
> What's your alternative?

Nothing, yet.  And i suspect you knew that.

> > We have a go to folder option?  Hmm, so we do.
> > 
> > Hmm, would this even make sense with the new layout?  The existing
> > functionality is pretty pointless if you have the folder list open
> > already, and if the ui will force it to be always open, it makes it even
> > less useful?
> 
> I don't know, I find myself using the "Go to folder" dialog a lot,
> because it lets me pick a folder without having to get focus in the
> folder tree first, which either implies a mouse movement or a lot of
> tabbing.

Ahh, i hadn't thought of that.  I find evo impossible to use with a
keyboard so i've always used a mouse.

So it makes some sense in that case, and in any case isn't much work.