It was found that because geany_plugin_set_data() could be used by both
plugin's init() and geany_load_module(), that it introduced some uncertainty
as to when to call the free_func. init() callers might expect the call
around the same time as cleanup() is called, while geany_load_module()
callers expected the call at module unload time.
It was indeed called at module unload time. But that means that init() callers
cannot call it again reliably after in a init()->cleanup()->init() flow (when
toggling the plugin) without fully unloading the plugin (which is what we do
currently but that's we would want to change).
With the separation we can actually destroy the data depending on where
it was set and do everything unambigiously.
With geany_plugin_set_data() the legacy plugin support can be made
more transparent by using wrapper functions that call the actual plugin_*
functions. This allows to remove the differentiation in code that's not
directly concerned with actually loading plugins.
This commit doesn't change anything except for one thing: legacy plugins now
cannot call geany_plugin_set_data(). But it is meant for new-style plugins
anyway.
The API function adds a free_func parameter, and can also be called
after geany_plugin_register(), i.e. in the plugin's init() callback. This
fixes a by-design memory leak and gives greater flexibility.
The old plugin loader has a number of deficiencies:
- plugins need to export a couple of callback functions into the global namespace
- plugins need to export data pointers, that are written by Geany
- the exported functions have no user_data param, so there is no way to
pass context/state back to the plugin (it needs global storage for that)
- plugin registration is implicit, plugins have no way to not register themselves
(it may want that due to missing runtime dependencies)
- plugins perform the ABI/API verification, and even though we provide a
convinience wrapper, it may get that wrong
As a result, I designed a new loader with the following design principles
- semantics of callbacks should not change, but they they shouldn't be mess
with the global namespace
- each callback receives a self-identifying param (the GeanyPlugin instance) and
a plugin-defined data pointer for their own use
- explicit registration through a new API function
- in-core API/ABI checks
The following principles shall be left unchanged:
- The scan is done on startup and when the PM dialog is opened
- Geany allocates GeanyPluginPrivate for each plugin, and GeanyPlugin is
a member of it
- Geany initially probes for the validity of the plugin, including file type
and API/ABI check, thus Geany has the last word in determining what a
plugin is
- the PM dialog is updated with the proper, translated plugin information
- the PM dialog GUI and user interaction in general is unchanged
With the redesign, plugins export a single function: geany_load_module().
This is called when the GModule is loaded. The main purpose of this function
is to call geany_plugin_register() (new API function) to register the plugin.
This is the only function that is learned about through g_module_symbol().
Within this call the plugin should
a) set the localized info fields of GeanyPlugin::info
b) pass compiled-against and minimum API version as well as compiled-against
ABI version, to allow Geany to verify compatibility
c) pass a pointer to an instance of GeanyPluginFuncs
which holds pointers to enhanced versions of the known callbacks (except
configure_single which is dropped).
d) optionally pass a plugin-private data pointer for later callbacks
Enhanced means that all callbacks receive the GeanyPlugin pointer as the first
and a pdata pointer as the last. pdata is private to the plugin and is set
by geany_plugin_register().
The callbacks need (should) not be globally defined anymore, and the global
GeanyData, GeanyPlugin and GeanyFunctions pointers are ignored and not set
anymore. GeanyData is available through GeanyPlugin::geany_data.
This makes it easier to define it consistently to what the compiler
and platform supports, and avoids having to include a special header
everywhere, which is some kind of a problem for separate libraries
like TagManager and especially Scintilla.
As we only use these macros from the source and not the headers, it
is fine for it to be defined to a configure-time check from the build
system.
Warning: Although Waf and Windows makefiles are updated they are not
tested an will probably required tuning.
Adds a new header `pluginexport.h` to put the macros in, could be
moved into an existing header (support.h?) by I didn't want to drag
a bunch of existing stuff into the source files for this one macro.
TagManager has relative include, this could be fixed by changing the
include directories for it if it's a problem. Mark the Scintilla
functions exported by re-declaring them in sciwrappers.c with the
attribute to avoid changing upstream Scintilla code.
This is a mega-commit - because most of it had to be done in one go
otherwise some commits would fail to compile - that attempts to fix a
few problems with Geany's includes as well as various other related
cleanups. After this change it's easier to use includes and there's
little worry about which order things are included in or who includes
what.
Overview of changes:
* Include config.h at the start of each source file if HAVE_CONFIG_H
is defined (and never in headers).
* Go through each source file and make the includes section generally
like this:
- Always config.h first as above
- Then if the file has a header with the same name, include that
- Then include in alphabetical order each other internal/geany header.
- Then include standard headers
- Then include non-standard system headers
- Then include GLib/GTK+ related stuff
* Doing as above makes it easier to find implicit header include
dependencies and it exposed quite a few weird problems with includes
or forward declarations, fix those.
* Make geany.h contain not much besides some defines.
- Add a little header file "app.h" for GeanyApp and move it there
- Move "app" global to new "app.h" file
- Move "ignore_callback" global to "callbacks.h"
- Move "geany_object" global to "geanyobject.h"
* Add an include in "geany.h" for "app.h" since GeanyApp used to be
defined there and some plugins included this header to access
GeanyApp.
* Include "gtkcompat.h" everywhere instead of gtk/gtk.h so that
everywhere sees the same definitions (not a problem in practice AFAIK
so this could be changed back if better that way.
* Remove forward declarations from previous commits as some people
apparently consider this bad style, despite that it reduces inter-
header dependencies.
TODO:
* As always, to test on win32
* As always, to test with not Autotools
* Test plugins better, both builtin and geany-plugins, likely API/ABI bump
* Test with various defines/flags that may change what is included
* win32.[ch] not really touched since I couldn't test
Watch the lifetime of objects referenced in plugin->signal_ids and
remove our references to them if they get destroyed. This avoids
possibly trying to disconnect signals on destroyed objects when the
plugin is unloaded.
Supporting this case is safer, and is useful for objects that may or
may not outlive the plugin (like ScintillaObjects), because in such
cases plugin_signal_connect() is handy to make sure the signals are
disconnected if the object is still alive, but used to crash if the
object was destroyed.
These functions does the same as the corresponding GLib functions but
makes sure that the added GSource will be removed when the plugin is
unloaded, preventing possible crashes.
These are only convenience functions for the plugin author not to have to
care about the case the plugin gets unloaded, he can still manually
manage hes GSources if he wants to.
git-svn-id: https://geany.svn.sourceforge.net/svnroot/geany/trunk@5650 ea778897-0a13-0410-b9d1-a72fbfd435f5
pointer syntax instead of @signaldef as this puts a summary of
the signal names at the top of the page and sorts alphabetically.
(Note: the syntax is similar to Vala signal syntax).
git-svn-id: https://geany.svn.sourceforge.net/svnroot/geany/trunk@5065 ea778897-0a13-0410-b9d1-a72fbfd435f5
Fix 'Date' appearing twice on the date line.
Don't generate API docs for prefs.h, toolbar.h (unused).
Move some '@file' doc-comments to the .c file.
git-svn-id: https://geany.svn.sourceforge.net/svnroot/geany/trunk@4772 ea778897-0a13-0410-b9d1-a72fbfd435f5
to be ignored if inappropriate so a later keybinding with the same
key combination can intercept it. (Also group callbacks are usually
tidier than separate callbacks).
Remove special handling for GEANY_KEYS_EDIT_COMPLETESNIPPET.
git-svn-id: https://geany.svn.sourceforge.net/svnroot/geany/trunk@4300 ea778897-0a13-0410-b9d1-a72fbfd435f5
these fields.
Make keybindings_set_item() duplicate the name and label fields
(needed by GeanyLua) and return a keybinding pointer.
Add keybindings_get_item() to the API (in case it's useful).
Move some keybinding code out of plugin source files.
git-svn-id: https://geany.svn.sourceforge.net/svnroot/geany/trunk@4123 ea778897-0a13-0410-b9d1-a72fbfd435f5
GeanyKeyBinding or GeanyKeyGroup structs, so we don't need to break
the ABI when adding fields to them.
Add plugin_set_key_group() for plugins to dynamically set a
keybinding group (e.g. for the Lua script plugin). Used in Split
Window plugin as an example.
Improve keybinding docs a little.
git-svn-id: https://geany.svn.sourceforge.net/svnroot/geany/trunk@4115 ea778897-0a13-0410-b9d1-a72fbfd435f5
runtime and also for connecting to any GObject signal.
Add 'Plugin Utility Functions' on main page.
Add foreach_array() macro.
git-svn-id: https://geany.svn.sourceforge.net/svnroot/geany/trunk@4041 ea778897-0a13-0410-b9d1-a72fbfd435f5
