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

[smurfd <smurfd smurfnet homelinux net>]

tis 2004-03-09 klockan 09.54 skrev Not Zed:
> 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.

Ah, i see, save as .. you say, ill look into it. Thanks.

Okey, and that should be located int the camel/ folder, right, even the
framework stuff?

> > 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.

Okidoki, well as i said, havent been looking into much of gtk/gnome code. 
It is all so very different, comment/documentation wise, i mean, some tend to comment the code Too much,
wich just makes it hard to follow.. 
Though, Java has a nice thing, called javadoc wich creates an API similar html documentation from a .java code,
if you only have a sertain look of the comments about each function, makes documentation alot easier.. 
though, i guess you have heard of it. :)

Thanks for taking time to answer.
/smurfd a.k.a Nicklas Boman