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

[Not Zed <notzed ximian com>]

On Tue, 2004-03-09 at 15:41 +0100, smurfd wrote:

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

No.  Camel just handles the mail.  The frontend stuff is in mail/
(mostly).

I think the ui is hooked up in mail/em-folder-view.c, and the actual
saveas code is in mail/em-utils.c.

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

You mean ... like gtk-doc?  Although I think the way gtk-doc has
implemented its documetation framework is essentially busted, the basics
are the same.

e.g. from the evolution source code:

/**
 * em_utils_save_messages:
 * @parent: parent window
 * @folder: folder containing messages to save
 * @uids: uids of messages to save
 *
 * Saves a group of messages to disk in mbox format (prompting the
 * user for filename).
 **/
void
em_utils_save_messages (GtkWidget *parent, CamelFolder *folder,
GPtrArray *uids)
{