aboutsummaryrefslogtreecommitdiffstats
path: root/modules/cal-config-contacts/evolution-cal-config-contacts.c
Commit message (Collapse)AuthorAgeFilesLines
* Consolidate base utility libraries into libeutil.Matthew Barnes2012-12-131-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Move ECalSourceConfig to /widgets/misc.Matthew Barnes2012-06-151-1/+1
| | | | | | ECalSourceConfig drags in no additional dependencies, and although we do publish a libevolution-calendar.so, this keeps all the ESource config UI in one place so it can more easily be moved to Evolution-Data-Server.
* Move EBookSourceConfig to /widgets/misc.Matthew Barnes2012-06-151-1/+1
| | | | | | | | | | | EBookSourceConfig drags in no additional dependencies, and allows us to delay publishing a libevolution-addressbook.so since 3rd party packages will need to subclass EBookSourceConfig. The address book source code will need to be flattened into a single library before we could publish a libevolution-addressbook.so anyway. That would be a good thing to do regardless -- Evolution has way too many internal libraries -- but it's out of scope at the moment.
* Adapt to single-include E-D-S libraries.Matthew Barnes2012-06-041-1/+1
|
* Add 'cal-config-contacts' module.Matthew Barnes2012-06-031-0/+256
Registers the "Contacts" backend in ECalSourceConfig widgets.