This is easier to handle if we decide to add callbacks. Since we can
zero-initialize callbacks before passing it to the plugin we can be certain as
to which callbacks the plugin knew about when it was compiled. This is exactly
the same method used for GeanyPlugin::info already and easier than inspecting
the API version.
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.
We want it disabled by default in 1.25 for everyone, but want to be
able to get it back on by default later on when the UI is more
polished.
So we will need to have a way to tell whether the configuration comes
from 1.25 and should be upgraded or was willfully disabled by the user
in a later version. So, use a temporary setting name that defaults to
disabled for 1.25
See #553.
Hide spawn_get_program_name(), spawn_async_with_pipes() and
spawn_get_exit_status_cb(), which are not used by anyone else and
should not be part of the plugin API unless explicitly required.
See http://lists.geany.org/pipermail/devel/2015-June/thread.html#9521
Note: this duplicates some documentation when a now hidden function was
referred to.
While the feature is nice, it might be unexpected and lacks user
feedback. This might lead to user thinking they lost their work
because they don't know they can undo the reload operation.
So, disable the feature by default until we introduce appropriate user
feedback allowing the user to learn about the feature and new behavior.
See http://lists.geany.org/pipermail/devel/2015-June/thread.html#9537
Since we build libgeany some ld flags were applied to libgeany only.
Some of them need to be applied to the main binary as well.
This fixes the problem that a sticky terminal window starts together
with geany.
This automatically keeps the installer's idea of Gtk version with the one
used to compile geany in sync.
Traditionally we use the bundles from gtk.org to compile geany, and this
is also used for the installer. With msys2, we can use precompiled
msys2 binaries. These exist for GTK3 as well so we can actually provide a
GTK3 based installer. The installer naturually should reflect this.
Msys2's GTK2 is also newer.
Use the new script gtk-bundle-from-msys2.sh to extract the precompiled
GTK binaries from msys2 / pacman for packing the installer (can also be
used to make a zip for sharing).
mkdir gtk; cd gtk; ../scripts/gtk-bundle-from-msys.sh [-c] [-z] [-2 | -3]
waf is also adapted to process geany.nsi.in. This implies geany.nsi is now
under _build_, not in the root anymore.
autotools based build system uses only config.h. This file was lacking some
important defines. Rather than maintaining the defines in all build systems,
we can simply define in a specialized header that is included by all .c files
that use windows.h
Ubuntu's linker apparently has a bug when installing in /usr/local/lib,
as it is setup in such a way that makes libtool recognize it correctly
as a system path so doesn't add RPATH to our executable, but ld can't
find the library without an explicit ldconfig call (unlike when
installing in /usr/lib).
So, workaround this by explicitly calling ldconfig when installing in
/usr/local/lib -- and when our library is actually not found, to try
and avoid doing something unnecessary on working systems, like e.g.
Debian.
