[Evolution-hackers] Removal of implementation details from public API, any breakages?
Hi, Last week I committed a patch to libebook, and want to commit a patch to libecal[1], which removes private functions and types from the installed headers. This has several consequences: - e_cal_view_new() is removed - ECalListener is removed - ECalViewListener is removed I believe that nobody is using these functions apart from libecal itself, so this removal is safe. However, I'd appreciate it if anyone writing advanced clients to EDS (like Zimbra or Brutas) remove their currently installed headers, apply the patch, and rebuild. Thanks, Ross [1] http://bugzilla.gnome.org/show_bug.cgi?id=438727 -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Removing libical fork, moving to new upstream?
Hi, I discovered last week that there is an attempt to resurrect libical from non-maintainership, merge all of the patches from various forks, and start making sane releases again[1]. Are the evolution team as whole interested in merging their changes to libical upstream and depending on it to be installed when a release is made with all of the relevant changes? libical isn't exactly a small library, and statically linking it is a waste of memory for everyone. I'll happily start working on extracting the changes to EDS and pushing them into the new libical repository, if the Evolution team as a whole agrees that the fork of libical will be dropped. Ross [1] http://sourceforge.net/projects/freeassociation/ -- last commit two weeks ago! -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: I'll happily start working on extracting the changes to EDS and pushing them into the new libical repository, if the Evolution team as a whole agrees that the fork of libical will be dropped. +1 Matthew Barnes ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Proposed fix for bug 311512
Hi friends I have submitted new patches to bugzilla for bug http://bugzilla.gnome.org/show_bug.cgi?id=311512 One changes e-d-s as Fejj suggested, the other does the Evolution side so it will only do mail-notification on 'truely' new messages. I'll be pleased if you could review. Karl On Thu, 2007-04-26 at 09:29 -0400, Jeffrey Stedfast wrote: not completely correct... when you trigger an event on a CamelObject, it first fires the prep callback, which is what camel-folder.c:folder_changed() is (note that it returns bool) A prep event handler is the first handler called (event handlers are fired sequentially, in order of connection - /not/ in parallel) and gets to decide if the event propagates by returning TRUE (or FALSE if it should be blocked - that's how freeze/thaw works). ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Proposed fix for bug 311512
Karl, This is a killer problem and you have been rocking with your patches on this right from the beginning. Awesome work! I'm sure that the Mailer hackers would review it asap and It will be great if we can get this in for 2.11.3. Thanks for your great work! -Srini. On Sun, 2007-05-20 at 19:29 +0100, Karl Relton wrote: Hi friends I have submitted new patches to bugzilla for bug http://bugzilla.gnome.org/show_bug.cgi?id=311512 One changes e-d-s as Fejj suggested, the other does the Evolution side so it will only do mail-notification on 'truely' new messages. I'll be pleased if you could review. Karl On Thu, 2007-04-26 at 09:29 -0400, Jeffrey Stedfast wrote: not completely correct... when you trigger an event on a CamelObject, it first fires the prep callback, which is what camel-folder.c:folder_changed() is (note that it returns bool) A prep event handler is the first handler called (event handlers are fired sequentially, in order of connection - /not/ in parallel) and gets to decide if the event propagates by returning TRUE (or FALSE if it should be blocked - that's how freeze/thaw works). ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: Hi, I discovered last week that there is an attempt to resurrect libical from non-maintainership, merge all of the patches from various forks, and start making sane releases again[1]. Are the evolution team as whole interested in merging their changes to libical upstream and depending on it to be installed when a release is made with all of the relevant changes? libical isn't exactly a small library, and statically linking it is a waste of memory for everyone. I vaguely recall the biggest diff being timezone handling. I'll happily start working on extracting the changes to EDS and pushing them into the new libical repository, if the Evolution team as a whole agrees that the fork of libical will be dropped. I'd suggested waiting to see a pattern of stable releases before moving externally, but getting the patches upstream would be good. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
