Re: [Evolution-hackers] Update on the composer port
On Tue, 2012-09-04 at 12:08 -0400, Matthew Barnes wrote: Yeah, I'm toying with the idea of merging all these base libraries into one. libeutil + libemiscwidgets + libetimezonedialog + libetext + libetable + libemenus + ... there's just way too many already. Linking to all these shared libraries from layers higher up is a real PITA and probably increases our startup time since each shared library has to be loaded serially. Hi, I hope it's not the issue. I see main trouble elsewhere. Evo's slow start begun in time of move to GSettings, and got slightly worse when each CamelStore is initialized (there used to be initialized only those for which accounts are enabled), and recently with the new ESource API. There is also shown, when running evolution in calendar, initialization of the mail part as well, same as I see huge I/O activity on evolution's start, where this all definitely slows things down, not the libraries, which are there for ages. Mine ~/.config/evolution/sources/ has 214 files, which takes some time to load for sure. From my point of view is issue with bindings on GSetting properties. As you told me (and pointer to devel docs) the GSettings notify:: signals are not emitted when the value changes, but only when there is a chance the value could change. Because of use of GBindings and hard callback calls (hard in a meaning that the local cache of the value is not tested with the new value, to not call signal handlers when value didn't change) forces evolution doing useless ops on fake change notifications. The best would be to fix GSettings. The changes on g_object_notify() calls I did for eds evo helped a bit, but not enough (there were few regressions, some code expected the notify being called always, but I think (and hope) we found all of them already). ESource used to emit fake changed signals, likely on load, but I didn't check the latest code, thus maybe it's gone now (one example I knew about, if the ESource has added new EExtension into itself, then it notifies about change, but it does so also when reading the EExtension from the saved file, which is incorrect, because it's just a load of already saved data). Anyway, just my opinion on the issue. Finally, Milan had some objections against the EEditor prefix, feel free to discuss a better alternative. No strong opinion here. I can live with EEditor. My concern was that there is a CompEditor already, thus the EEditor, which is supposed to be part of CompEditor for the Description part of respective pages, might be slightly confusing. After all, the EEditor is just a text editor (ETextEditor?). Maybe following predefined EWebView, make it EWebEditor, where Web means webkit, not WWW? Though even that sounds silly. Because I cannot offer better name, and Matthew is fine with Dan's name, then feel free to keep it as is. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution 3.8 Planning
Hi Matt, Am Dienstag 04 September 2012, um 17:05:36 schrieb Matthew Barnes: Few quick announcements: I started a new planning page on the wiki for Evolution 3.8 and seeded it with a few items. Would appreciate seeing it fleshed out a bit more. https://live.gnome.org/Evolution/Planning38 Thanks for the heads-up. I remember you mention some sort of API restructuring / rework concerning E-D-S, D-Bus and EClients you had in mind for 3.7/3.8 cycle. Do you have anything cooking in this regard already? Might be worth putting on that page. Milan and I discussed gnome-3-6 branches today. I'm ready to branch and begin 3.7 development now, but for the sake of translators we'll hold off until September 17 when GNOME 3.5.92 enters its hard code freeze. Sounds good to me. Also I'll be taking personal time off the latter half of this month, as will Milan I believe. So you may be hearing crickets in #evolution for couple weeks. I'll still have email and will get the 3.6.0 release out on time. Returning the first week of October. That's some valuable bits of information, thanks. Matthew Barnes Kind regards, Christian -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution 3.8 Planning
On Wed, 2012-09-05 at 09:57 +0200, Christian Hilberg wrote: Thanks for the heads-up. I remember you mention some sort of API restructuring / rework concerning E-D-S, D-Bus and EClients you had in mind for 3.7/3.8 cycle. Do you have anything cooking in this regard already? Might be worth putting on that page. My plan is to write XML interface specifications for all our calendar and address book D-Bus interfaces, use gdbus-codegen to generate the GDBus classes, and throw away our old egdbus libraries. I've already made some progress on this. We're currently using gdbus-codegen to generate the GDBus classes for the evolution-source-registry service. It's a fantastic tool and the XML interface specs are much easier to maintain and extend. As I recall, the current D-Bus classes in our internal egdbus libraries were generated once by some now-unsupported and non-working precursor to gdbus-codegen, so we've been stuck hand-maintaining the generated C code. That makes any D-Bus interface changes we wish to make (such as adding a synchronize method) a royal PITA. While I'm at it I'll be deprecating some parts of the EClient APIs whose function signatures imply they're non-blocking but in fact make blocking D-Bus calls, and replacing them with proper cancellable synchronous and asynchronous functions. I'll try my best to NOT break the libebook and libecal APIs. Not yet sure of the impact to backend APIs, I'll know better shortly. Since I'm hoping to wrap this up in time for 3.7.1 and it's really just a cleanup operation, I'm not sure if it's worth listing on the planning page. If the scope of this project balloons too much I may reconsider. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
