Re: [Evolution-hackers] introduction and an offering

2007-06-09 Thread Nickolay V. Shmyrev
В Чтв, 07/06/2007 в 11:06 -0500, Roy Pittman пишет:
 This is my first post to this list.  I have been reading it for a while and 
 have a script to offer to all of you but am unsure if this is the right 
 place.  Any guidance will be welcome.

Hello Roy, you are welcome.

 The problem:  it is not convenient to move contacts information from MS 
 Outlook to Evolution.
 
 My solution: a bash script that will read a dos csv file exported by Outlook 
 and re-order that data into a vcard file that Evolution can easily import.
 

Well, it's important thing. I've meet this problem several times in the
past and was blaming everything. But in recent Evolution there is
imported for Outlook's CSV. What version are you using?

 This script works pretty well.  I had fun solving some interesting logic 
 problems to make it work.  I want to see it used and to get suggestions for 
 improvements.  I have registered my copyright on this script but intend to 
 release it under GPL and give it to the community.  I will send this script 
 to anyone on this list who is interested.
 
 Thanks,
 
 Roy Pittman


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

2007-06-09 Thread Philip Van Hoof
On Fri, 2007-06-08 at 20:45 -0400, Jeffrey Stedfast wrote:
 On Fri, 2007-06-08 at 18:34 +0300, Philip Van Hoof wrote:
  The imap4 project is making things look better, though all in all it's
  still much of the same (blocking and waiting for results, in stead of
  letting the server do most the work and do pipelining).
 
 adding pipelining support would not be difficult to do, actually.

I noticed that, indeed. Last time I was reading it, I did notice a few
things in its code that would make it difficult.

All in all, the ideas behind the 'imap4' way of working (with the IMAP
server) are indeed a lot better than the 'imap' code.

Maybe it would be a good idea to bring features like condstore and idle
to it? If there are some more people interested in this, I would
probably help out too. Unlike the stuff that I have put in the 'imap'
code, this should be done in a proper non-hackish way then, imo.

What I disliked most about Camel's 'imap' code, though, is the fact that
the sequences have to correspond to the array indexes of the
CamelFolderSummary. It sounds like it would have been more easy if that
was a key in a hashtable.

For example if a message got expunged that had a sequence value in the
beginning of the folder, it right now more or less means that the entire
folder has to be re-synchronised. While the majority of the local data
can be perfectly corrected in stead too.

Luckily very few people often remove things in the beginning of their
mail folders (since those E-mails are usually the older emails).

I have some ideas on having blocks of mmap data for CamelFolderSummary,
that for example contain ~ 1000 items per block, and having reference
counting per block.

That way I could create a vfolder-like feature that keeps only the
blocks alive that contain summary items that matched the query. In stead
of having to keep all the memory of each folder in the vfolder alive.

I have a prototype of this somewhat working, although done extremely
hackish too. So at some point I'm going to rewrite this first.

Another benefit is that the blocks will never have to be rewritten:
removals are simply marked until  50% of the block is removed (and then
the entire block is rewritten), flag changes are stored in a different
file and on push-email events or a summary download, the latest headers
are kept in normal memory until there are enough of them to start a new
block.

Rewriting the summary file truly is a hit on performance on some
devices. On Flash it also introduces some level wearing. Which is why
it's another benefit.



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


Re: [Evolution-hackers] Introduction and Questions

2007-06-09 Thread Jeffrey Stedfast
On Sat, 2007-06-09 at 13:00 +0300, Philip Van Hoof wrote:
 What I disliked most about Camel's 'imap' code, though, is the fact that
 the sequences have to correspond to the array indexes of the
 CamelFolderSummary. It sounds like it would have been more easy if that
 was a key in a hashtable.

...???

are you serious?

 
 For example if a message got expunged that had a sequence value in the
 beginning of the folder, it right now more or less means that the entire
 folder has to be re-synchronised. While the majority of the local data
 can be perfectly corrected in stead too.

huh? it doesn't re-fetch anything, it simply removes the item from the
array at the index given in the untagged EXPUNGE notification.

server says:

* 1 EXPUNGE

camel-imap-summary does:

g_ptr_array_remove_index (messages, seqid - 1);

(seqid in this case would be '1', but keep in mind that IMAP seqids
start at 1 while in c, array indexes start at 0)

How would a hash table simplify this? It'd only serve to complicate
things because you'd have to re-key the entire hash table after each
EXPUNGE notification. Not to mention it would consume a fair bit more
memory...

Jeff


___
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-09 Thread 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.
-- 
Gilles Dartiguelongue [EMAIL PROTECTED]
EE/CS last year student, ESIEE


signature.asc
Description: Ceci est une partie de message	numériquement signée
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers