Re: [Evolution-hackers] Missing half of my preferences ... ?
Hello, is there anything on the console? There should be some message explaining what's going on, probably. I have there (from top to bottom) Mail Accounts, Autocompletion, Mail Preferences, Composer Preferences, Calendar and Tasks, Certificates. All about mail is missing for you, hmm. You've probably broken mail component. I'm using fresh SVN version and works for me, maybe recompile whole project, after 'make distclean'. But depends on the messages on console. Bye, Milan On Fri, 2007-11-23 at 13:34 -0500, Paul Smith wrote: I'm using Evo from SVN HEAD, latest version as of just this morning. For the last week or so at least, when I select Edit - Preferences, most of my options in the left menu are missing. I have Autocompletion, Calendar and Tasks, and Certificates, and that's all; I'm missing Mail and Composer stuff altogether, and whatever else should be there (I can't actually remember!) Does anyone else see this, or is there something corrupted about my environment? ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Missing half of my preferences ... ?
I think you've mixed up versions, somehow/probably. Try 'make distclean', check if you've setup right paths for libraries, eds and so on, and then ./autogen.sh ... whole evolution. I guess it compiled against older factory, which didn't know those components of version 2.22. (probably older object file, maybe from other directory?) Milan On Fri, 2007-11-23 at 15:10 -0500, Paul Smith wrote: On Fri, 2007-11-23 at 20:55 +0100, Milan Crha wrote: is there anything on the console? There should be some message explaining what's going on, probably. Doh! I turn on all debugging and carefully keep it around but I forgot to look. You're right, when I select Preferences I get this: (evolution:30484): evolution-mail-CRITICAL **: file mail-config-factory.c: line 52 (mail_config_control_factory_cb): should not be reached (evolution:30484): evolution-shell-WARNING **: Cannot activate OAFIID:GNOME_Evolution_Mail_ComposerPrefs_ConfigControl:2.22 -- Factory `OAFIID:GNOME_Evolution_Mail_Factory:2.22' returned NIL for `OAFIID:GNOME_Evolution_Mail_ComposerPrefs_ConfigControl:2.22' (evolution:30484): evolution-mail-CRITICAL **: file mail-config-factory.c: line 52 (mail_config_control_factory_cb): should not be reached (evolution:30484): evolution-shell-WARNING **: Cannot activate OAFIID:GNOME_Evolution_Mail_MailerPrefs_ConfigControl:2.22 -- Factory `OAFIID:GNOME_Evolution_Mail_Factory:2.22' returned NIL for `OAFIID:GNOME_Evolution_Mail_MailerPrefs_ConfigControl:2.22' (evolution:30484): evolution-mail-CRITICAL **: file mail-config-factory.c: line 52 (mail_config_control_factory_cb): should not be reached (evolution:30484): evolution-shell-WARNING **: Cannot activate OAFIID:GNOME_Evolution_Mail_AccountPrefs_ConfigControl:2.22 -- Factory `OAFIID:GNOME_Evolution_Mail_Factory:2.22' returned NIL for `OAFIID:GNOME_Evolution_Mail_AccountPrefs_ConfigControl:2.22' ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution doesn't honor LC_TIME (and other LC_ variables)
Hello, please consider already filled bugs too, see http://bugzilla.gnome.org/buglist.cgi?query=product%3Aevolution+date +time+format It gave me 30 bugs today. They are more or less related to the thing you are going to do. Bye, Milan On Wed, 2008-03-05 at 20:16 +0100, Raúl Núñez de Arenas Coronado wrote: I'll try to have some patch by tomorrow evening. Raúl DervishD Núñez de Arenas Coronado ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Largefile support
On Mon, 2008-04-07 at 14:23 -0400, Jeffrey Stedfast wrote: On Mon, 2008-04-07 at 13:29 -0400, Matthew Barnes wrote: On Mon, 2008-04-07 at 12:43 -0400, Jeffrey Stedfast wrote: The only 'gotcha' I can think of by enabling it by default is that it might break ABI if old builds were 32bit off_t's (the new off_t's would be 64bit). Oh, and fwiw, looking ahead, it may even be worth changing the public API to take goffset's rather than off_t's if breaking API is acceptable since it will prevent future off_t size issues (since I believe that goffset is supposed to be an int64_t) Yeah, and this would be the opportune time to do that if we're going to (early in the development cycle). Sounds like we should wait to enable largefile support by default until we do the goffset replacement, and then ship both changes at once with a soname bump. sounds reasonable to me Jeff Hi Jeff, I looked a bit at this, and even it seemed as 'find and replace' work, then it finally showed up that off_t is saved in a summary file. I'm not sure how to properly (and in the simplest way) handle this. The only thing I can think of is bump summary file version to indicate all offsets are 64bit regardless of the machine architecture, and for those old version files read the offset either as 32 bit or 64 bit. The problem is, when we turn on the large file support, then I cannot recognize what was the old size of off_t (before turning this on). Maybe I can do it with sizeof(int), which will tell me whether I'm on 32 or 64 bit machine, but it seems kinda strange (and smells like hack) to me. Also, I didn't check code completely, but is it right that summaries are overwritten always whole or did I misread code? Maybe there is better way, just drop summary if it's an old version and rebuild it, but I do not want to go by this way, because for local summaries there are (more or less) important data like user tags/flags, which I believe we should not delete to the user. Maybe any migration code? I still think I will need to know the old size of off_t anyway. And I would like to do that as much transparent as possible. What is your idea? Bye and thanks, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] e_canvas_new in Evolution
On Fri, 2008-06-13 at 12:17 +0530, svalbard colaco wrote:
Yup i got the sources but there is nt any anti-aliasedaa
mode of canvas generation . and e_canvas are diffrent from
gnome_canvases
i think.
Neither did i get a function for repainting a canavs.
Any more suggestions?
Hi,
based on the code, ECanvas is a descendant of the GnomeCanvas. I would
suggest, for testing, changing e_canvas_new from:
GtkWidget *
e_canvas_new (void)
{
return GTK_WIDGET (g_object_new (E_CANVAS_TYPE, NULL));
}
to
GtkWidget *
e_canvas_new (void)
{
return GTK_WIDGET (g_object_new (E_CANVAS_TYPE,
aa, TRUE, NULL));
}
or something like that.
For calling redraw, you can do it in a same way as for GnomeCanvas.
Bye,
Milan
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] e_canvas_new in Evolution
On Fri, 2008-06-13 at 17:16 +0530, svalbard colaco wrote: Thanks for your prompt reply, aa is not a member of the ECANVAS structure ; In gnome_canvas_new_aa() function aa is a member of the Gnome_canvas structure , defined as below /* Whether the canvas is in antialiased mode or not */ unsigned int aa : 1; And the link below gives us the details of the two modes of gnome canvas operation http://developer.gnome.org/doc/GGAD/z177.html So making the aa modification; will it understand as to what is to be done? Are these two modes supported in Ecanvas ? what do you suggest ? Hi, based on this documentation of GnomeCanvas, http://library.gnome.org/devel/libgnomecanvas/stable/GnomeCanvas.html#GnomeCanvas--aa you can pass this property in construction time, which I believe means in call of g_object_new, and because ECanvas is the specialization of the GnomeCanvas, then the GnomeCanvas will set this property, same as it does in gnome_canvas_new_aa: http://svn.gnome.org/viewvc/libgnomecanvas/trunk/libgnomecanvas/gnome-canvas.c?revision=1286view=markup Hope that helps, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Contact component in Evolution source code
On Thu, 2008-06-19 at 15:20 +0530, svalbard colaco wrote: Hi Milan Thanks ... I actually want to Know the first view where its writen Double_click here to create a new contact the source code for it. here i can double-click on the canvas and add entries. right? so is it the table or mini card now?? once i make entries the entire canvas changes color red/brown etc... so i need to Know wer to debug.. Thanks Regards sv. Hi, just open one of them and search there. The one is addressbook/gui/widgets/e-minicard-view.c: in function 'set_empty_message' is this text set, but I'm not sure how much this will help you. I guess the canvas changed its color because the drawing of the minicard left it in some state, like set different color or something, but it doesn't do this on Linux, so possibly something out of evolution? Just a guessing, I can be definitely wrong. Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Bug 499932] Not deleting from e-mail server after specified time
On Tue, 2008-08-26 at 19:55 +0200, Patrick Ohly wrote: Hello, Can one of the Evolution email hackers have a look at bug 499932 [1]? This has been open since 2.12 and still applies to the latest stable version. I'm affected myself, so I can help debug this if necessary. Thanks! [1] http://bugzilla.gnome.org/show_bug.cgi?id=499932 Hi, I updated the bug with this text: I believe this has been fixed within bug #514827 and is included in development version. Can someone check, please? Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Bug 499932] Not deleting from e-mail server after specified time
On Thu, 2008-08-28 at 21:04 +0200, Patrick Ohly wrote: [snip] I compiled the trunk and tested it - it works. Thanks! Is this something for the distributors to back-port to 2.22.x? Hi, it's up on them. Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting all mail
Hi, On Mon, 2009-06-22 at 20:43 +0200, Filipe Nepomuceno wrote: The problem I'm having now is when I ask for the folderinfo it returns a null pointer at the point indicated below. Evolution is set-up with a gmail pop account. When I tried it with the IMAP settings it worked and I managed to get the CamelFolders. Might be that it uses On This Computer for storing/showing mails. Look for mail-component.c:mc_setup_local_store for an example how to open the local store. (There should be enough to construct proper URL and use it like the one from an EAccount structure, I guess.) See also load_accounts in the same file, as you do not check for enabled accounts only. The other thing I don't understand is the threading thing. Could someone please explain that. I'm afraid this is out of scope of this mailing list. What do you mean exactly? One more question, I cant seem to compile the devel-guide, is there an online version of it? I've just been grepping everything and wanted to know if there is some kind of API out there that makes it easier. Hmm, I usually look around the code. Some information can be found also on http://go-evolution.org but I've no idea how much accurate/up-to-date it is. Maybe someone else knows where to find the online devel-doc version. Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel calls causing hangs?
On Tue, 2009-06-23 at 22:43 +0200, Filipe Nepomuceno wrote: for(j = 0; j uids-len; i++) ^^^ use 'j' here? Try to differentiate between hang and busy loop, there is a little difference between them :) Also, those returned CamelObjects are supposed to be unreffed too, not just free your array. Even I cannot tell you from this code part, as it's not complete. (Those mail-ops functions I pointed you earlier are unreffing arguments itself, at the end, thus in the best you should ref them, and when done with them unref them. There is no reffing necessary when you use it in the done callback only, but when you left the callback and still need the pointer, then there should be a ref and unref done. Just to ensure you'll not lose the pointer before you are done with it. I think. Check the code where those are used in evolution.) Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Weird folder selection bug
Hi, On Fri, 2009-07-03 at 13:56 +0200, Christoph Höger wrote: * ping * Has no one a clue on that? Most likely. On Tue, 2009-06-30 at 11:17 +0200, Christoph Höger wrote: When I want to select the folder in which evolution puts it's mail, the selection button changes it's label to the selected folder name. The problem is: The selected folder name is: a) translated (leading to Verschickt instead of Sent which would be the correct name. (Verschickt is the german translation of the evolution internal Sent mail folder, Sent is a subfolder of my Maildir account) It shouldn't do that, but it does. I doubt it's question on glade, it's evo's/eds' fault most likely. b) misinterpreted on reopening that dialog. Instead of the selected folder (Maildir/Sent) I get Verschickt selected as if the selection did not change anything (what in fact it did - new mail is dropped into Maildir/Sent) Probably because of a). Though cannot tell for sure without further investigation. So my first thaught was: Is that glades fault (the buttons label is set to translatable) and could that be fixed by setting the buttons translatable value to false (or would than _nothing_ get translated at all)? See above, no. And: What the f*** does that dialog get as content? Somewhere the correct information (aka Path) is stored, as it works. But from that point to the dialogs display it gets turned into a completely different path. How is that even possible? That's how it works, it might take much longer to explain you the interns than spending time on trying to fix it. Basically, there are paths to the folder how they are used by camel, and how they are used in evo, the later contains an account name in it. See em_uri_to_camel/em_uri_from_camel. I'm not sure if I got it right. It works, with respect of moving messages to the correct folder, only the UI is confused with the Sent name, which it considers as a special folder, thus translates it, when you reopen the account editor dialog again? Anyway, please file a bug, that's no waste, that's much better way how to track patches than in a mailing list. Thanks and bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GAL Question
On Mon, 2009-07-20 at 11:21 -0400, Kevin Boyce wrote: I am new to the mailing list. I apologize if this is the wrong place to ask such a question. I've configured my evolution account to work with my company's exchange global address list, and that appears to work OK. However, often the GAL server goes offline. I would like to make an offline copy of the GAL to my local computer so that I don't depend on the server too much. Is there a way I can get a dump of the address book and copy it locally? I tried doing an Advanced Search based on email address containing @mydomian.com but it says that the backend refused to process the search. I was hoping I could select all the contacts in the resulting search and drag and drop them to another location. Any help on the above matter would be appreciated. Thanks, Kevin Hi, it's usually better to use evolution-list, than the evolution-hackers list, as this is more user-related question than anything about code. Anyway, since 2.23.90 (I guess based on the time of patches commit from bug [1]) you can setup your GAL to be browseable (in account preferences), then with limits large enough you should be able to see all your contacts. Either dragdrop them, or even better right click over the GAL address book and choose Save as vCard, and then import this resulting vCard file to your local address book. Your way of doing this might work too, though, just do not use advanced search, (it doesn't seem to be usable with GAL in general) but use just a simple search on the Name Contains, and choose some very common latter, like a or similar. Though the browsing method with large enough limit is more appropriate. Hope that helps, Milan [1] http://bugzilla.gnome.org/show_bug.cgi?id=324203 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] how to initialize bf-priv-file_db
On Thu, 2009-08-13 at 09:03 +0800, Saint yeyo wrote: Hi, maybe I will sound silly, but what type a bf is? What is its parent object? You know, you just give here some expression from somewhere. The context is missing, at least for me. Bye, Milan sorry, the data struct is like following: EBookBackend *backend; EBookBackendFile *bf = E_BOOK_BACKEND_FILE (backend); DB *db = bf-priv-file_db; // here occurence segmentation fault then I tried backend = malloc(sizeof(EBookBackend)); backend-priv = malloc(sizeof(ebookbackendvcfprivate)); backend-priv-file_db = malloc(sizeof(DB)); it's better, but still can't access the address of file_db, how can I do, than you. Hi, EBookBackend is a GObject, you should create it by g_object_new call. But, you should never need to create a backend on your own, you should use EBook with a proper ESource. What exactly are you trying to do, please? Bye, Milan P.S.: Please, never ever reply to digest, at least on evo lists. Moreover, you kept there all the mail long because of quoting 5 lines of text? That's not nice. Not talking about broken threading. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] how to use e_contact_new_from_vcard function
On Thu, 2009-08-13 at 17:26 +0800, Saint yeyo wrote: while I used function 'e_contact_new_from_vcard (vcf_file) ' based on a exported vcard file Hi, the vcf_file is a file name or a file content? It should be the file content here, which contains those BEGIN:VCARD/END:VCARD tags. Something like here [1], just not with a vCard. Here's [2] a little big about EBooks. Look for other tests in that folder for other examples. Hope that helps, Milan [1] http://svn.gnome.org/viewvc/evolution-data-server/trunk/addressbook/tests/vcard/dump-vcard.c?revision=7761view=markup [2] http://svn.gnome.org/viewvc/evolution-data-server/trunk/addressbook/tests/ebook/test-ebook.c?view=markup ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Programmatically Invoking Contact Editor
On Thu, 2009-08-13 at 16:41 -0700, Kip Warner wrote: Thanks Matt. I've found the contact-uid by querying the EContact pointer via e_contact_get_const(contact, E_CONTACT_UID), but I can't seem to find the source-uid anywhere. Hi, source-uid is the UID of an EBook you've your contact stored in. If it's just the contact not stored in any EBook, then no such thing is possible. Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Changes from 2.26 to 2.28
Hi, On Sun, 2009-10-04 at 10:22 +0100, Tobias Mueller wrote: On 04.10.2009 02:47, Rohan Agrawal wrote: * In the panel that lists the mails, each mail is given a much wider space, which seems like a waste. GNOME already consumes a lot of screen space with very big controls and text, when compared to Windows or to KDE. Could you make a screenshot and file a bug at https://bugzilla.gnome.org/? this is your bug: https://bugzilla.gnome.org/show_bug.cgi?id=565780 * The Date column now uses n days ago for mails within the last week, rather than the day of the week. My impression is that Sunday is more understandable than 6 days ago. If there is no (obvious) setting for this, I'd file a bug :-) Yeah, there is no such enhancement request (or I'm not aware of it, at least). The request sounds good to me, please file it and point us to it. Thanks and bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Errors logging into MAPI
Hi, On Thu, 2009-10-22 at 02:31 -0400, Paul Smith wrote: On Sun, 2009-10-18 at 17:30 -0400, Paul Smith wrote: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connectio n.c:2856: Leaving exchange_mapi_get_folders_list libexchangemapi-Message: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-folder.c: 139: exchange_mapi_peek_folder_list: unlock(folder_lock) libexchangemapi-Message: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connectio n.c:3106: exchange_mapi_create_profile: unlock(connect_lock) libexchangemapi-Message: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-folder.c: 134: exchange_mapi_peek_folder_list: lock(folder_lock) libexchangemapi-Message: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-folder.c: 139: exchange_mapi_peek_folder_list: unlock(folder_lock) ^^^ this is just a debug output e-data-server-ui-Message: Unable to find password(s) in keyring (Keyring reports: No matching results) e-data-server-ui-Message: Key file does not have group 'Passwords-ExchangeMAPI' ^^^ this is nothing serious, only keyring reports that the group doesn't exist. The group will be created the first time you successfully enter your password. As Evolution is asking keyring for your password first, and if not found then asks yourself, then the error is shown. It is also sort-of debug message. I re-entered my password (I was leery of this because the other day I locked my account by Evo asking for my password too many times in a row) but the second time it took and worked. Good it works finally. Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Retrieve signal of 'Junk' / 'Not Junk' button in Evolution mail
On Mon, 2009-11-23 at 18:00 +0800, Arumugam Vkk wrote: My team created a spam filter that is being integrated into Evolution mail for our final year project. We have no problem reading the mails and everything is almost complete. Currently working on the retraining of Bayesian and we need to know how do we retrieve the signal when we click the 'junk' / 'not junk' button. Hi, have a look how's done the bogofilter junk plugin http://git.gnome.org/cgit/evolution/tree/plugins/bogo-junk-plugin or the SpamAssassin plugin http://git.gnome.org/cgit/evolution/tree/plugins/sa-junk-plugin in evolution. Doing your spam plugin the similar way you'll be able to choose it in Edit-Preferences-Mail Preferences, tab Junk. (Maybe you have it that way already, I do not know.) Hope that helps, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Failing to build latest GIT code
On Tue, 2009-11-24 at 12:25 -0500, Paul Smith wrote: On Tue, 2009-11-24 at 12:15 -0500, Paul Smith wrote: What am I missing here? found it. Please apply this patch to fix the build: Hi, hrm, I would like to know why I didn't face that when doing the change there. Maybe an older gcc or something? Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI support not even close... ?!?! Can I help?
On Thu, 2009-12-03 at 16:10 -0500, Reid Thompson wrote: hmm -- is calling evolution supposed to auto-start these two? On Thu, 2009-12-03 at 16:12 -0500, Reid Thompson wrote: (evolution:24437): libebook-WARNING **: ../../../../evolution-data-server/addressbook/libebook/e-book.c:2194: cannot activate book: The name org.gnome.evolution.dataserver.AddressBook was not provided by any .service files Hi, yes, those two processes are run as a DBus services. The relevant files are in your $PREFIX/share/dbus-1/services/ and dbus is supposed to be directed to that directory too, to know about them. There are more options to do that, what I do is making a symlink to that folder: $ rm /usr/local/share/dbus-1 2/dev/null $ ln -s $PREFIX/share/dbus-1 /usr/local/share/dbus-1 The only disadvantage of this solution is to have changed rights on /usr/local/share/ to be able to write there even as a regular user. Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] I broke junk filtering config -- help!
On Fri, 2009-12-04 at 13:47 -0500, Paul Smith wrote: On Fri, 2009-12-04 at 12:21 -0500, Reid Thompson wrote: On Fri, 2009-12-04 at 12:11 -0500, Paul Smith wrote: Looking at the /apps/evolution/mail/junk/bogofilter section of gconf with gconf-editor, I see only one entry here, unicode which is selected (boolean true). this is all that i have in my gconf. one level up has a bunch, of note is check_incoming and default_plugin Grr. Yes, I have those both set (default_plugin is Bogofilter). Anyone have any ideas about logs or places I should look? *sigh* Hi, this all should be manageable from Preferences itself, try Edit-Preferences-Mail Preferences, tab Junk, whether you've enabled automatic junk filtering in global, then, just in case, in Mail Account-account-tab Receiving options, whether junk filtering is enabled on the account. Note, with the former, you can skip checking with the junk plugin itself, when, for example, the sender is in your address book. Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Error reporting changes
On Mon, 2009-12-07 at 14:41 -0500, Reid Thompson wrote: if i wished to attempt to update evolution-remove-duplicates to git head http://www.gnome.org/~carlosg/stuff/evolution/ Hi, here's your bug report about the same http://bugzilla.gnome.org/show_bug.cgi?id=587011 Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Error reporting changes
On Tue, 2009-12-08 at 13:13 -0500, Reid Thompson wrote: I applied Ritesh's patch from comment 27 and compilation fails with ../../../../evolution/modules/mail/e-mail-shell-view-actions.c:505: error: implicit declaration of function ‘message_list_free_uids’ Hi, bad luck, it had been removed recently for some reason, see commit 76fbb9d. Is/Are one/all of the previous patches required also? The first patch is for the external plugin itself, applicable to tar.gz sources of it, whereas the second patch, the ritz's one, is to have this plugin as internal code, not a plugin. These two are supposed to be independent. Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
On Wed, 2009-12-16 at 11:35 -0500, Jeffrey Stedfast wrote: The summary files would have had this problem, but they would have just been regenerated, so not really an issue. Hi, a) it's similar as moving from 32bit to 64bit architecture or the other way; evo crashes for these situations, because the version is fine, but it doesn't know whether the previous one was a 32bit or 64bit machine, aka whether it should do some translation or not. (and doing translation is not as that simple for usage of functions which are doing sizeof(...); not a problem with db-summary, but still might be with indexes and store summaries, I didn't check that.) b) you cannot just drop it and regenerate, because it holds some information for local providers, like labels, tags and such. Silly reasons, but that's why I think those bugs are still opened (no numbers handy). Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
On Wed, 2009-12-16 at 19:56 -0500, Jeffrey Stedfast wrote:
Does it really crash? It used to just regenerate the summary files.
yes, on out of memory, as it tries to allocate a very large memory block
due to misreading items.
b) you cannot just drop it and regenerate, because it holds some
information for local providers, like labels, tags and such.
The point of the version info was so that you could do things like:
if (summary-version CAMEL_64BIT_SUMMARY_VERSION) {
off_t offset;
camel_file_utils_load_off_t (file, offset);
info-offset = offset;
} else {
camel_file_utils_load_int64 (file, info-offset);
}
If you do this, then you don't actually lose any information.
I do not think the above will work together with defaulting to LARGEFILE
compile flag, but the other way would, like defaulting to load_int32 for
older summaries and reading off_t for new. I'm wondering whether some
distro has the largefile support enabled these days, as if so, then the
decision what to use as an off_t size isn't that easy. Maybe they have,
or it's enough to compile under 64 bit to have the size changed.
I didn't try this, I just suppose because of reported issues.
Milan
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Access Contacts information from Remote Machine with Python
Hi, On Fri, 2009-12-25 at 11:57 +0100, Michael Pilgermann wrote: Could anybody please give some advice, whether - there is a way to copy the database to another machine by keeping it working, or It should work as long as the Berkeley DB library is compatible with that used on the older computer. EDS used to use its own copy of it, but it was dropped in favor of a system libdb. Here might be some useful information too, I guess. http://www.go-evolution.org/FAQ#How_can_I_transfer_all_my_Evolution_data_from_an_old_home_directory_to_a_new_home_directory.3F Nonetheless, playing with internal evolution files is highly discouraged. - how to remotely access the EDS in Python using the proper way?? I've not much idea about python bindings on EDS side, the nearest I know are some python binding for plugins in evo itself, but it's far away from what you want. Here's an example how to open a system address book and read emails from contacts stored there: http://git.gnome.org/browse/evolution-data-server/tree/addressbook/tests/ebook/test-ebook.c Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] How notifications work?
On Tue, 2010-01-05 at 11:24 +0200, Cristian Vrabie wrote: Hi guys! I've been using Evolution for a long time, but only recently i decided to get look into the code and maybe give a hand with the development in the little free time i get. I wanted to start small issue that interested me, more exactly why in KDE, when you receive a new message, the raised notification does not properly indicate the folder where the message ended up after filtering. I created this bug https://bugzilla.gnome.org/show_bug.cgi?id=605986 which apparently is not an Evolution issue but of libindicate. In order to fully understand that, can you give me a quick high level description of how notifications are raised by Evolution transparently of the notification library of the desktop environment? Thanks! Cristian Hi, Evolution is using a plugin to notify about new messages, and this plugin is listening for events invoked by Evolution itself. See the source code at [1] for more information. Nonetheless, if I understand your request properly, then it was covered by [2] and is part of the latest git master. Note also that there are some settings in Edit-Plugins-Mail-Notification, tab Configuration, where you can influence how the notifications should behave. If you are looking for some (usually) simple tasks, then there is a keyword gnome-love, which developers use to mark some bugs as good for beginners, thus maybe go through them. Note that something what might look easy at the beginning can turn to be hard task. See the list for evolution itself at [3]. [1] http://git.gnome.org/browse/evolution/tree/plugins/mail-notification [2] https://bugzilla.gnome.org/show_bug.cgi?id=464400#c16 [3] https://bugzilla.gnome.org/buglist.cgi?quicksearch=keywords% 3Agnome-love+product%3A%22Evolution%22+ Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting a core in latest git Evolution view Junk folder
On Wed, 2010-01-06 at 17:17 -0500, Paul Smith wrote: Whenever I click on my Junk folder Evo dumps core. It seems to be an error displaying the summary of my Junk folder. I'm avoiding it right now. Hi, I'm on actual master as well, and I do not see this. I tried to select Junk folder of my IMAP account, under On This Computer, but none of these exhibits your issue. What account type is your Junk folder from? Do it all Junk folders or only some of them? When you close evolution and move out (do not delete it) folders.db file for that account, will it fix itself? Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting a core in latest git Evolution view Junk folder
On Thu, 2010-01-07 at 08:04 -0500, Paul Smith wrote: ... Since the failure appears to be related to determining something about attachments. ... As I mentioned, it's connecting to an IMAP server. Oh, my fault, IMAP with mail with an attachment in junk folder. I can reproduce it too, with a message as an attachment. Please file a bug report about it. Thanks. Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-mapi exchange 2007 fails to send messages encoding in non-english characters
On Fri, 2010-01-29 at 01:04 -0800, Fred Liu wrote: Is there anyone who has ever met this? Hi, there have been some bug reports in https://bugzilla.gnome.org but the fix came to the quite recent: https://bugzilla.gnome.org/show_bug.cgi?id=608320 Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Build failures with latest git in evolution-mapi
On Tue, 2010-02-02 at 16:57 -0500, Paul Smith wrote: CC exchange-mapi-utils.lo In file included from /opt/evo-master/include/util.h:26, from /opt/evo-master/include/ndr.h:32, from /opt/evo-master/include/dcerpc.h:33, from /opt/evo-master/include/libmapi/libmapi.h:50, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.h:31, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.h:28, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:29: /opt/evo-master/include/charset.h:125: warning: redundant redeclaration of 'strchr_m' /opt/evo-master/include/charset.h:104: note: previous declaration of 'strchr_m' was here In file included from /opt/evo-master/include/dcerpc.h:33, from /opt/evo-master/include/libmapi/libmapi.h:50, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.h:31, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.h:28, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:29: /opt/evo-master/include/ndr.h:517: warning: redundant redeclaration of 'ndr_print_bitmap_flag' /opt/evo-master/include/ndr.h:516: note: previous declaration of 'ndr_print_bitmap_flag' was here In file included from /opt/evo-master/include/gen_ndr/exchange.h:9, from /opt/evo-master/include/libmapi/libmapi.h:57, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.h:31, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.h:28, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:29: /opt/evo-master/include/gen_ndr/ndr_misc.h:12: warning: redundant redeclaration of 'ndr_print_GUID' /opt/evo-master/include/ndr.h:375: note: previous declaration of 'ndr_print_GUID' was here /opt/evo-master/include/gen_ndr/ndr_misc.h:17: warning: redundant redeclaration of 'ndr_push_policy_handle' /opt/evo-master/include/ndr.h:493: note: previous declaration of 'ndr_push_policy_handle' was here /opt/evo-master/include/gen_ndr/ndr_misc.h:18: warning: redundant redeclaration of 'ndr_pull_policy_handle' /opt/evo-master/include/ndr.h:492: note: previous declaration of 'ndr_pull_policy_handle' was here /opt/evo-master/include/gen_ndr/ndr_misc.h:19: warning: redundant redeclaration of 'ndr_print_policy_handle' /opt/evo-master/include/ndr.h:494: note: previous declaration of 'ndr_print_policy_handle' was here Hi, I see these as well, but didn't figure out what's going on. I was told about two different samba's installed, but I didn't check that yet. Though what we have common is a different install prefix from the one used by default, which is /usr/local/samba. ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c: In function 'utf8tolinux': ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:71: error: implicit declaration of function 'windows_to_utf8' ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:71: warning: nested extern declaration of 'windows_to_utf8' ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:71: warning: assignment makes pointer from integer without a cast make[4]: *** [exchange-mapi-utils.lo] Error 1 make[4]: Leaving directory `/opt/src/evo/evo-master/obj/evolution-mapi/src/libexchangemapi' windows_to_utf8 was removed in Openchange trunk, in favor of correct fix for this. You can change the utf8tolinux in your build to simply return g_strdup (wstring); and that's it. The function had some issues, was able to drop letters like @!,() from strings, if you noticed. It's still under its way, but better now. With respect of fixes around this in evolution-mapi and openchange you mentioned in the other email, there was a change for reading values in evolution-mapi, but changes for writing values were in openchange. For example, if your subject contains any utf8 letter, then that will be properly encoded in the openchange functions in actual trunk, where it just failed to send such message before the change. I do not want to go too far with details, thus just saying there is still some effort to fix even more cases for this, initially in openchange, and if required then also on evolution-mapi side, for better experience with utf8 strings received/sent with MAPI. Bye, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution 2.28 does not load calendars anymore
On Tue, 2010-03-30 at 05:03 +0200, Thomas Mittelstaedt wrote: There also is an error message: (evolution:6613): libecal-WARNING **: ../../../../evolution-data-server/calendar/libecal/e-cal.c:1046: Could not activate calendar factory (OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2) I wiped out my whole /opt/evo directory and installed everything afresh. No change. Hi, there is definitely something with your bonobo activation server. Check if yours $PREFIX/lib/bonobo/servers/GNOME_Evolution_DataServer_1.2.server contains proper path to an evolution-data-server-2.28 within the CalFactory section, and whether you can run it on a console and whether your bonobo-activation-server knows about it (it doesn't, most likely). Try to search http://live.gnome.org/Evolution/FAQ for bonobo questions. Hope that helps, Milan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] WebDAV Addressbook Debugging
On Fri, 2010-04-23 at 13:25 -0400, Adam Tauno Williams wrote: I am testing Evo with our GroupDAV server and after a moment it responds with 'address book not available' and instructs me to restart Evolution. Running Evolution from the command line doesn't provide any additional information. Hi, it means your evolution-data-server (for 2.28-) or e-addressbook-factory (for 2.30+) crashed. Try to run it on another console, maybe under gdb, and see where it crashed and why. With respect of the initial question, I do not see any getenv call in webdav address book sources, thus it seems it doesn't have any such thing. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-mapi is failing to compile on gnome-2.30 branch
On Sun, 2010-04-25 at 22:05 -0400, Paul Smith wrote: ... exchange-mapi-connection.c: In function 'exchange_mapi_events_init': exchange-mapi-connection.c:3160: error: too few arguments to function 'RegisterNotification' ... Help? Hi, you've too new OpenChange, the API for this function changed. It is fixed on master, and now on gnome-2-30 too. Please update your git repo or download 0.30.1 tar-ball. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GIT master failing evolution-data-server build...
On Fri, 2010-04-23 at 20:22 -0400, Paul Smith wrote: In function `ebook_test_utils_book_async_add_contact': ebook-test-utils.c:160: undefined reference to `g_malloc0_n' Hi, I do not see these myself, but from other experience I believe it's linking to wrong GLib, to the older one, than it is compiled with, or some other module it is linking to itself is using a newer GLib. I'm not sure, but try to add glib-2.0 to EVOLUTION_ADDRESSBOOK_DEPS in configure.ac, whether it'll help. Or maybe any of your environment variable isn't referring to the right path? Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Base URI for On This Computer
On Tue, 2010-06-08 at 21:17 -0400, Matthew Barnes wrote: Is there any reason why we can't just use file:// as the base URI for the On This Computer source group? No other group uses that scheme, so it seems we could identify the On This Computer group as file:// as easily as file://home/mbarnes/.evolution/calendar/local. Plus it would solve a whole class of migration issues and help make moving to XDG base directories easier. I can't find anything that actually uses the source group's base URI to locate files -- everything I see uses a hard-coded path, which actually works out well for me in this case. Hi, I'm not much sure what you are trying to do, but even you probably know, the e_source_get_uri uses ESourceGroup's base uri and a relative uri of the ESource to build the full uri, if not built/set an absolute uri on the ESource already. Are you going to change ESourceGroup's base_uri to contain only the protocol for all the ESourceGroups? If yes, then I think it's not the best thing, because for example evolution-mapi uses as base uri mapi://u...@server/, and each account you have configured and enabled in the preferences has its own group. It cannot be distinguished just by mapi://, because for example (I believe) every user has its default calendar named Calendar. Hope that helps, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes
On Thu, 2010-07-01 at 14:42 +0200, Patrick Ohly wrote: Will that break libebook and libecal APIs? The issue only mentions backends, but the subject of your emails includes EBook and ECal. Hi, for EBook it is, all the async API there uses 'status' as an indicator of the operation result in the async callback. I'm changing it to GError too. I'm still on ECalBackend, but it seems some similar change will be in ECal too, though I'm not sure yet, I'm not that far. I'll summarize changes in the bug report when I'll be done with it, to have them written somewhere. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo won't display special characters
On Sat, 2010-07-10 at 19:28 -0400, Paul Smith wrote: Is there any hope of anyone looking into this? I'm not even sure if it's a gtkhtml bug or an Evo bug at this point, all I know is I'm constantly being forced to forward email to my Exchange account and read it with Outlook in Crossover Linux, because Evo can't display these messages. Hi, yup, I've this in my todo list, since 21/06/2010, but due to other work I didn't get to it yet. I'm sorry. If someone provides a patch I'm happy to test it. Thanks, I appreciate it. Just to summarize, you've an issue involving https://bugzilla.gnome.org/show_bug.cgi?id=610797 that with a patch the reading is mostly fixed (when message is refetched, maybe - as I prefer the recent evolution-mapi git master due to its changes which couldn't be done in gnome-2-30, and recent openchange svn trunk (or say at least revision 1922) due to its changes with unicodeness and such, which are not part of openchange 0.9), but the patch also broke composer. Is it only this or more things left? Thanks and bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo won't display special characters
On Mon, 2010-07-12 at 12:56 -0400, Paul Smith wrote: Just to summarize, you've an issue involving https://bugzilla.gnome.org/show_bug.cgi?id=610797 ... To be clear, I'm seeing this with the IMAP (and IMAPX) backends, not with MAPI (it might happen with MAPI, too, but it's not MAPI-related). ... Hi, OK, let's move to the above bug report. I will go by David's pointers from the other reply, because if you see this in IMAP, then it is quite different issue than I thought initially. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] Datastructures for calendar data
On Wed, 2010-07-14 at 17:37 +0530, chen wrote: ECalComponent - This holds the calendar event's data in Ical format. It wraps Icalcomponent, but has not completely wrapped the same. So both are used at places. ECalComponent is better to use as its a Gobject. ECalBackendSync - Abstract class from which you would need to subclass kolab backend. (http://live.gnome.org/Evolution/CalendarStore) Hi, you said you want everything async, thus I agree with Ross, do not use ECal/BookBackendSync, but rather ECal/BookBackend parents, and do everything yourself (similar actions like ECal/BookBackendSync does, only fully asynchronously). I plan to rewrite evolution-mapi backends to be fully asynchronous. I'm not sure how it'll go and when I get to it, but maybe you would get inspired, if it'll be as I hope it. ... http://www.go-evolution.org/EDS_Architecture - I find that its not there in lgo, will need to be migrated. It's there, I'm not sure why it isn't shown up for you: http://live.gnome.org/Evolution/EDS_Architecture Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Couple new functions for ECal/EBook
On Sun, 2010-07-18 at 20:34 -0400, Matthew Barnes wrote: Only reason I wrote them for the client-side libraries is because e_cal_get_user_cache_dir() is used to figure out where to cache ECal attachments in set_local_attachment_store(). Hi, that's a part which should be changed. The ideal way, as I understand it, is to have an ECalBackend function to retrieve a path for attachments, and ECal should ask backend for it, instead of duplicating the code (it sort of blocks extendibility of ECalBackend, because the client side depends on the code in evolution-data-server itself, which is kinda wrong). It will be good to fix this and move functions to libedata-book/cal, where they, as you said, belong anyway. And because there were API changes for ECal/BookBackend anyway, then this one shouldn't hurt more. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: hiding IMAP folders
On Tue, 2010-07-20 at 13:18 +0200, Christian Hilberg wrote: Hm. Maybe I'm still missing some parts here on how Evolution internally works. Subclassing the Camel Provider in our backends and overloading get_folder_info() will work for the backend part, i.e. PIM data wich is accessed and managed from inside E-D-S. So far, no problem. But there is standard Email to handle as well, and if I understood correctly, Email handling is (presently) done inside Evolution, not E-D-S. Hi, others will correct me, but from evolution-mapi point of view (which is, with evolution-exchange, closest to that what you are trying to do): - create a Camel provider, which, when placed to the right place, will be shown in new account creation as an account type (see camel-mapi-provider.c, there's everything needed for having new mail provider available in Evolution). Evolution-mapi is extending basic camel objects, like CamelStore, but as you want to use IMAPX, then less work for you, derive from it. Note that this Camel part has nothing to do with EPlugin, the most you define an EPlugin to add menu options on your folders, like Folder Size option for MAPI folders, but other than that the EPlugin part is optional for mailer part. - for calendar and addressbook support create your own EBookBackend/ECalBackend descendants (with defined all the virtual methods there). You need an EPlugin to have them accessible from UI, to be able to setup specific things on it. See exchange-mapi-account-setup.c:exchange_mapi_create_addressbook and exchange_mapi_create_calendar as examples. Note these are mentioned in org-gnome-exchange-mapi.eplug.xml. - evolution-mapi's EPlugin also listens for changes on EAccountList (which is a list of configured mail accounts) and adds/removes ESource-s for addressbooks/calendars based on enabled/disabled MAPI accounts, keeping these three in sync, so the only thing user needs to setup is an email account, and the addressbook/calendar are added automatically. With respect of folder structure changes, the first sync will update internal caches as necessary, namely camel-store-summary, allowing you to hold the necessary information about each folder, and also adding the type annotation on it too. How or when fetch that annotation is a question for you. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: Some design thoughts on Email handling
On Fri, 2010-07-23 at 10:43 +0200, Christian Hilberg wrote: We would need the possibility to define extra D-Bus communication between Evo and E-D-S for that, right? Hi, I'll let Matt answer the rest of your mail, but before he gets to it here are my two cents: Camel (the mailer) is running in evolution process EBookBackend (contacts) is running in e-addressbook-factory process ECalBackend (calendar) is running in e-calendar-factory process What I thought you'll do the easiest way was to define your own camel, subclass of imap/imapx, and add some property of source-type to it, which will lead folder showing on all of them. This camel part will be compiled first, because you will need it in book/cal backends. Note you'll have three simultaneous connections to your server, from three different processes. I do not think moving mailer part to eds would help you much, the time where there was only one evolution-data-server-X.YZ process is gone :) Evolution exchange had been also running as a separate process, independently from evo and factories, some time back, which is very similar to your proxy, but it wasn't working well, so it was also rewritten in time of 2.29 (I think). Anyway, it is possible this way too; you'll get less connections to your Kolab server, if nothing else. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up
On Fri, 2010-07-23 at 18:08 -0400, Matthew Barnes wrote: For those following the master branch of git, that means that with any luck your ~/.evolution directory will soon be gone and you'll have far more control over where Evolution writes files. Hi, does this mean that one would be able to keep .evolution folder as is, with some XDG foo? You know, sometimes is useful to run 2.30.x while developing 2.31.x on the same machine, where your change makes it impossible. But if it's possible, do you know the XDG foo to achieve it? Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Gnome 3.0 delay Evo?
On Thu, 2010-07-29 at 01:23 -0400, Paul Smith wrote: I wonder if Matthew or Milan or anyone have any thoughts on what the delay in Gnome 3.0 means for Evolution. Hi, it means couple things, all positive. More work can be done, more testing can be done, less time pressure. Is the current git master buildable and usable without Gnome 3.0 components? Do you expect distros to build and ship both Gnome 2.x and 3.0 versions, to make transitions simpler? As far as I know most people are running evo with gtk2, but I have gtk2 on my main machine, and gtk3 on the other. Of course, testing with gtk3 is more appreciated (I have one crasher there already, though to be filled and fixed), thus also bugs/changes in gtk3 will be spotted on time. (I guess it doesn't answer your questions much) :) Let's see what's Chen's and Matthew's (module maintainers) idea on this. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory leaks
On Mon, 2010-08-23 at 11:12 +0100, David Woodhouse wrote: I got offended by Evolution growing to almost 4GiB and having to be killed if I wanted to use my workstation for anything else, so I've started running it in Valgrind. I've filed bugs for the reports of 'definitely lost', and have fixed a bunch of them. Hi, that's pretty bad. What are the bug numbers/links, please? But there are *lots* of reports of memory blocks being 'possibly lost', too. Should we be worrying about those? ... I'm therefore tempted to go ahead and file bugs for *every* report of 'possibly lost' that Valgrind gives me when I run Evolution. Please do not do that. Evolution has cache of CamelStore-s, CamelFolder-s and such, so almost anything from evolution can be pointed by some global/static variable. And indeed, these caches aren't freed by the application, but by the operating system itself. Even if some of them are false positives, I think we should find some way to tell Valgrind about them -- either with a suppressions file, or preferably by finding some annotation which lets Valgrind know that this 'interior-pointer' really *is* going to be followed. Even if it means cleaning up some false positives, I think it would be extremely useful to get to a point where valgrind runs cleanly and new memory leaks can easily be detected. I agree, though I'm afraid it's not possible (I didn't check valgrind yet, but I do not suppose it has any compiler flags/annotations in the code, because it uses the binary file itself, together with a debug information). I can be wrong here, though. Bye, Milan P.S.: I didn't CC you intentionally, because I know you are subscribed on this list, and because I do not want anyone CC'ing me on this list, because I'm subscribed to it too. ;) ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory leaks
On Mon, 2010-08-23 at 13:10 +0100, David Woodhouse wrote: On Mon, 2010-08-23 at 13:25 +0200, Milan Crha wrote: https://bugzilla.gnome.org/showdependencytree.cgi?id=627707 I've grouped a bunch of different GtkHTML reports together. although I'm not sure that was the right thing to do. The fixes I mentioned are sitting in my working tree, and I'll commit and push them today. Hi, good, thanks for it. ... If they're referenced by a global variable, surely valgrind would know that they're reachable and would not complain about them? I do not know how it works precisely. And if *not*, can we find a way to teach Valgrind that they're reachable, so that it can be useful for us and not have so many false positives? ... I had thought briefly about annotating the code, and perhaps extending sparse to handle refcounts and 'ownership' of memory so that it can warn at compile time if you write code which leaks. Hmm, I cannot imagine a way doing so with an async API. It would be a very complex call tree to solve, with evo and eds code mixed together, from my uneducated point of view (imagine all the libraries used in them, and all using evo/eds). But basically, what you seem to be saying is that Valgrind is essentially useless for us. I'm definitely not saying that. I like valgrind, it helps me (usually) pretty well. I just got a thought, what if some of those possibly lost come from GSlice? Then G_SLICE=always-malloc should help valgrind with it. At least a bit. I'd be very disappointed if that really turns out to be the case -- we should definitely talk to Julian about that before we give up. I'm not giving up, and as stated above, I like valgrind :) Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Can't build evolution-data-server master on ubuntu maverick
On Sat, 2010-09-04 at 05:30 +0200, Thomas Mittelstaedt wrote: .libs/libebook_1_2_la-e-book.o: In function `e_book_new_default_addressbook': /home/tuxdistro/src/evolution/obj/evolution-data-server/addressbook/libebook/../../../../evolution-data-server/addressbook/libebook/e-book.c:3329: undefined reference to `e_source_list_peek_default_source' Hi, I suppose you do not have latest master sources of the evolution-data-server. The missing function is part of libedataserver/e-source-list.c and it links to libedataserver-1.2.la, which I see it used in the Makefile.am in addressbook/libebook. The function was added just recently. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Can't build evolution-data-server master on ubuntu maverick
On Sat, 2010-09-04 at 09:12 +0200, Thomas Mittelstaedt wrote: More errors trying to compile gtkhtml: Making all in gtkhtml make[2]: Entering directory `/home/tuxdistro/src/evolution/obj/gtkhtml/gtkhtml' CC htmlengine-edit-cursor.lo ../../../gtkhtml/gtkhtml/htmlengine-edit-cursor.c: In function ‘draw_cursor_rectangle’: ../../../gtkhtml/gtkhtml/htmlengine-edit-cursor.c:129: error: implicit declaration of function ‘gdk_gc_new’ ../../../gtkhtml/gtkhtml/htmlengine-edit-cursor.c:129: warning: nested extern declaration of ‘gdk_gc_new’ ... Hi, is it with gtk3 or gtk2? The gtk3 isn't supported fully. The other option, even with gtk2, I think, is that might be similar to your eds issue, you might not have latest git master sources, because this commit seems to be relevant to your issue: http://git.gnome.org/browse/gtkhtml/commit/?id=e118a01dfefa589ce83fe43b13c5eb2732a0fcfb Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Can't build evolution-data-server master on ubuntu maverick
On Mon, 2010-09-06 at 23:27 +0200, Thomas Mittelstaedt wrote: Am Montag, den 06.09.2010, 23:20 +0200 schrieb Thomas Mittelstaedt: I downloaded and built gtk 2.9, the latest from the gtk website, and installed it into /opt/evo, where I try to build evolution. Hi, well, 2.9x is a development version of gtk3. Try the latest non-development version, like 2.20 from: http://www.gtk.org/download-linux.html I just pulled the latest sources from master, the gtkhtml configuration script tells me, that it's using gtk2: Configuration: GTK+ package: gtk+-2.0 Still the same compilation error. It might mean it's using your system gtk+. I gave you a commit link at the first reply, which contains that -DGDK_DISABLE_DEPRECATED removal, so you probably do not have latest master checkout for some reason, I guess. Seeing the code, isn't it possible that the makefile checkouts gnome-2-30 branch instead of the master branch? I ask because the above mentioned configure.ac change doesn't seem to be part of gnome-2-30 branch. Using master is a good idea, especially in this stage (few weeks before release), thus it'll have more testing, which is always good. With respect of compiling without the Paul's makefile, I do not use the makefile myself, so I do not know what it does or doesn't, but that one also checks for dependencies within the configure stage, so you can try to configure the checkout yourself and see what it'll claim about, if anything. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Can't build evolution-data-server master on ubuntu maverick
On Sat, 2010-09-11 at 03:45 +0200, Thomas Mittelstaedt wrote: Finally, I got evolution 2.31 to run, but the restoration of ics files from my 2.28 version is a problem. The memo (notes) ics-files are somehow not recognized, even if they are set correctly in the gconf keys. I tried the restoration using the installed version 2.30, having made sure, that services in /usr/lib are called instead of the ones of 2.31 in /opt/evo, and the app would restore memo ics files correctly, plus tasks and calendars. Then I tried to use this new .evolution directory with 2.31, having switched to the right services again and 2.31 doesn't show data for those memos, even though the list items in the left pane show up, but no entries. Hi, actual master, 2.31.92 very soon, doesn't use ~/.evolution, but XDG folders for its data. Everything is migrated on the first run, when ~/.evolution exists, but those XDG folders/files not. (It tries it every start, and complains on console). For your file backends were changed protocol from file:// to local:, thus the gconf key differs. Because you run 2.30 after 2.31, then I suppose you've duplicated On This Computer/Personal sources in calendar/task/memo/addressbook. Also see release notes at: http://mail.gnome.org/archives/ftp-release-list/2010-August/msg00023.html Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel Manifesto (update)
On Mon, 2010-09-27 at 12:52 -0400, Matthew Barnes wrote: Transient operations are now implicit: if you push a new status message onto a non-empty message stack, the message is treated as transient. A transient message just means there's a longer delay before the message is shown in Evolution's status bar, since transient operations tend to come and go quickly. If the transient operation finishes before the timer expires, the transient message is never shown at all. This helps filter out messages that would otherwise flash by too quickly for users to read. Hi, I do not like this change. Its result is that I do not see which folder is getting updated and what percentage is done on it, which I consider as one of the most valuable information being on the status bar. I only see there Checking for new mail now, and I have no idea about actual progress of the operation behind it. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] Datastructures for calendar data
On Mon, 2010-09-27 at 15:54 +0200, Hendrik Helwich wrote: while working on a plugin [1] to connect eds to a kolab server, i need to convert evolution contacts, events, tasks and notes to a kolab email (and back). Right now the idea is to use the class EContact for evolution contacts and ECalComponent for evolution events, tasks and notes. I now noticed, that an event in an evolution iCalendar file contains a VTIMEZONE and a VEVENT block, and the VEVENT block depends to a timezone which is defined in the VTIMEZONE block. The ECalComponent seems to hold only one block of an iCalendar object and it is therefore not possible to get all the informations of an evolution event from one ECalComponent. Hi, I think it was mentioned earlier, the ECalComponent is a wrapper for the icalcomponent. Evolution's UI is using ECalComponent, but, say as CalDAV, you can operate with icalcomponent internally, when there is a need for a VCALENDAR component used in the kolab email. With respect of VTIMEZONE, the ECalComponent has times/dates stored as ECalComponentDateTime structure, which has 'tzid' member (it's a const gchar *), and when the UI or a util function needs the VTIMEZONE, then it asks ECal through e_cal_get_timezone, which calls, through DBus these days, ECalBackend's e_cal_backend_get_timezone function. Note also that there is a default timezone for the ECalBackend, and that timezones can be also added to the backend from outside, not only from the server. It's used when copying events between backends, for example. Most ECalBackend-s are using ECalBackendStore, which has a facility to store both components and timezones. Hope that helps, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] Datastructures for calendar data
On Wed, 2010-09-29 at 17:15 +0200, Hendrik Helwich wrote: So one option for us is to operate on the icalcomponent instead of ECalComponent. Hi, internally yes, but remember, the ECalBackend API uses ECalComponent in most cases. In our project we do not need any time zone information which is attached to time data. It would be sufficient if all time data is stored in UTC format. Then we could stay with the ECalComponent class. Is there an easy way in evolution to strip timezone information from an ECalComponent by converting local time data to UTC time data? Well, timezone information is crucial for users, usually, and you might not change they will to use always UTC. You know, when you are adding a new appointment into a calendar, then you can choose your own timezone (View-Timezone), also a different one from that used in Evolution (which is used as a default timezone). Imagine a user, a businessman, whom is living in US and cooperates with a Europe partner on regular bases. Say they have a phone meeting twice a month, which is held in Europe in some certain time. So our businessman living in America/New_York will enter his meeting in Europe/Berlin, and he'll see this in his timezone (because he has it set in Evolution), even though the internal ECalComponent timezone is Europe/Berlin. What is it good for? I believe you know. It's good because changes from summer to winter time and vice versa are done in different weeks in these timezones, and because the organizer is in Europe, then the New York time will be shifted accordingly based on Europe time in these periods, so our business man will not miss his meeting. If you would change timezones for all your components to UTC then the times may be wrong. The other thing is that whenever there is recognized an event in different than Evolution user's timezone, Evolution is showing an icon about it on the event. Nonetheless, to answer your question, I didn't find an ECalComponent function for converting times between timezones, though I didn't search heavily, but there is used a libical function icaltimezone_convert_time for it. Hope that helps, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] latest e-d-s git head won't build out of source tree
On Fri, 2010-10-01 at 10:40 -0400, Reid Thompson wrote: rthom...@raker~/evo-git-head/obj/evolution-data-server $ ../../evolution-data-server/autogen.sh /usr/bin/gnome-autogen.sh autopoint: *** Missing configure.in or configure.ac, please cd to your package first. autopoint: *** Stop. rthom...@raker~/evo-git-head/obj/evolution-data-server Hi, might be caused by this commit: http://git.gnome.org/browse/evolution-data-server/commit/?id=5440f849 though I have no idea what it does and what it should do. Thus CC'ing the author. Javier, do you have an idea on this, please? Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] Datastructures for calendar data
On Tue, 2010-10-05 at 10:00 +0200, Hendrik Helwich wrote: I understand this point for recurring events. In the Kolab format it is only allowed to store time data in UTC format (see 1.2.1 in [1]). So we have to think how we can handle this problem in our software. Hi, aha, pity they do not support any timezone, though I understand it's easier for them to understand only UTC and nothing else. Try whether you are able to store your own elements in the XML on the server, and if so, then I would add there a location of the timezone user used for the event, and when parsing back from XML then convert times to that timezone too. If they'll reject your own elements, then it'll be bad and you would have no option to keep user's timezone on component. Also note of e_cal_backend_set_default_zone and e_cal_backend_internal_get_default_timezone; I would extend usage of the default timezone to convert UTC times of events to this timezone, if the user's timezone is not present. Though it'll be better to do some testing whether such extension wouldn't bring more trouble than gain. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] Datastructures for calendar data
On Tue, 2010-10-05 at 10:58 +0200, Hendrik Helwich wrote: But we still have the problem then that the time in some recurring events could be shown different in kontact and evolution in winter or summer time even if both clients are in the same time zone. Err, right, with respect of applications interoperability it's not good to workaround with timezones from a user when the storage allows only UTC, thus yes, forget all I said about timezones and do what the storage allows. :) Bye, Milan P.S.: this one might be useful: icaltimezone_get_utc_timezone() ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memo CALDAV Query
On Tue, 2010-10-05 at 09:04 -0400, Adam Tauno Williams wrote: When Evolution does the calendar-query on a collection for memos (vjournal) objects if specifies a time-range, like: ... C:time-range start=20100831T125831Z end=20101109T125831Z/ ... Is this time range at all adjustable or configurable? I haven't found anything in the UI that seems to pertain to this - perhaps some setting via gconf? Hi, those times are taken from your view on the calendar (or such). First thing the CalDAV does when it's opened is to try to update view for changes in near future and past, to update view for the time user will look for the most. When it's done with it it also tries to update whole calendar, which make take significantly longer. This functionality is not dependent on the event type (calendar/tasks/memo), it should work this way for all of them. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution 2.32.0 and pop3 server error
On Sat, 2010-10-16 at 14:17 +0300, Dmitry Korzhevin wrote: Has anyone come across a bug in Evolution 2.32.0: Storage POP3 does not use a hierarchical folder structure Hi, I'm not sure what you mean with that. POP3 had never use any folders, as far as I know, it has only one, the Inbox, which can be fetched and operated with. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Patch for build failures in gnome-2.32 branch
On Wed, 2010-11-03 at 18:13 -0400, Paul Smith wrote: The current head of the gnome-2.32 git branch in evolution-data-server fails to compile cleanly because necessary -I options are not provided. Hi, thanks, Created commit fda6915 in eds master (2.91.2+) Created commit b0dbfb6 in eds gnome-2-32 (2.32.1+) Not sure if this needs to be applied to the master head as well. The master had it fixed already, in a similar way, but I change it to have this done the same way. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution 2.91 installation error
On Thu, 2010-11-04 at 12:19 +0100, Stefano Facchini wrote: ... Hi, hrm, please try update sources again, with commit 9cc43ef. I'm wondering why I do not see these, because I would like to get them as well. :( Maybe can this depend on the fact that I have an Evolution 2.30 installed from ubuntu repository? As long as you take care of libs and DBus services then it should not be a problem. Note that since 2.32.0 is used GDBus, instead of dbus-glib (in 2.30.x) and the API also changed, thus using factories (e-addressbook-factory/e-calendar-factory) which are not for the same version as Evolution may cause trouble. The thing with DBus service is most likely it and may explain your below P.S.. (Feel free to search evolution-list/evolution-hackers archives for hints how to deal with it.) Bye, Milan P.S. After the failed installation of evolution 2.91 (in /usr/local), evolution 2.30 (from /usr/bin/evolution) is unstable, I get a segmentation fault when trying to create a New Message, for example. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Wed, 2010-11-10 at 11:39 -0500, Matthew Barnes wrote: Here's a few built-in top-level stub sources as trivial examples. They don't do anything other than name a backend. They would appear as bold group names in a source selector widget. 1. Filename/UID: on-this-computer [source] name='On This Computer' backend='local' The built-in system (a.k.a. Personal) source is an interesting corner case because it defines several different groups. (The comments below are just my annotations, they would not appear in the key file.) Filename/UID: system [source]# org.gnome.Evolution.Source name='Personal' parent='on-this-computer' [extensions/address-book] # org.gnome.Evolution.Source.Selectable color='#00' # would not be used in the UI enabled=true# would not be used in the UI [extensions/calendar] # org.gnome.Evolution.Source.Selectable color='#becedd' enabled=true [extensions/task-list] # org.gnome.Evolution.Source.Selectable color='#becedd' enabled=false [extensions/memo-list] # org.gnome.Evolution.Source.Selectable color='#becedd' enabled=false Hi, it's pretty confusing to me. I understand from the above that there are two files, one for groups, which is stored in system directory, and one for real sources, which is stored in user's home. Will be there any kind of property inheritance? As in your example above, I would like to define the 'color' in the [source] key-file-group, thus all extensions will inherit it, but, if user changes color for one of them, then it'll create its own key and it will be used instead of the parent's. Maybe it's not the best example with the color, but imagine the Exchange account, I would like to define server address and credentials, connection setup and such, in the parent, and the children (mail/calendar/...) will inherit this. It seems to me that there is no difference between the file in system and home directory, both are using [source], but each for a different purpose. I do not think it may work well. Imagine the exchange account again. Right now you define an account name, and this name is used as a source group name in Calendar and such, same as in mailer. With that you wrote I do not see a way of achieve that just from the user's home. Or is this based on the existence of the parent/backend key in the [source] key-file-group? In that case the exchange account will have actually two files instead of one in the home directory, one for group definition and one for real sources? It's unnecessary, right? a) you would search for parents, in home and in system directory. b) you should be able to easily distinguish between group definitions and real sources definitions (all are named [source] in your proposal) and be able to _easily_ reconstruct them. Well, it's not straightforward, from my point of view. I would rather name groups [group], avoid confusion, and be able to define all this in one file, thus for usual user they will be able to distribute only one file with predefined account settings instead of many. Of course, the groups should either have the 'uid' defined in the file, or it should inherit uid from the file name itself. Filename: excha...@my-company [group] name='excha...@my-company' backend='exchange' server='my-company' username='me' [source] color='#FEFEEF' parent='excha...@my-company' [extensions/mail] enabled=true [extensions/addressbook] fragment='personal/Contacts' name='Contacts' [extensions/addressbook] fragment='personal/second-contacts' name='second-contacts' [extensions/calendar] fragment='personal/Calendar' name='Calendar' last-notified='2010-10-10T10:10:10' [extensions/calendar] fragment='personal/second-calendar' name='Second Calendar' color='#80FF80' ... Well, you cannot have two groups with the same name in the key file, thus you really meant to have one file per each ESource/EAccount + one file for the group definition, all these put into one folder in the home (+ system group definitions in system folder)? I do not like the idea much, but I agree it can work. Also, remember that users can name their accounts whatever they want, but not every latter is usable for the filename - so the files will be either meaningless strings or something descriptive? The last two questions (and I see I mostly answered above questions myself), how will be the group definition propagated to mailer, respectively how will be defined the POP account, which doesn't have a group in the folder tree, same as the mbox, which is hacked in and hidden in the background? Will these two kinds also require its own group file (for the 'backend' key) or not? Because you have [source] for groups and [source] for pseudo-sources (the real source is at the [extension/...]), then will I be able to define a child of the source, not of the group, and it'll be propagated to the UI? Just an
Re: [Evolution-hackers] Rethinking account management
Hi, On Mon, 2010-11-15 at 11:45 -0500, Matthew Barnes wrote: I was a bit horrified to realize over the weekend the way we select a backend from the factory processes when requesting a new EBook or ECal. We convert an ESource object to XML and transmit the -entire- XML string over D-Bus, only to have the factory process reconstruct the ESource object from the XML string, extract the URI string from the ESource object, and extract the scheme from the URI. The scheme is used as a hash table key for registered backends. Well, it's not complete, the reconstructed ESource is passed into e_data_book_new, so the backend can access it and knows where to connect. With the new APIs, apart from GConf migration we won't be constructing ESources from XML anymore. So here's how it's gonna work: getCal() and getBook() will just take the ESource's UID string, the factory process will look up the corresponding ESource object from its own registry and call e_source_get_backend() to get the hash table key. Done. That's kinda limiting, isn't it? As you allow only saved sources to be opened, though for example all test suits are not saving their sources, but just construct them on the fly and pass them to the factory. ... If there's no objections I'd like to get new interface names into 2.91 now so I can increment the interface versions on my account-management branch and not have to worry about this anymore. Sounds fine to me. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Use real version in /apps/evolution/last_version
On Thu, 2010-12-02 at 07:43 -0600, Matthew Barnes wrote: Seems fine to me, as long as we continue to target the last stable version as the source to migrate from. Does it mean that the migration routines should be clever enough to know whether they were running already, though the version will indicate they didn't? I would use the last version in the migration code check, and if any fix in the migration routine would be done after another release, then just increase the number in the version check. It might work as long as the changes will be done non-destructively. On the other hand, if you think the little breakage is acceptable in development releases, then this might not worth the trouble. Maybe. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Thu, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote: As usual this is turning out to be a bigger job than expected, and I'm less confident now that I can get this all done by 2.91.90 but I'm still gonna try. The alternative, since I -really- don't want these XML blobs creeping into GSettings even temporarily, is to depend on GConf for 3.0 and then land this stuff (along with Rodrigo's GSettings branch) early in 3.1. Were it not for the pressure to get everything converted in time for GNOME 3.0, I would already be retargeting this for 3.1. Hi, sounds reasonable, this seems to be quite intrusive change, not only for evo itself, but for everyone using it, so landing in time of .90 might be rather bad. Apart of that we have enough such changes in sources already, counting also gtk3, so I'm 111% for postponing to early 3.1. libedataserverui - All e-passwords functions will simply take an ESource instead of component and key strings. Keyring entries will contain the UID of the corresponding ESource instead of URI components (we'll convert existing keyring entries as part of the migration phase). It would be good to allow also username changing in EPasswords. It's very unusual to allow only password entering when most applications are allowing to change both username and password (I'm not aware of any other with enter password only functionality at the moment). It seems to be related, a bit, thus I'm bringing it here. Also note one thing which might require a bit rewriting. If I recall correctly you would use the ESource's UID for password storing. The thing is that evolution allows setting auth-method, which is used as 'component'. The advantage of this is that the ESource for calendar can share password from mailer (while not knowing the parent source/account at all), because they are using same 'component' and 'key'. So with your change in the passwords there should be a knowledge to which account is this ESource tight (which is not always clear right now?), and this parent account should be used instead of the actual ESource, right? I do not want to complicate things much here, though with the change also user name proposal above it might mean that one wouldn't use different name for calendar and a different name for mailer with this? I think we are not using any such approach here anyway, so I'm only brainstorming here. Bye, Milan P.S.: If you'll be changing API, please change also EIterator API, to not return 'const' pointers from e_iterator_get. We use to forget to change this release by release :) ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Handling Aliases, Silent Mode, Combo Tasks
On Fri, 2010-12-10 at 09:06 +0100, twohot wrote: I'm not sure if this should fall into the hacking section or general section ... Hi, as this is not about developer thing, then I would rather use evolution-list, because you are asking as a user. Nonetheless, see below. 1. Once an account is set up it becomes difficult to implement an alias sending. Evolution doesn't allow its user change the sender's field when composing ... except for accounts created locally. For people involved in open-source projects like Evolution this makes it hard to use evolution to send list related mails. Why? Some users have email aliases tied to their email accounts ... and use the aliases for such projects. Is there no way one could override the sender's field so users can enter their email aliases instead? No way at the moment, there is a bug filled in https://bugzilla.gnome.org for identities or something like that. Evo's way for this is to create an account for each alias and set only sending part there (the receiving will hae None). Then you would be able to choose respective addresses when sending a message. 2. It would be nice if evolution can start silently ... docked in the panel and runs on the background. No way, no need, will never be part of evolution itself. I'm sorry. Also see http://live.gnome.org/Evolution/FAQ 3. I see Combo Tasks (or whatever) as a Task that has other tasks inside it -- like a project with small objectives. Yes, sounds like a feature request. I thought it would be enough to group your tasks based on a category (View-Define view and create a new one there, and assign categories to your tasks), but it might not work as you wish, with a relationship to the parent task. Please search the bugzilla, and if not found there already filled, then feel free to file a feature request there. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Mon, 2010-12-20 at 14:17 -0500, Matthew Barnes wrote: Since removing an address book or calendar source will be as simple as deleting its key file, in theory the backend process should be notified of the file deletion event by its ESourceRegistry and can then clean up after itself on its own without being told to by the client. Hi, I like your idea. It might work as long as the backend is running, otherwise it will not, unless you'll add a listener for this in factory and run the backend if needed. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Install E-D-S backends into separate directories?
On Tue, 2011-01-04 at 15:00 -0500, Matthew Barnes wrote: That means e-addressbook-factory is loading calendar backend modules and e-calendar-factory is loading address book backend modules. Until now that hasn't been a problem: the foreign backend classes are registered but remain dormant. Hi, are you sure they are kept in memory? I see the factory calls e_data_server_get_extensions_for_type() then frees this list with e_data_server_extension_list_free() and finally calls e_data_server_module_remove_unused() which may do the things you are trying to achieve by extension folder separation, right? I do not think it worth the change, the overhead on a factory load may not be so large. Though see below. On my account management branch I've started registering other GTypes in eds_module_initialize() functions. For example, the LDAP backend now registers both a backend factory class and an ESourceLDAP class which holds all the LDAP account details and configuration options. Do you mean you are returning from the backend module, apart of EBackend types, also different types in the eds_module_list_types() call? I always thought this function is mean to return only list of descendants of EBackend. There is no need to have a separate module for calendar and book at the moment, it is only done this way. Separate folders may mean forcing this two-module model. On the other hand, if you share some parts between both, where I hope you do with Exchange, where both calendar and book backends are using same ESourceBackend type (or how you call it), then having one module may be a benefit. The cleanest and most obvious solution is to install the backends into separate address book and calendar directories, then have each factory process load from the appropriate directory. I suppose the other approach is to have some kind of hierarchical type tree in e-data-server-module.c, having separated descendants of EBackend and the rest returned from eds_module_list_types() and unload those other types only if every EBackend types from that module are unused. Is it more dirty way than overloading eds_module_list_types()? By the way, why cannot be ESourceBackend type registered only on the backend class creation? It's a similar way as Camel's provider does it, isn't it? Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Install E-D-S backends into separate directories?
On Wed, 2011-01-05 at 08:25 -0500, Matthew Barnes wrote: Both the backend factory class and the ESource extension types have to be registered with g_type_module_register_type(), and the GTypeModule isn't available from the class init function. Here's the workaround I'm currently having to add to almost every backend. The lengthy comment explains a bit more technical detail. Ah, I see, quite complicated. The g_type_module_register_type() says: As long as any instances of the type exist, the type plugin will not be unloaded. Whatever that means. Though if it means what I would expect from it, then registering unconditionally all types in eds_module_initialize() and dereferencing those special types in eds_module_shutdown() may cause unload of the module. Nonetheless this is just a theory, and I believe the usage of this showed you that it doesn't behave this way, thus you've a green from my side, even I would prefer less intrusive change for providers of calendar/book backends. Does the proposed change (in ESourceGroup/ESource) also mean that each backend should provide its own ESourceExtension when it'll need to set some custom attributes on an ESourceGroup/ESource? I hope not. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Install E-D-S backends into separate directories?
On Wed, 2011-01-05 at 12:13 -0500, Matthew Barnes wrote: Yes, but I'll write them. They're nothing more than a bunch of GObject properties with simple get/set functions. The marshalling of those values to and from key files is all handled transparently by ESource. Writing those classes is monkey work, as you like to call it. :) Nobody likes monkey-work, neither code duplication, and as we are talking about each backend for addressbook and calendar, then one can imagine what that might mean. For example, will you write these for evolution-couchdb, evolution-kolab and possibly many other 3rd party providers, apart to all of included in eds itself? You may understand why I dislike the idea. I thought, from one of your first mails about this, that this code duplication will be unnecessary, that the basic ESource will have a way, different from the GObject properties, to get/set any property from the ESource hierarchy. And what I thought was that it'll not be done through GObject, but through its own API. What I'm trying to tell is that the approach of GObject properties is more limiting and adds more monkey work than an approach with special get/set API on ESource itself. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Account management and keyrings
On Thu, 2011-01-20 at 11:07 -0500, Matthew Barnes wrote: With this in place, the only thing left for e-passwords.c to do is put up a password dialog. Although knowing me I'll likely wind up rewriting that too. Hi, I think I mentioned it somewhere already, please add also possibility to change/enter username to the dialog (and possibly also domain name, though this one can be encoded into username too). Any strong objections to scrapping e-passwords.c for 3.2? Nope, go for it. It may also fix an issue with BirthdayAnniversaries calendar, when using authenticated addressbook, as right now there is no easy way to ask for a stored password for that book. Of course, there will be needed new API for book/cal backends to be able to ask for any password (on any ESource), not only during its authenticate signals. Even it's another story, please consider these things too. Thanks and bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Hierarchical Tasks [Was: Multiple child-addressbooks under an account]
On Sun, 2011-01-23 at 16:51 -0500, Adam Tauno Williams wrote: You'll also run into consistency issues when using GroupDAV/CalDAV/CardDAV and the server tries to be 'helpful' or smart. For example if on a CalDAV server I have a todo list of many tasks and three of those tasks are linked in some way - the client makes a modification to one of those tasks which has a side-effect on the status of the two other tasks the client will remain merrily oblivious to that fact that the other objects in the collection have changed. This is just a crappy part of the specs, there isn't any widely supported mechanism for the server to notify the client that certain references in its cache have been invalidated. The only way the client figures that out is if it polls the collection; which can be slow and/or computationally expensive. Polling the entire collection after every update would just be brutal - but it is the only way to remain consistent. ... Hi, there could be done, as the first step, a hierarchical view of components based on the Andrew's property, and it can do nothing, as a starter, with respect of implicit impact on related components, keeping all this on a user (call it a very simple target calendar system). So Evolution would use it only for viewing. Because the RFC doesn't dictate whether client or server should do implicit impact changes, then the rest can be safely done on the Evolution side (which avoids update issues you mentioned) by some kind of plugin, rather than making evolution's UI too complex. Of course, it might not work with every server, but this kind of issue is there every time. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rebasing gtk3 branches
On Sat, 2011-01-22 at 14:01 -0500, Matthew Barnes wrote: Would anyone mind if I do another round of gtk3 rebases? Hi, what about wait till Wednesday, after evolution team meeting, and then merge gtk3 branches to master branches, and require gtk3 for the Monday 2.91.6 release? It saves a bit of work for you, and also forces people to fix new issues related to gtk3, both during Thursday and Friday, and also benefit from more testers with 2.91.6 release. This might be doable, especially because: ... and it's quite usable. A few minor glitches left but canvas widgets now draw and scroll correctly, and I'm seeing a few but not an enormous number of runtime warnings on the terminal. which can be fixed till the meeting. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Tue, 2011-01-25 at 16:54 -0500, Matthew Barnes wrote: The new names are (with both versions at '0'): Bus Name:org.gnome.evolution.dataserver.AddressBook0 Object Path: org/gnome/evolution/dataserver/AddressBookFactory Interface: org.gnome.evolution.dataserver.AddressbookFactory Bus Name:org.gnome.evolution.dataserver.Calendar0 Object Path: org/gnome/evolution/dataserver/CalendarFactory Interface: org.gnome.evolution.dataserver.CalendarFactory Hi, thanks for doing this. I'm only wondering, why not a dot or dash (if available for bus names) between the version number and the bus name itself? Was there anything preventing it to do it that way? (I'm not much familiar with DBus itself, so please forgive me if this is a lame question.) Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Gtk-ERROR **: GTK+ 3 symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported
On Thu, 2011-02-03 at 12:43 -0500, Reid Thompson wrote:
Is there a way to determine where I'm mixing GTK 2 3?
Hi,
try with this:
$ for i in `ldd $PREFIX/bin/evolution | awk '{print $3}'` ; do \
if [[ `ldd $i | grep gtk` ]] ; then \
echo -e $i \n `ldd $i | grep gtk` \n ; \
fi ; done
Bye,
Milan
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Local calendars with custom files
On Mon, 2011-02-07 at 09:46 -0500, Matthew Barnes wrote: On Mon, 2011-02-07 at 09:50 +0100, Milan Crha wrote: And that's what is wrong with it. I do not know the polling interval, chosen by gio developers, but I prefer to be able to set the polling time myself, for fine-tuning. Not talking about unnecessary network traffic for those (rather rare?) cases. What network traffic? Evolution only lets you choose a file on the local file system. I thought of something like /mnt/samba/... All three options are used for different purposes and use cases, to be able to configure one writer and multiple readers, for example, because there is done no file-locking and such. I'm not suggesting dropping the force read-only option. Users of these custom files expect the calendar data as shown through Evolution to be kept up-to-date with the file contents and my guess is they don't care how. They should never be looking at stale data. A file monitor is clearly the best mechanism for knowing when to refresh a local calendar, and if the file never changes then the only resource lost in monitoring the file is one file descriptor. Big deal. I see no need to burden the user with this choice. Maybe. I let it up to you. I thought those options might be useful when I was implementing those bits into evolution. If you think it's overcomplicated, then feel free to drop it and use the best default, which is surely the file monitoring. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GroupWise mail issue (Was: (no subject))
On Tue, 2011-02-15 at 23:16 -0700, Sankar P wrote: Your last few mails are displayed as I have attached below in a non-open mail client that I use (GroupWise). Hi, I guess it's the X-Face header doing trouble for GroupWise. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution requesting info on every year from 2011 down to 65535
On Thu, 2011-02-17 at 00:48 +0100, Carlos Martín Nieto wrote: I've attached the backtrace for a year of 167 (I think) though I don't think it gives much information. This happens even if I have my main calendar off (which I think it's the only one with recurring events). Hi, this is from your CalDAV calendar, based on the backtrace. Try to get the component which is causing this trouble, and see whether there is something wrong either with that component or with evolution. You can achieve that if you breakpoint as you did earlier, then move to frame of e_cal_backend_sexp_match_comp function and invoke gdb command: (gdb) printf %s\n, e_cal_component_get_as_string (comp) then strip any private information (the best by replacing with 'x' or similar letter) and maybe share it here, if you think it's correct, or better file a bug report and post here a link to it. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Sqlite cache for address-book storage in EDS
On Thu, 2011-03-10 at 12:09 +0530, Chenthill Palanisamy wrote: file, groupwise, exchange uses EBookBackendDBCache. Hi, do not forget that the DB cache is compiled conditionally, because some distros do not ship libdb. Using SQLite for this was mentioned months ago, only no-one got time to actually do it, so go for it. Only think of two things: - using binary storage for this kind of data is bad for cases where the binary file breaks, either due to an update/downgrade of the library providing access to it, or just by a crash. It's not so hot with camel as SQLite has there only summary data, but if you want to store also real data in it, then it can be a problem. There are people having issues recovering their data from addressbook storage already, but if you are going to do any change on it, then it would be good to think of that from the beginning. It would be good to store raw vCards in some plain text file(s) which will be indexed by SQLite summary. This plain text file(s) will be then easy to import to evolution if something goes wrong, and with erasing SQLite file user will not loose any valuable data. (I'm thinking of a flat maildir approach here.) - be able to store custom values in the summary - backends can have a need to make its own notes in the summary, so make it possible for it. As these might not be so critical as contact information itself, then it should be fine to store to summary only. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Handy GObject debugging trick
On Thu, 2011-03-10 at 13:42 +, David Woodhouse wrote: Are we not *ever* closing a folder, after the UI has visited it once? Hi, CamelStore keeps list of opened folders in its bag-container, and because there are caches of CamelStore-s which are not freed properly, then neither folders are freed as ought to be. Did you ever notice a flash in the folder tree when you change something in the account preferences, but those changes were not propagated till next start? I believe it's a side-effect of such CamelStore caches issue in evo itself. No wonder Evolution tends to grow until it's eating all the memory in my system... :) Well, it depends. There were some bugs fixed already (in 2.91.91), but many are still there which no-one is aware of, I'm sure of that. Two most significant I recall right now: a) any attachments shown in the message preview were never freed, together with its content - so with large attachments memory usage could grow pretty quickly b) the templates plugin used to leak folder infos when building menu options for itself. It's not much leaking in a byte-size, but as the menu is regenerated on each click/move/change in the message list, then this can grow in time also quite quickly. Thinking of Matt's change, I wrote something similar recently too, not that sophisticated, and it did slightly different things too, but it did what I wanted from it as well. Mine change was for pointer tracking. Simple routines to track and untrack concrete pointer (usually track a pointer in its init method and untrack it in its finalize method), and list left pointers when exiting the application. I thought I'll add it to Camel, but then I realized it's not about Camel only, so it could come to e-data-server-util.h/.c, but then I couldn't decide, so I simply dropped it. Maybe it would be useful for debugging purposes too. It was for me. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Headers
On Wed, 2011-03-09 at 14:58 -0500, Richard Bromwich wrote: I really think Evolution is great mail program but its lacking a very important feature for someone who travels. The ability to just download message headers, and then being able to download only the messages you want to read at the moment and leave the rest on the server or delete the junk without downloading. Hope to see this feature before too long. Thanks Richard Hi, well, this is rather question for an evolution-list, than to hackers, but anyway, what is your protocol you are using? I hope it's IMAP. Note that you can setup evolution to download headers only, and the message is downloaded only when you open it, like in the preview below the message list. In other words, I believe your above statement is wrong, at least for IMAP servers. I now have to use thunderbird when I travel Part of freedom you have :) Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Front-end header files for E-D-S libraries
On Tue, 2011-03-22 at 14:35 -0400, Matthew Barnes wrote: For 3.1, I would like to provide a top-level header file for each of the libraries in E-D-S and deprecate including individual header files. The benefits should be clear by now: more flexibility to change or rearrange header files without breaking the public API. Hi, I never got why one wants this, I recall some Java guidelines which encourage the opposite, never include whole unit, but only pieces you actually use. It made more sense to me, to not get in things you never use (quicker parsing/compilation too, probably, to not openparse spare header files). Also, one does not rearrange code so often, I believe. Anyway, if you really think this change (which actually affects anyone using eds client API) worth the effort, then feel free to do it. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Tue, 2011-03-29 at 09:26 -0400, Matthew Barnes wrote: The hierarchy just ensures that deleting the mail account from the ESource registry will also take out the default identity and transport for that account. Hi, should it delete them too? I've a feeling there is no need for it, especially when you want to have them as three separate independent objects. But that's just a feeling. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Backend requesting arbitrary user input from frontend
On Wed, 2011-03-23 at 19:04 +0100, Christian Hilberg wrote: Of course, this is going to be fun - how to tell which of the possibly multiple EDS-frontends should receive the request? Ideally, the backends should be unaware of EDS-frontends... trouble galore! :) Hi, Matt suggested in his Account management that the server will ask for credentials with an information for which source this request is made, so the auth_required signal may contain this information. I'll add a strv parameter to that, just for being ready even for more expansion. What kind of information will be known in this parameter depends on the receiver for the signal. Let's have it opened for now, but I believe this may cover your issue too. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Maintenance fork for Evolution / EDS 2.32
On Fri, 2011-04-01 at 20:07 +0100, David Woodhouse wrote: That's great; thanks. I'll do a little more testing on the patches I've cherry-picked into my trees, and then unless someone else has objected in the meantime I'll push them. Hi, I objected against this many times, directly to you, on IRC, with no effect, obviously. If I recall correctly, the reason why release-team decreased releases is that distributions were *not* using .2 release. Which is just the opposite you are trying to convince us. If they are not using official releases, why should they use unofficial branch? By the way, how would you look for a fix user reported to your distribution, as a distribution maintainer? The work-flow, as I understand it, is like this: a) user enters a bug report in your distro bugzilla b) maintainer gathers enough information to identify the issue c) check upstream bugzilla for a duplicate or possible fix d) decide on the change whether backport or indicate will be fixed in the next stable/unstable release Note that I do not expect anyone looking into git branch for a particular fix, with a very good reason, they would rather check in bugzilla, which offers much better searching ability and contains enough information for possible bug matching, with compare of git commit. And the bugzilla should have enough information about the fix, like either a patch or a link to particular commit. The evolution-related products use to it that way. That's my opinion. Bye, Milan P.S.: as of today (or tomorrow, if you wish), the official stable release is 3.0.0. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Calendar PIM objects with inlined attachments
On Fri, 2011-04-08 at 10:04 +0200, Christian Hilberg wrote: We could use Evolution's file-link attachment mechanism by writing into Evos file cache from the backend and placing the file paths into the ECalComponent when reading calendar objects from the Kolab server, and read attachment file data from this same cache when creating a new object with attached files. We found a whole lot of issues with this approach (at least for Evo2.30), which I can detail if anyone is interested. Hi, CalDAV calendar plugin uses this approach, and it seems to work. It's surely better than passing rather-long attachments over the wire (D-Bus) in both ways. Check the CalDAV sources how it's done there, maybe you would be able to mimic that approach. Hope that helps, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Calendar PIM objects with inlined attachments
On Fri, 2011-04-08 at 15:06 +0200, Christian Hilberg wrote: There's no e_cal_backend_get_cache_dir() in Evo2.30 (which is the one we're sitting on presently). That means we cannot maintain a backend-private file cache with this version, since we cannot inform Evo about it ... is that correct? Hi, basically correct, unfortunately: http://git.gnome.org/browse/evolution-data-server/tree/calendar/libecal/e-cal.c?h=gnome-2-30#n725 Though you might be able to set full URI in the attachment object and evo should be able to read it, but not write, probably. Maybe the UI will create a store for you when creating a new event with attached files. To be honest, I do not recall details, it's too long time ago with 2.30.x for me. I would suggest you to try and see. With respect of fetch on demand, it'll be tricky to achieve, to make this done right on each operation which deals with the calendar component in a certain way (operations like copy, move, send and so on). But there is some API function, probably meant for something like that, already, the e_cal_backend_get_attachment_list, used by e_cal_get_attachments_for_comp. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Fedora builds with 2.32.2+ patches
On Mon, 2011-04-11 at 10:54 +0200, Patrick Ohly wrote: Listing sources shows local:/system instead of local:system and opening local:system also still fails. Milan pointed to the history of e-source.c, but I don't see which (other?) commits are needed to fix these issues. Hi, try these commits from eds: 1443076ae96133f7046f7ea96cb39352f0ca4508 fc9462d477b098b8f15db5cde3952db6d92e2868 and probably this from evo: 8e33ff0fbb5908d06c9f32f58f35eca694b3f50c I didn't check if they had any followup commits done by others, I only chose commits I did in this area, though I've a feeling there might be some followups. Hope that helps, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Finding memory leaks in EWS with Valgrind
On Tue, 2011-04-12 at 11:13 +0100, David Woodhouse wrote: I started testing under Valgrind and fixed a bunch of memory leaks... and now someone has introduced some more :) Note that you have to use 'GSLICE=always-malloc' when testing for memory leaks, because otherwise the glib internal pool allocator will confuse valgrind. Hi, I'm just wondering, how does this mail belong to evolution-hackers list, please? I do not see anything general evolution-related in it, maybe apart of the above paragraph, but that's usually known to people whom are coping with valgrind on daily basis. Was this mail meant to punish certain people in public? Really? I certainly do not see the point of this mail, I'm sorry. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Pre-alpha test builds of Evolution-EWS for Fedora / MeeGo
On Sun, 2011-04-17 at 09:16 +0100, David Woodhouse wrote: Since the early QA has also shown up a bunch of evo/eds bugs Hi, were any of them still present in master/3.0? If so, which bugs is this about, please? Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Pre-alpha test builds of Evolution-EWS for Fedora / MeeGo
On Mon, 2011-04-18 at 10:36 +0100, David Woodhouse wrote: I'm trying to operate a 'trickle down' policy, where I only commit fixes to gnome-2-32 if they are already in master *and* gnome-3-0. That way, things don't get lost — and we don't end up in the odd situation where a bug is fixed in 2.32 but not 3.0. Hi, thanks for the answer. The above was my unspoken interest behind the question. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] New 'eclient' branch in eds
Hi, I just created a new branch 'eclient' in eds [1] where is added my work on the new API which will deprecate EBook/ECal. It is following glib/gio async pattern and, I believe, makes things more coherent. This change, apart of other things, influences also backends, as I added GCancellable to each virtual function which deserved it, made ECalBackend authentication process similar to that used on EBookBackend-s (with authenticate_user function), and I dropped unused and/or unnecessary virtual functions from backends as well (mostly from ECalBackend). The GDBus interface functions were also completely rewritten, for better readability, I believe (and hope). Please have a look and comment here, before I'll commit this to git master, which I would like to do before the first 3.1 release of eds, thus all other descendants of backends will have enough time to change their code appropriately. The next step, after such commit, will be to slowly adapt evolution itself, with which I would prefer to wait till Matt's account management changes will land, definitely on places which are interleaving, because I would like to avoid most of the pain when merging changes, unless we'll make other deal on this. Bye, Milan [1] http://git.gnome.org/browse/evolution-data-server/log/?h=eclient ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Mon, 2011-04-18 at 15:36 +0100, Philip Withnall wrote: I haven't had a chance to look at it all in detail, but two things strike me from a quick glance: • If we're following the GIO async pattern, why do the e_data_book_respond_*() functions still exist? Hi, the server part (e-data*) didn't change much, not with respect of API changes, apart of dropping outdated functions. The part which changed was the client side. The 'respond' functions are there to tell the client, from the server, that the certain operation was finished. What I forgot to mention in the previous mail is that the asynchronous server operation have been divided into two parts, the first is to start the operation by calling particular function on the client side, and then notifying the client from the server that this operation was finished. It's done by a done signal for the particular operation. It avoids timeouts on DBus, as long as the main thread isn't stuck, because when an operation is started, then the first thing the EDataBook/Cal does is a response to the client with an operation ID, (this ID can be used to cancel this particular operation). Only after that is the function run and is considered running until backend finishes it by the 'respond' function. The only disadvantage I faced with this approach is that the _sync client calls are supposed to run their own mainloop, to behave like blocking, but still being able to receive the done notification, when invoked from the main thread. • Please, please, please add some documentation to the new EDataBook. Trying to understand how the old one was supposed to function was a nightmare, and I would hope that the same mistake isn't repeated with the shiny new version. Yeah, can be added any time later, though you may use EBookBackend documentation, rather than a wrapper around dbus and factory, for which the EDataBook is. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Mon, 2011-04-18 at 12:48 -0400, Matthew Barnes wrote: * There's some overlap between the new EClient API and the new ESource API that I'm working on. Some functions will need to be dropped once the new ESource API is in place, so I don't know if you want to do this now or wait. ... Hi, I do not think dropping all of them is any of gain, just the opposite. Why to write same code, even 4-lined, all around instead of call one simple function? Notice that all these functions are hiding where the sources' configuration is stored. (4-lined is because you may get somewhere the registry pointer and free it afterwards, instead of your simplified 2-lined sample). There are also simplified functions for freeing GSList-s and their content, which is mostly two-lined code too. * We should use GIO error codes whenever possible, and I see quite a bit of overlap here. I think following error codes should be dropped: Well, from my point of view, the error also tells you the place of origin, and the origin for these is not a GIO at all. E_CAL_CLIENT_ERROR_SUCCESS E_BOOK_CLIENT_ERROR_SUCCESS There's no need for an error code for successful operations. Ah, right, since returning GError instead of error status/code only it doesn't make sense to be there anymore. ... E_CAL_CLIENT_ERROR_INVALID_SERVER_VERSION E_BOOK_CLIENT_ERROR_INVALID_SERVER_VERSION I don't think these are necessary anymore since we started using versioned bus names for the addressbook and calendar services. If there's a client/server version mismatch, the client will get a D-Bus error about it. It's used by Groupwise exclusively. * Of the remaining error codes, a number of them in ECalClient and EBookClient can be combined and moved to EClient. Especially ones related to offline and authentication, since that's what EClient handles. Good idea, I didn't think of it in this way, also because the codes are different when passed through D-Bus, but it can be done on the client side for sure. * I would really prefer we use GList instead of GSList throughout the API. GSList is silly and really should never have been added to GLib, in my opinion. Most modern GNOME APIs that I've seen prefer GList, and it's a pain in the butt having to convert between the two. Yeah, my other goal was to harmonize internal API to consistently use one of these types, and I chose GSList, because it's simpler and smaller than GList, and because the usual case is to traverse the list in one direction and not both, thus the GSList is sufficient. If there will be more voices for this, then I can make it GList. * I thought backends could send their own custom error messages now, so are e_cal_client_error_to_string() and e_book_client_error_to_string() still necessary? Hmm, maybe it isn't. Consider it as debugging function :) * In EBookClient, drop the 'const' qualifier from EContact arguments. Trying to use 'const' with GObjects is misguided and pointless. I've cursed at EIterator many times for this. Yet another thing I wanted to address was a clear memory management recongnizable from function prototype. Thus if the function doesn't change object's/variable's content, then I made it 'const' to indicate it's used for reading only. Of course, inconsistencies all around the code in this makes it hard to do right, so the function type-casts it back to non-const pointer internally, because EContact API is not written in that way. (Though it's not only about EContact.) * Why do we have get_capabilities functions in EClient, ECalClient and EBookClient? Are they different sets of capabilities? And if getting capabilities involves a D-Bus call then doesn't it need to be async everywhere? They are same capabilities. Same as ECal/EBook the EClient caches capabilities once it's asked for them, and reuses them, same as is responsible for its memory. The cached values are also used for capability checking. These are fetched on demand, and are always synchronous. For cases where this is unusable, and where the caller will take care of the memory, I added also get_capabilities functions to ECalClient/EBookClient, which has both sync and async versions. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Tue, 2011-04-19 at 09:27 -0400, Matthew Barnes wrote:
Havoc Pennington kept having to answer this same type of thing in the
early days of GLib/GTK+ when people would ask why the API never uses
const in functions that take but don't modify a GObject and GLib data
structure.
http://mail.gnome.org/archives/gtk-devel-list/2001-May/msg00485.html
The take away there for me has always been const is useless for any
kind of struct that has a pointer member, which virtually all GObjects
do. The API docs are a better place to document that the argument is
not modified. Don't try to do it in the function prototype.
I'm not sure if it's an apologize for it, but making it /* const */ may
not hurt.
* Why do we have get_capabilities functions in EClient, ECalClient and
EBookClient? Are they different sets of capabilities? And if getting
capabilities involves a D-Bus call then doesn't it need to be async
everywhere?
They are same capabilities. Same as ECal/EBook the EClient caches
capabilities once it's asked for them, and reuses them, same as is
responsible for its memory. The cached values are also used for
capability checking. These are fetched on demand, and are always
synchronous. For cases where this is unusable, and where the caller will
take care of the memory, I added also get_capabilities functions to
ECalClient/EBookClient, which has both sync and async versions.
Hmm, so you're saying I first have to fetch the capabilities via the
async calls in ECalClient and EBookClient, then the result is cached in
EClient? I'd suggest renaming the EClient function then to something
like e_client_get_cached_capabilities().
No, not at all, EClient calls descendant's get_capabilities_sync on its
own, when it's needed. The public get_capabilities API on descendants is
sort of redundant in this case.
There's a couple other simple things I forgot to mention yesterday.
* We should add some padding to all the public class structs so we can
add new class methods in the future without breaking ABI. Something
like this:
struct _ECalClientClass {
... methods and stuff ...
gpointer reserved[16];
};
I never understood a need for this, neither used it when changing
structs. There was done a soname version bump when changing public
class structures, which, from my point of view, always involves also
API changes, and freezes on these both are tight together. If you add a
new member to the struct and not change the reserved array size (by
how many, by the way), then you end up with a crash/critical warning
about different structure size anyway. Doing change-and-try loops here
sounds rather silly, from my point of view.
* Also, GLib 2.26 gained its own timezone API: GTimezone.
http://developer.gnome.org/glib/unstable/glib-GTimeZone.html
It would be good to eventually try and correlate GTimezone and
icaltimezone. Other projects will be using GTimezone now since
it's part of the GNOME platform libraries, and will likely expect
to be able to use GTimezone with E-D-S libraries.
I'd like to add least make room for this in the name space now by
renaming all functions that expose libicaltimezone pointers from
timezone to icaltimezone.
As icaltimezone is the main timezone for calendar in
evolution-data-server, and will be as long as libical will be used
there, then what about having e_cal_client_set_default_gtimezone as a
possible alternative for e_cal_client_set_default_timezone? On the other
hand, wouldn't e-cal-time-util.h/.c fit better here?
Milan
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Tue, 2011-04-19 at 19:39 +0530, Chenthill Palanisamy wrote: I would like you to a incorporate some change to the free/busy api. Some servers allow querying free/busy information for multiple users at a time and the results appear in a iterative fashion. The freebusy information of some users are delivered first, while the server keeps fetching other user's free/busy information. So if we could have he FreeBusy api such as this, we could leverage those features, ECalClientFreeBusy e_cal_client_get_freebusy_object_sync (ECalClient *client, time_t start, time_t end, const GSList *users, GCancellable *cancellable, GError **error); (with a async counter-part) Signal: freebusy_received (ECalClientFreeBusy *fbobject, const gchar *user, GSList *ecalcomps) The clients could watch for the signal and update the freebusy information as and when they receive from eds. Hi, one more function would be needed, to tell backend from the client that it may stop delivering free/busy information and/or focus on a new query. Otherwise you may get responses really any time, which is not what you actually want. It all seems to me like an ECalView for free/busy, rather than anything doable on the backend client itself. Remember the factory shares backends between data-book/cal-s. With views, all known are notified about changes on objects (if they belong to the view), thus even as a view this will not be that easy on the server side to do, with some hard management of who (EDataCal) is looking for what (different users, time interval...). Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Tue, 2011-04-19 at 10:40 -0400, Matthew Barnes wrote: 1) There's no need for apps to use numeric IDs to track asynchronous operations; GCancellable fills that role. GCancellable is the app's handle to the ongoing operation. If the app wants to cancel an unfinished operation, it calls g_cancellable_cancel(). The following functions should be dropped from the public API: e_client_cancel_op() e_client_register_op() e_client_unregister_op() All functions that kick off an asynchronous operation should return void. If you need to use numeric IDs to track D-Bus operations, do so internally. Create an e-client-private.h if you need to. Don't expose it in the public API. I was afraid of an overuse of the GCancellable, as it is used for the DBus communication and then for the whole operation lifetime too. But you've right, both ways are probably not needed. 2) ECredentials is way too complex. My intent for ECredentials was to have a self-contained authentication handling interface to avoid all the current nonsense with ECal and EBook where you have to always remember to connect to authentication signals and then implement the keyring lookup and user password prompting yourself. ... The benefit here is that apps can simply pass some pre-packaged ECredentials implementation when creating calendar or address book connections and not have to worry about handling authentication beyond that. The ECredentials API you came up with would be one possible implementation of the raw ECredentials interface illustrated above. It should live in libedataserverui or maybe just in Evolution so it can run a password dialog or whatever other GTK-related things it may need to do. Please see libedataserverui/e-client-authenticate.*. It does that. The ECredentials is also used in authenticate_user backend implementations, allowing ask for any backend (as you cannot ask for a password for an address book from a contact calendar backend right now), and one is also able to ask for a PIN, as was asked for by the kolab developers. I covered your requirements and (at least) those two above in a simpler way, at least for me. 3) The new functions for EClient classes should be asynchronous, and ... I'd really like for establishing a D-Bus connection to the backend, connecting to a remote server, and authenticating via ECredentials to be *one* step for the app. It either all works and you get back a fully connected and authenticated EClient object, or something fails and you get back NULL with a GError set. I want to avoid these weird in-between states where you're holding a client object but you haven't connected to the backend yet, or you failed to authenticate with the remoter server, etc. It just makes life difficult and confusing for apps trying to figure what they're supposed to do in these cases. ... Hmm, I think I understand, but I do not see clearly the point. Sometimes you do not know if the server requires the authentication, only after open, which will deliver (on idle) the auth-required signal, which can come before the backend notified open-done, or after, it depends. What about offline mode? What about offline server which requires authentication when evolution is online? (The CalDAV calendar backend deals with that case, somehow.) I agree that invoking operations on backends which are opened but not authenticated yet leads to issues, bugzilla shows couple of them, but I seem to miss here something too. Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Tue, 2011-04-19 at 19:02 -0400, Matthew Barnes wrote: On Tue, 2011-04-19 at 23:25 +0100, David Woodhouse wrote: Note the 'gboolean retrying' argument to the libsoup authenticate signal handler. We probably want to have something similar in the above API too, because that's what tells the UI that it needs to ditch the existing remembered password and ask for a new one. Excellent point, definitely want that. e_credentials_equal() or e_credentials_equal_keys() offers such functionality without a need of an extra parameter in a callback - I do that in the http calendar backend, if you want to look. Maybe it needs a little bit fixing, but such logic may work, mostly. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Tue, 2011-04-19 at 17:00 +0200, Milan Crha wrote: On Tue, 2011-04-19 at 19:39 +0530, Chenthill Palanisamy wrote: I would like you to a incorporate some change to the free/busy api. Some servers allow querying free/busy information for multiple users at a time and the results appear in a iterative fashion. The freebusy information of some users are delivered first, while the server keeps fetching other user's free/busy information. So if we could have he FreeBusy api such as this, we could leverage those features, ECalClientFreeBusy e_cal_client_get_freebusy_object_sync (ECalClient *client, time_t start, time_t end, const GSList *users, GCancellable *cancellable, GError **error); (with a async counter-part) Signal: freebusy_received (ECalClientFreeBusy *fbobject, const gchar *user, GSList *ecalcomps) The clients could watch for the signal and update the freebusy information as and when they receive from eds. Hi, I rethought my thoughts about this and I think I follow your idea more closely now. If I try to rephrase it, then it might be: On the server side, add new e_data_cal_notify_free_busy_data (..., const GSList *ecalcomps); which invokes a signal on the D-Bus connection about (partial) result for a free/busy request (note it doesn't provide user separately). This signal will be valid only while a get_free_busy request is running. Calling e_data_cal_notify_free_busy_data() out of these functions will not fail, but the ECalClient consumer may not expect that being done. With this limitation we'll have a possibility to cancel pending request, if needed. The e_data_cal_respond_get_free_busy() will have no return values. On the client side, the 'finish' function will be also void and any information about free-busy will be available exclusively in a free-busy-received signal, which will have a parameter GSList *ecalcomps. I hope we are on the same line now. If you agree, then I'll make a change in this way. Thanks and bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
