Table of Contents
In any conflict between Epiphany's C coding style and this document's, Epiphany's is right and this document's is wrong. Particularly, tabs are 8 spaces wide and are tabs, and in each function declaration, each argument should appear on its own line, in line with the argument above it.
There is no coding standard for Python extensions.
The C LOG macro is included in ephy-debug.h. If you use --enable-debug while running configure or autogen.sh from within the epiphany-extensions/ directory, the messages will be printed with g_print, which uses a printf-like syntax.
This function is only necessary for C extensions; Python coders may skip this section.
Epiphany will look for a register_module function when loading the extension. This function is defined in extension.c if you used the copy-template script.
Read over the default example to understand what is expected: register_module must return a GObject type. Almost always, this GObject should implement the EphyExtension interface. In the template extension, this is described in the last line of the function:
return ephy_foo_extension_register_type (module);
. If you wish to register other GObject types, simply put their register_type calls above this one.
Extensions may be loaded or unloaded at any time. This means they must be registered using g_type_module_register_type. Also, due to a limitation in that function, if you update your extension to change the parent class of a particular GObject, unload the extension and then reload it within Epiphany, the new GObject class will fail to register. To avoid problems, when changing the parent class of a GObject in your extension, increment the version in the extension's XML description file.