Re: [Evolution] Mail Folder Re-syncronize (feature request)

[Jeffrey Stedfast <fejj helixcode com>]

On 30 Dec 2000 11:52:03 +1030, Mark Phillips wrote:
> Recently I wrote to the list about the corruption of my "Sent" folder.
> Evolution is almost at the stage where I could use it properly, except I
> can't afford to have mail folder corruptions happening now and then
> causing me to lose my mail.  The solution, I thought, is to do regular
> backups of the mbox file in each folder.  That way, if one gets
> corrupted, I can just restore the backup.

There should be no reason to ever need to do this. It would also be a
tremendous waste of space for anyone with a lot of mail. If there are
still issues with it corrupting your mail, then that is a bug that needs
to be fixed. I personally have not had this problem, but it is entirely
possible.

> The only problem with this, is that I believe evolution extracts various
> bits of information from the mbox file, and stores this elsewhere.  So
> just restoring the mbox file won't necessarily work.  What is needed is
> some kind of folder "resyncronize" option, which causes the folder to
> look at the mbox file and recreate all the related files so that they
> match mbox.

It already does this.

> And this leads me to a more general comment about the philosophy of
> Evolution...
>
> Evolution seems to be modelled on MS Windows mailer, Microsoft Outlook,
> so I'm told.  I don't use windows so I don't know from first hand
> experience.  While Evolution has borrowed many good ideas from the
> Windows environment, I think it should endevour to take the best from
> both worlds.  Ie don't lose the good things about the unix way of doing
> things.
>
> An example of this is cut and paste.  The unix "select text with left
> and right buttions and paste with the middle button" doesn't work
> consistently within Evolution.

This should be fixed, I'll agree with that ;-)
Can you provide some places where this is true so we can tracj down
these cases easier? My guess is one of the places is the editor and such
but I'm not sure where else.

> Another deeper example is with the design philosophy of Evolution.  The
> windows philosophy is to "hide the underlying structures from the user,
> and only allow him to play with settings you want him to play with".
> The unix philosophy is roughly "let the user see as much of the
> underlying structure as he wants to see, and let him play with as much
> of the structure as he wants to --- at his own risk."

This is a bad idea. They mess with stuff, lose their mail - and who do
you think the first person they blame is? Helix Code. Is it fair?
Depends on how you look at it I suppose.
Evolution does need more configuration abilities, I'll agree with that
but I'm not sure that's all you mean.

> I think Evolution should incorporate a bit more of the unix philosophy
> into Evolution.  That is, give the user the option of seeing more of the
> underlying structure if he so desires...

What underlying structure would (s)he want to see that's pretty much not
already visable?

> ...If he wants to play with folders
> and surrounding structures manually, then he should be able to.

He already can - mkdir is wonderful for creating new folders ;-)
Now, we will also have a way to do this in the GUI...

> ...If he
> wants to play with internal representations of things, then let him.
> (There will be some limits of course, but it
> would be nice to be able to get a better handle on what the internals
> are doing, especially when the software is still a bit buggy.)

Not clear on what you mean.

> Perhaps some of these things will be included with Evolution later?  Or
> perhaps people disagree on these design philosophy ideas?  I thought I
> would raise them anyway.


I'm not sure, you were pretty vague. Can you suggest some ideas?

Jeff