Re: [Evolution-hackers] Update on the composer port

[Milan Crha <mcrha redhat com>]

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