| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
The EModule, EExtensible and EExtension classes as well as the
e_type_traverse() function have been moved to Evolution-Data-Server's
libebackend library to replace e-data-server-module.c.
Now Evolution-Data-Server modules use the same framework as Evolution.
|
| |
|
|
|
|
| |
Works around a design flaw in EExtension.
See the comment in e-module.c for more details.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Prefer thread-safe G_DEFINE_TYPE and G_DEFINE_INTERFACE macros over
manual GType registration.
This is just a start... lots more to do.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce e_extensible_list_extensions(), which provides extensible
objects access to their own extensions, or a subset of them.
Convert EShellBackend to an abstract EExtension subtype. EShell will
load its extensions with e_extensible_load_extensions(), and then obtain
a list of EShellBackend extensions as follows:
shell_backends = e_extensible_list_extensions (
E_EXTENSIBLE (shell), E_TYPE_SHELL_BACKEND);
Because EShellBackend is abstract, its GType is skipped while traversing
the GType hierarchy to find EShell extensions.
|
| |
|
|
|
|
| |
The mechanism here is simple but hard to explain without leaning heavily
on object-oriented jargon. Consider this a rough draft. Illustrations
would certainly help clarify.
|
|
|
This introduces a simple means of extending Evolution objects.
Any GObject subclass wishing to be extensible need only call
g_type_add_interface_static (type, E_TYPE_EXTENSIBLE, NULL);
when registering its GType, and then at some point during initialization
call e_extensible_load_extensions() to load extensions for that subclass.
Extensions are implemented by subclassing EExtension, setting the GType
being extended in EExtensionClass, and making sure its own GType gets
registered at startup. This usually done while loading a GTypeModule.
e_extension_get_extensible() provides extensions access to the object
being extended.
|
