[Evolution-hackers] Evolution library consolidation
I'm currently smoke testing Dan's webkit-composer branch before giving him the go-ahead to merge it to master. Immediately after the merge I'm going to consolidate Evolution's base libraries into a single base utility library. libeutil seems as good a name as anything else I can think of, so I'm going to stick with that. I'm also going to absorb libedataserverui back into Evolution, since Evolution is now the only module using it (I've done my due diligence on other modules that still show a dependency -- in most cases it was just a historical artifact that could be dropped). So all the non-deprecated APIs in libedataserverui will become part of Evolution's new libeutil. I plan to have this in for Evolution 3.7.3. The new libeutil will include APIs that are currently scattered across: a11y/libevolution-a11y.so e-util/libeutil.so filter/libfilter.so widgets/e-timezone-dialog/libetimezonedialog.so widgets/editor/libeeditor.so (new in Dan's branch) widgets/menus/libmenus.so widgets/table/libetable.so widgets/text/libetext.so libedataserverui/libedataserverui.so (from E-D-S) At least, that's the list for starters. I'd still like to keep things like libemformat.so, libcomposer.so and libeshell.so separate. I'm on the fence about the smime libraries. Additionally, since almost all the #include paths will need updating anyway, I'm going to move libeutil to a single-include model like we've done for Camel and E-D-S. In addition to convenience, it helps shield 3rd party apps as well as our own extension packages from quite so much API churn, even though we still make no guarantees about API stability in Evolution libraries. The new #include directive for libeutil will be #include libeutil/libeutil.h which will bring in all headers in the library. With all the base utility libraries under one header, maybe we can then get serious about producing some good API documentation for this stuff. My attempts thus far have been half-hearted at best. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution slowing down
Hi all Is it just me, or is evolution 3.6 now really slow. I find opening and closing message windows markedly slower than 3.2 on the same hardware. Even worse, the slowness gets worse with usage - so after a day's usage it is pretty intolerable (to the point where the window manager kicks in thinking the application is unresponsive). I'm guessing it is the move to webkit or whatever for viewing messages? The slowness is obvservable for both reading a message and composing a message. Anyone else seen this? Karl ___ 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 slowing down
On Tue, 2012-11-27 at 18:59 +, Karl Relton wrote: Is it just me, or is evolution 3.6 now really slow. I find opening and closing message windows markedly slower than 3.2 on the same hardware. Probably just you, since I've not seen any such slowdown. If anything, rendering is much faster now with the move to WebKit. One possibility is your mail summary database has accumulated a lot of cruft and needs garbage collected. Unfortunately we don't yet run this automatically so it has to be done manually. Eventually I'd like to tie it into Folder - Expunge and File - Empty Trash. Shutdown Evolution and try running this little script: http://mbarnes.fedorapeople.org/evolution-rebuild-summarydb Matthew Barnes ___ 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 library consolidation
On Tue, 2012-11-27 at 14:20 -0500, Matthew Barnes wrote: The new libeutil will include APIs that are currently scattered across: a11y/libevolution-a11y.so e-util/libeutil.so filter/libfilter.so widgets/e-timezone-dialog/libetimezonedialog.so widgets/editor/libeeditor.so (new in Dan's branch) widgets/menus/libmenus.so widgets/table/libetable.so widgets/text/libetext.so libedataserverui/libedataserverui.so (from E-D-S) Addendum: Forgot to list an obvious and important one: widgets/misc/libemiscwidgets.so ___ 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] UI interaction from book/calendar backends
Yes, the gtk_init() issue occurred to me after posting that suggestion. I agree a separate process is the better idea. Then gtk3 won't taint evolution-source-registry. (Apologies for top-posting. I'm trying out Dan's webkit-composer branch and it seems to have some kinks yet to be worked out, especially in quoted replies.) Matt On Mon, 2012-11-26 at 08:37 +0100, Milan Crha wrote: On Thu, 2012-11-22 at 13:04 -0500, Matthew Barnes wrote: 1) Write this as a ESourceRegistryServer extension, and just link to GTK+ from the extension module. That way it's easily removable if the Tizen folks don't want it, or they want to implement their own version using Qt. Hi, I was thinking of it, and I feel like it's not correct to initialize gtk within an extension, thus this should be just a new server within eds, with its default implementation using gtk3, which will be accessed through DBus (as you suggested), thus will be replaceable by other implementations. 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 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
