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

[smurfd <smurfd smurfnet homelinux net>]

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

Oh, i see.. Ah, Camel is the backend, i see.. :)
Ill look into it. 
Thanks, you have been very helpfull!

> > > > 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)
> {

Ooo yes, most like it, yes! :) 
Okey, ill think i do some research before i throw out stuff like that from now on. heh.

/smurfd a.k.a Nicklas Boman