| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
e_config_add_skip_check()
e_config_class_remove_factory()
e_config_create_window()
e_config_page_get()
e_config_page_next()
e_config_page_prev()
e_config_set_page_is_finish()
Also remove E_CONFIG_ASSISTANT and all the assistant support therein.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of stuffing host/port/user/etc into CamelURLs.
To enforce this in 3rd party extensions, remove EAccounts from
EMConfigTargetAccount and rename it EMConfigTargetSettings with
the following struct members:
const gchar *email_address;
const gchar *storage_protocol;
CamelSettings *storage_settings;
const gchar *transport_protocol;
CamelSettings *transport_settings;
|
| |
|
|
|
|
|
|
| |
Allows plugins to manipulate a CamelSettings instance directly. The
settings are written back to the URL string (for now) when the user
clicks Apply in the mail account editor.
|
|
|
|
|
| |
Use e_mail_folder_uri_from_folder() if you really need a folder URI for
the target's CamelFolder.
|
|
|
|
|
|
|
| |
Rename the existing 'account' member to 'modified_account' and add an
'original_account' member so plugins have direct access to both.
Mostly of benefit to the imap-features plugin.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Require all EPlugin and EPluginHook subtypes be registered before
loading plugins. This drastically simplifies the EPlugin/EPluginHook
negotiation.
- Turn most EPluginHook subtypes into GTypeModules and register their
types from an e_module_load() function (does not include shell hooks).
- Convert EPluginLib and the Mono and Python bindings to GTypeModules
and register their types from an e_module_load() function, and kill
EPluginTypeHook.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
More changes to come.
svn path=/trunk/; revision=36247
|
|
|
|
| |
svn path=/trunk/; revision=35663
|
|
|
|
|
|
|
|
|
|
| |
2007-09-02 Matthew Barnes <mbarnes@redhat.com>
* Update FSF address in header comments (#469886).
Patch from Tobias Mueller.
svn path=/trunk/; revision=34151
|
|
svn path=/trunk/; revision=27300
|