Re: [Evolution-hackers] Plugin and menu icons

2007-06-10 Thread Nickolay V. Shmyrev
В Сбт, 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] Plugin and menu icons

2007-06-10 Thread Nickolay V. Shmyrev
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:
menuitem name=FolderRefresh verb= _label=Re_fresh...
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] Introduction and Questions

2007-06-10 Thread Jeffrey Stedfast
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] Introduction and Questions

2007-06-10 Thread Ross Boylan
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