Re: [Evolution-hackers] Regarding a mail Exporter.

[Not Zed <notzed ximian com>]

On Tue, 2004-03-09 at 02:54 +0100, smurfd wrote:

> Hello Evolution-hackers!
> 
> I have been in touch with this subject earlier (it was some time ago, a
> couple of months maby, i asked about a mail exporter).
> Then i got a answer, that it was thought of, but not implemented..
> 
> So, to make a long story shorter, i created a patch to one of the
> bounties, regarding the mailer. Though, i was pretty late :(
> 
> But, anyway, this was a carrot for me to learn about GTK-development and
> also to learn abit about the Evolution-development. 
> So, while i got things abit fresh in memmory, i thought that i could try
> to create such an mail-exporter.. ie a thing that would move, and or Tar
> a mail (sub)directory to another place for backup.
> 
> I come so far, that i kindof know where to put a function, handling the
> exporting, from a right-click-folder menu.
> Wich prompts a file-selector that wich you would point to the directory
> where you want it exported.
> 
> (im thinking of then, adding a window, after one hit the OK button, that
> would give you options to run it to a compression filter (ie, Tar it
> etc). 
> Still im clueless on how to do the actual moving of files, the Evolution
> way. I mean, i had a look on the importer things, but they are well
> baked together with all the source all around..
> My plan right now, temporary of course, just to get an working example,
> is to make it run a system() call.. yes, ugly hack (TM).
> 
> And that my friends, is why im writing this.. 

> Any ideas, any suggestions?!

You probably want to open each folder using camel, and then write each
message out to a file or a new folder.  Depending on what message format
you want.

Note that we already have a 'save as ...' menu item, which essentially
'exports' the currently selected messages in the current folder to a
berkely mailbox format ('mbox') file.  The way this works would be a
basis for most of the functionality.

Also note that anything to do with camel/etc should run in another
thread, and conversely, anything that runs in another thread can't do
any gtk+ stuff.  We've got a bunch of frameworks for managing thread
pools and passing data and status messages back and forth, but it isn't
terribly well documented.

> Ps. bare with me, ive only been doing gtk development for a couple of
> weeks (2-3) .. but i see alot of kindof-similarities to Java's Swing GUI
> wich i know alot about doing stuff with. 
> 
> Ps. some constructive critisism : 
> One or two lines of comments about what a function does, wouldnt hurt.
> Why not do like, that if someone changes something in a function on the
> CVS, that they add two lines of comments.. that way, it wouldnt be,
> like, "oh, i got 50000 functions to write about, *sigh*" .. as an
> example .. 

The mailer code has a *lot* more comments than just about any other
gnome or gtk+ application, from what i've seen.  Many external entry
points in most files are documented.

> void 
> /* This function, handles the the user input, that is given
> ** from the file-selector window
> **/
> em_function_x()  

FWIW you always want to put the comments above the complete function
declaration.  Makes it a lot more readable.  i.e. not between the return
type and the function name.