Re: [evolution-patches] 57114, camel trash problems in connector

[Not Zed <notzed ximian com>]

On Wed, 2004-05-26 at 11:17 -0400, Dan Winship wrote:
> On Wed, 2004-05-26 at 09:46 +0800, Not Zed wrote:
> > 
> > I think a cleaner way would be to do this:
>
> OK, new patch attached
Go for it.
> > The original code was supposed to abstract the trash name to be the
> > same thing regardless of what it physically is - connector was
> > supposed to do that.
>
> But it doesn't behave the same way as it does in the rest of Evolution,
> so it makes more sense to show its real name and be consistent with
> Outlook/OWA. At any rate, this is how it was in 1.4 and things worked
> fine.
>
> >   Some of the other code assumes this is the case (in the mailer), so
> > it will break some minor things if it isn't.  e.g. trash icon, e.g.
> > translation of trash folder name, etc.  So keep that in mind what
> > these changes break or complicate.
>
> The older code uses (folder->folder_flags & CAMEL_FOLDER_IS_TRASH). It
> looks like only em-folder-tree.c uses CAMEL_VTRASH_NAME.
Yeah.  I didn't say it was a good idea, that api.  I even told whomever it was not to base icons on the folder names, but they did it anyway ... sigh.

The problem is we essentially have 3 separate 'models' driving the folder tree.  The camel one (which is essentially based on disk data), the mail-folder-cache one, which also tracks physical folders, and the em-folder-tree one which doesn't track the folders.  Its a "big bloody mess".  You can't rely on folder_flags anyway, since the folder might not be open.

The camel one can't really go, and isn't useful enough by itself, the folder cache one 'does other things', like be a central point for folder change notifications, renames (for vfolders/filters), etc, and you need something to drive the view.

"in an ideal world":
 - get_folder_info would only exist for subscriptions, perhaps it might not even be needed for that
 - folders would have siblings and children and parent relationships, be 'stateful', i.e. need explicit open/close, etc.
   - they might have, but i stuffed the api up early in 2000 making it harder to do this
 - store wouldn't have any "create folder" "subscribe folder" calls, they would just sit on the folders
 - you'd have a single *direct* tree model (not using that awful treestore thing) which just proxied the folder tree

Michael Zucchi <notzed ximian com> Ximian Evolution and Free Software Developer

Novell, Inc.