GObject.TypePlugin¶
- Implementations:
Methods¶
|
|
|
|
|
|
|
Virtual Methods¶
None
Properties¶
None
Signals¶
None
Fields¶
None
Class Details¶
- class GObject.TypePlugin¶
- Bases:
An interface that handles the lifecycle of dynamically loaded types.
The
GObject.Object
type system supports dynamic loading of types. It goes as follows:The type is initially introduced (usually upon loading the module the first time, or by your main application that knows what modules introduces what types), like this:
new_type_id = g_type_register_dynamic (parent_type_id, "TypeName", new_type_plugin, type_flags);
where new_type_plugin is an implementation of the
GObject.TypePlugin
interface.The type’s implementation is referenced, e.g. through
GObject.TypeClass.ref
() or through g_type_create_instance() (this is being called by g_object_new()) or through one of the above done on a type derived from new_type_id.This causes the type system to load the type’s implementation by calling
GObject.TypePlugin.use
() andGObject.TypePlugin.complete_type_info
() on new_type_plugin.At some point the type’s implementation isn’t required anymore, e.g. after
GObject.TypeClass.unref
() orGObject.type_free_instance
() (called when the reference count of an instance drops to zero).This causes the type system to throw away the information retrieved from
GObject.TypePlugin.complete_type_info
() and then it callsGObject.TypePlugin.unuse
() on new_type_plugin.Things may repeat from the second step.
So basically, you need to implement a
GObject.TypePlugin
type that carries a use_count, once use_count goes from zero to one, you need to load the implementation to successfully handle the upcomingGObject.TypePlugin.complete_type_info
() call. Later, maybe after succeeding use/unuse calls, once use_count drops to zero, you can unload the implementation again. The type system makes sure to callGObject.TypePlugin.use
() andGObject.TypePlugin.complete_type_info
() again when the type is needed again.GObject.TypeModule
is an implementation ofGObject.TypePlugin
that already implements most of this except for the actual module loading and unloading. It even handles multiple registered types per module.- complete_interface_info(instance_type, interface_type, info)¶
- Parameters:
instance_type (
GObject.GType
) – theGObject.GType
of an instantiatable type to which the interface is addedinterface_type (
GObject.GType
) – theGObject.GType
of the interface whose info is completedinfo (
GObject.InterfaceInfo
) – theGObject.InterfaceInfo
to fill in
Calls the complete_interface_info function from the
GObject.TypePluginClass
of self. There should be no need to use this function outside of theGObject.Object
type system itself.
- complete_type_info(g_type, info, value_table)¶
- Parameters:
g_type (
GObject.GType
) – theGObject.GType
whose info is completedinfo (
GObject.TypeInfo
) – theGObject.TypeInfo
struct to fill invalue_table (
GObject.TypeValueTable
) – theGObject.TypeValueTable
to fill in
Calls the complete_type_info function from the
GObject.TypePluginClass
of self. There should be no need to use this function outside of theGObject.Object
type system itself.
- unuse()¶
Calls the unuse_plugin function from the
GObject.TypePluginClass
of self. There should be no need to use this function outside of theGObject.Object
type system itself.
- use()¶
Calls the use_plugin function from the
GObject.TypePluginClass
of self. There should be no need to use this function outside of theGObject.Object
type system itself.