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-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-05-28T13:56:30+00:00 Matthew Barnes mbarnes@redhat.com 2013-05-26T20:18:25+00:00 urn:sha1:04aa0fba1f96cac50e8006e7dd806cf042138851 To make Evolution's shared libraries more consistent. Also add an evolution-mail-formatter documentation module. 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. 2013-02-01T13:44:50+00:00 Matthew Barnes mbarnes@redhat.com 2013-02-01T13:44:50+00:00 urn:sha1:9a0b1266b5686d4985fec8a0dae7fdf00b1b8dd9 Restore this commit with a proper bug fix to follow. 2013-01-29T15:31:58+00:00 Milan Crha mcrha@redhat.com 2013-01-29T15:31:58+00:00 urn:sha1:57adde4be6ef1709008dc27af43ada147cf21588 This reverts commit bf30024dd7973006bf99d0ae509a7f0022368a41, because it breaks EMailFormatter/Parser extensions, like the prefer-plain. The thing is that the internal formatters/parsers (also extensions) should be always added first, and only after then can be added extended extensions, which are used before those internal. This constraint was not satisfied with the reverted commit, the order of extension registration was unpredictable, depended on GType. 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-12-07T22:40:28+00:00 Matthew Barnes mbarnes@redhat.com 2012-12-07T21:30:18+00:00 urn:sha1:bf30024dd7973006bf99d0ae509a7f0022368a41 Now we have the following extension points in the GType hierarchy: E_TYPE_MAIL_FORMATTER_EXTENSION E_TYPE_MAIL_FORMATTER_PRINT_EXTENSION E_TYPE_MAIL_FORMATTER_QUOTE_EXTENSION E_TYPE_MAIL_PARSER_EXTENSION A registry just needs to be given one of these extension points, and it can use g_type_children() to find and load all registered extensions. This eliminates e-mail-format-extensions.[ch] as well as the dynamic loaders I added a few commits back. Dynamically loaded extensions are now easier to register, at the cost of internal extensions being a tad more cumbersome to register. Fair tradeoff, imo. This also makes e_mail_extension_registry_add_extension() a private function used only by e_mail_formatter_extension_registry_load() and e_mail_parser_extension_registry_load().