Re: [Evolution-hackers] Introduction and Questions
On Sun, 2007-06-10 at 15:55 -0700, Ross Boylan wrote: > On Fri, 2007-06-08 at 20:22 -0400, Jeffrey Stedfast wrote: > > > > > > Second question: even if it creates a folder, does it need to stick > > > around for the folder creation to finish? I think I remember seeing > > > that camel was single-threaded > > > > not true... I should have been clearer here: yes, it needs to wait for the folder object instantiation to finish (the function returns a pointer to the instantiated object, afterall). not true that camel is single-threaded - it has a few of its own threads going - most notably is the thread for filtering incoming mail for providers like imap and maildir (they share the same thread). > > > > > , relying on the client app to do > > > threading. Would there be a way to multi-thread this somewhere > > (either > > > in camel or in the app)? Obviously doing so would complicate > > things, > > > because at some point one might need to block (e.g., if I move a > > message > > > from folder A to B and then switch the UI to look at B). > > > > okay, I think you need to familiarize yourself with Camel's API before > > we discuss anything further :) > > > http://www.go-evolution.org/Mail_Threading begins > "The Camel API is blocking and synchronous" > although it then goes on to qualify this: > "Custom Threads > Two tasks inside Camel use threads internally in order to implement a > cancellable api ontop of a non-cancellable one." > > Further > "Mail-OPS > mail-ops.h contains asynchronous versions of varous Camel api's" > It sounds as if mail-ops is outside of Camel, however. it is external to camel, yes. > > So it sounds as if Camel could (in principle) respond to a move request > by issuing the appropriate IMAP command and then, starting a thread to > do the other activities (indexing the target folder and deleting the the > message from the source folder) and return. it could, yes, but it'd need a way to report an error unless it waited for the operations to finish before returning. For moving mail, you typically want to know that it succeeded :) all of the current camel APIs are designed such that the caller expects that when the function returns, the operation has either succeeded or failed (where the failure would be set on the CamelException argument). > It would then block on > operations that attempted to access the target folder until the other > operations completed. yes, this is true... well, the way folders are implemented at this time anyway... > > I think this could be called a syncronous API, though perhaps that's a > stretch. it is indeed a synchronous API :) > > On the other hand, http://www.go-evolution.org/Camel.Operation does not > sound like a bocking syncronous API at all, so maybe the statement > quoted at the top is just obsolete? Camel code is written under the assumption that it is likely it is being used in a thread, so it has CamelOperation as a means to: 1. report the progress 2. cancel operations (typically i/o) what happens is Evolution has a thread-pool with a CamelOperation object for each of the threads the mailer creates so that it can cancel operations and/or get progress updates. > > So, first of all I'm confused about the nature of Camel's API and > operation as far as threading and syncronicity. > > Second, I don't have a sense of whether its features are historical > accidents (camel was implemented in a simple way and evo then used it as > it was) evolution mailer was originally not multi-threaded if my recollection serves correctly, although around the time of the first 0.0 release threading was added (about 7 years ago). camel and evolution were developed together, so their "designs" evolved together. > or the result of some deliberate design decisions. Blocking > syncronous operations are simpler to implement, yep > to use, yep > to debug, yep, altho with threads thrown in and gdb multi-thread support sucking, this was still a nightmare... > and to > understand, so they clearly have some advantages. But it seems that > the entire application (evolution) does not have that character, so the > benefits of that simplicity end up lost anyway. I'm not sure I understand what you mean here... I guess what you are saying is that evolution code isn't easy to understand. I think that's true for all large/complex projects. I think that it also feels that way when you are new to the project because it is so large and overwhelming - I mean, I know that's how I'd feel if I were just getting into Evolution sources... I think that it probably doesn't help that things aren't super well documented either (kinda hard to do when things change so much so frequently). From what I can tell, most software (proprietary included) suffers greatly from this problem :( I think it's obvious that most of evolution's design is evolutionary (hah, bad joke, eh?). Despite that, I think it actually turned out quite good, but some APIs are certain
Re: [Evolution-hackers] Introduction and Questions
On Fri, 2007-06-08 at 20:22 -0400, Jeffrey Stedfast wrote: > > [Ross wrote] > > Second question: even if it creates a folder, does it need to stick > > around for the folder creation to finish? I think I remember seeing > > that camel was single-threaded > > not true... > > > , relying on the client app to do > > threading. Would there be a way to multi-thread this somewhere > (either > > in camel or in the app)? Obviously doing so would complicate > things, > > because at some point one might need to block (e.g., if I move a > message > > from folder A to B and then switch the UI to look at B). > > okay, I think you need to familiarize yourself with Camel's API before > we discuss anything further :) > http://www.go-evolution.org/Mail_Threading begins "The Camel API is blocking and synchronous" although it then goes on to qualify this: "Custom Threads Two tasks inside Camel use threads internally in order to implement a cancellable api ontop of a non-cancellable one." Further "Mail-OPS mail-ops.h contains asynchronous versions of varous Camel api's" It sounds as if mail-ops is outside of Camel, however. So it sounds as if Camel could (in principle) respond to a move request by issuing the appropriate IMAP command and then, starting a thread to do the other activities (indexing the target folder and deleting the the message from the source folder) and return. It would then block on operations that attempted to access the target folder until the other operations completed. I think this could be called a syncronous API, though perhaps that's a stretch. On the other hand, http://www.go-evolution.org/Camel.Operation does not sound like a bocking syncronous API at all, so maybe the statement quoted at the top is just obsolete? So, first of all I'm confused about the nature of Camel's API and operation as far as threading and syncronicity. Second, I don't have a sense of whether its features are historical accidents (camel was implemented in a simple way and evo then used it as it was) or the result of some deliberate design decisions. Blocking syncronous operations are simpler to implement, to use, to debug, and to understand, so they clearly have some advantages. But it seems that the entire application (evolution) does not have that character, so the benefits of that simplicity end up lost anyway. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
On Sun, 2007-06-10 at 11:39 +0300, Philip Van Hoof wrote: > On Sat, 2007-06-09 at 08:14 -0400, Jeffrey Stedfast wrote: > > > server says: > > > > * 1 EXPUNGE > > > > camel-imap-summary does: > > > > g_ptr_array_remove_index (messages, seqid - 1); > > In imap_rescan, for example in case a message got removed by another > E-mail client while this E-mail client was not online. > A hash table won't solve this... Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Plugin and menu icons
>Le dimanche 10 juin 2007 17:05 +0400, Nickolay V. Shmyrev a crit : >> В Сбт, 09/06/2007 в 17:45 +0200, Gilles Dartiguelongue пишет: >> > Le vendredi 27 avril 2007 10:07 +0200, Gilles Dartiguelongue a crit : >> > after reading more code, it seems bonoboui doesn't like icons starting >> > with the stock_ prefix. It throws " Bonobo-CRITICAL **: >> > bonobo_ui_util_xml_to_pixbuf: assertion `length > 4 * 2 * 2 + 1' failed" >> > at the command line. >> > >> > The result is that the icon for folder->refresh and for any other menu >> > item wanting to use a stock_* icon, it just won't appear. >> > >> > I thought it could be a problem with libbonoboui but then I remembered >> > that it works perfectly fine for popup menus. >> > >> > As gtk-* icons are far from covering what we can add as icons in the >> > menus, please, please help me fix this issue. >> >> Hello Gilles >> >> It's really hard to understand original problem and reasons for that >> since not much is described. What are you trying to do really? > >> About way to convince bonoboui what about registration of stock icon and >> then usage it in libbonoboui with pixtype=stock? I'm not sure why >> libbonoboui tries to get pixbuf from your attribute (it's the task of >> the function bonobo_ui_util_xml_to_pixbuf). Looks like you misunderstand >> each other. What ui description are you passing to it? > >let's try with an example, take: >http://svn.gnome.org/svn/evolution/trunk/ui/evolution-mail-list.xml >there is a line in it that looks like: >pixtype="stock" pixname="stock_refresh"/> > >The icon exists and is in the same folder where are stored other stock >icons (gtk-add, gtk-undelete, ...) but it doesn't show up in the UI Right, because gtk-add is not the name of the file but id of the stock icon: http://developer.gnome.org/doc/API/2.0/gtk/gtk-Themeable-Stock-Images.html You should register your own stock icon if you want to use them. I suspect stock_refresh is not registered or registered under different name, say gtk-refresh. Probably it was registered earlier in libgnome and was dropped now. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Plugin and menu icons
Le dimanche 10 juin 2007 à 17:05 +0400, Nickolay V. Shmyrev a écrit : > В Сбт, 09/06/2007 в 17:45 +0200, Gilles Dartiguelongue пишет: > > Le vendredi 27 avril 2007 à 10:07 +0200, Gilles Dartiguelongue a écrit : > > after reading more code, it seems bonoboui doesn't like icons starting > > with the stock_ prefix. It throws " Bonobo-CRITICAL **: > > bonobo_ui_util_xml_to_pixbuf: assertion `length > 4 * 2 * 2 + 1' failed" > > at the command line. > > > > The result is that the icon for folder->refresh and for any other menu > > item wanting to use a stock_* icon, it just won't appear. > > > > I thought it could be a problem with libbonoboui but then I remembered > > that it works perfectly fine for popup menus. > > > > As gtk-* icons are far from covering what we can add as icons in the > > menus, please, please help me fix this issue. > > Hello Gilles > > It's really hard to understand original problem and reasons for that > since not much is described. What are you trying to do really? > About way to convince bonoboui what about registration of stock icon and > then usage it in libbonoboui with pixtype=stock? I'm not sure why > libbonoboui tries to get pixbuf from your attribute (it's the task of > the function bonobo_ui_util_xml_to_pixbuf). Looks like you misunderstand > each other. What ui description are you passing to it? let's try with an example, take: http://svn.gnome.org/svn/evolution/trunk/ui/evolution-mail-list.xml there is a line in it that looks like: The icon exists and is in the same folder where are stored other stock icons (gtk-add, gtk-undelete, ...) but it doesn't show up in the UI -- Gilles Dartiguelongue <[EMAIL PROTECTED]> Élève Ingénieur ESIEE, 5ème année Majeure Informatique ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Plugin and menu icons
В Сбт, 09/06/2007 в 17:45 +0200, Gilles Dartiguelongue пишет: > Le vendredi 27 avril 2007 à 10:07 +0200, Gilles Dartiguelongue a écrit : > > Le dimanche 08 avril 2007 à 23:11 +0200, Gilles Dartiguelongue a écrit : > > > Hi list, > > > > > > in the process of enhancing plugins, I was looking for a mean to add an > > > icon in the top level menus. After some code reading it seems it is not > > > possible if the icon is not a gtk stock icon. Did I miss something ? > > > > > > Any pointers would be appreciated. > > > after reading more code, it seems bonoboui doesn't like icons starting > with the stock_ prefix. It throws " Bonobo-CRITICAL **: > bonobo_ui_util_xml_to_pixbuf: assertion `length > 4 * 2 * 2 + 1' failed" > at the command line. > > The result is that the icon for folder->refresh and for any other menu > item wanting to use a stock_* icon, it just won't appear. > > I thought it could be a problem with libbonoboui but then I remembered > that it works perfectly fine for popup menus. > > As gtk-* icons are far from covering what we can add as icons in the > menus, please, please help me fix this issue. Hello Gilles It's really hard to understand original problem and reasons for that since not much is described. What are you trying to do really? About way to convince bonoboui what about registration of stock icon and then usage it in libbonoboui with pixtype=stock? I'm not sure why libbonoboui tries to get pixbuf from your attribute (it's the task of the function bonobo_ui_util_xml_to_pixbuf). Looks like you misunderstand each other. What ui description are you passing to it? signature.asc Description: Эта часть сообщения подписана цифровой подписью ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
On Sat, 2007-06-09 at 08:14 -0400, Jeffrey Stedfast wrote: > server says: > > * 1 EXPUNGE > > camel-imap-summary does: > > g_ptr_array_remove_index (messages, seqid - 1); In imap_rescan, for example in case a message got removed by another E-mail client while this E-mail client was not online. -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
