Google Summer of Code 2013 - GNOME - Archive Integration workspace https://www.lant.com.tw/~lantw44/cgit/cgit.cgi/gsoc2013-evolution/atom?h=master 2014-06-09T14:32:25+00:00 2014-06-09T14:32:25+00:00 Tomas Popela tpopela@redhat.com 2014-06-09T14:32:25+00:00 urn:sha1:8650fb139a9143f04615de74ff569bce3e0c4ce3 Merge wip/webkit-composer branch into master. 2014-06-04T17:46:25+00:00 Milan Crha mcrha@redhat.com 2014-06-04T17:46:25+00:00 urn:sha1:2f3fbdd6c6ff42a6c71ebe1d1d78108affe59d0f This is related to bug 698275, which did not cover all cases. The problem here is that the dconf can in certain situation claim that everything changed (path "/" changed), which GSettingsBinding propagates to a GObject property unconditionally and GObject's property setter (g_object_set_property()) also notifies about the property change unconditionally, despite the real descendant property setter properly checks for the value change. After all these false notifications a callback on "notify" signal is called and possibly an expensive operation is run. Checking whether the value really changed helps in performance, for which were added new e-util functions: e_signal_connect_notify() e_signal_connect_notify_after() e_signal_connect_notify_swapped() e_signal_connect_notify_object() which have the same prototype as their GLib counterparts, but they allow only "notify::..." signals and they test whether the value really changed before they call the registered callback. 2014-03-25T11:04:58+00:00 Milan Crha mcrha@redhat.com 2014-03-25T11:04:58+00:00 urn:sha1:8692b1cb72654888f0dab31843bdf05d3ac2a888 When enabled, this will compile all libraries/binaries with the necessary gcc and ld flags to enable code coverage support using gcov. 2014-01-07T21:05:51+00:00 Matthew Barnes mbarnes@redhat.com 2014-01-07T19:19:27+00:00 urn:sha1:b21733d06715597b189c4271a2e9d625f5fc2345 2013-09-07T23:08:54+00:00 Matthew Barnes mbarnes@redhat.com 2013-09-07T16:31:19+00:00 urn:sha1:3da4948c0fc1f2c21b163f0ec456b2d99c881258 2013-05-28T13:56:30+00:00 Matthew Barnes mbarnes@redhat.com 2013-05-26T19:41:29+00:00 urn:sha1:70a9fcdf9c61c09fcac72ddf99e73cb57ed99017 To make Evolution's shared libraries more consistent. Also rename the documentation module to evolution-shell. 2013-05-28T13:56:30+00:00 Matthew Barnes mbarnes@redhat.com 2013-05-26T18:57:43+00:00 urn:sha1:6c9a3243c9b335cb7e5873b15562263e74293dc2 To make Evolution's shared libraries more consistent. Also rename the documentation module to evolution-util. 2012-12-12T19:33:47+00:00 Matthew Barnes mbarnes@redhat.com 2012-12-12T18:11:13+00:00 urn:sha1:bed06d9ec3914ba39975a58797e79ff2ad028768 Move the supporting widgets for the contact maps feature alongside EABContactDisplay. Removing them from libeutil helps isolate our usage of libchamplain so it's not imposed on the entire application, and even 3rd party software. That libchamplain is an optional dependency only further complicates the matter. Ideally I'd like to somehow isolate this feature in an extension module, but we currently lack sufficient hooks for such an extension. So this arrangement will have to suffice for now. 2012-12-12T19:33:43+00:00 Matthew Barnes mbarnes@redhat.com 2012-12-10T13:09:59+00:00 urn:sha1:d09d8de870b6697c8a8b262e7e077b871a69b315 Evolution consists of entirely too many small utility libraries, which increases linking and loading time, places a burden on higher layers of the application (e.g. modules) which has to remember to link to all the small in-tree utility libraries, and makes it difficult to generate API documentation for these utility libraries in one Gtk-Doc module. Merge the following utility libraries under the umbrella of libeutil, and enforce a single-include policy on libeutil so we can reorganize the files as desired without disrupting its pseudo-public API. libemail-utils/libemail-utils.la libevolution-utils/libevolution-utils.la filter/libfilter.la widgets/e-timezone-dialog/libetimezonedialog.la widgets/menus/libmenus.la widgets/misc/libemiscwidgets.la widgets/table/libetable.la widgets/text/libetext.la This also merges libedataserverui from the Evolution-Data-Server module, since Evolution is its only consumer nowadays, and I'd like to make some improvements to those APIs without concern for backward-compatibility. And finally, start a Gtk-Doc module for libeutil. It's going to be a project just getting all the symbols _listed_ much less _documented_. But the skeletal structure is in place and I'm off to a good start. 2012-06-03T19:14:03+00:00 Matthew Barnes mbarnes@redhat.com 2012-06-03T19:14:03+00:00 urn:sha1:2a39437ee94059a79d3dc1bf0c97a3aeaff23f53