What I don't understand is why you are not actually testing a *plugin*. The code for drawing using GTK should not be part of fltk. IMHO the code in fltk should look for the libdecor plugin and if found load it and use it. If not found then there could be a fallback, probably using a copy of the decor-cairo code, or even something simpler using fltk drawing functions.
Unless we are actually loading plugins that dlload code is *not* being tested and that is wrong.
It works. I did this :
- build with meson + ninja the libdecor software containing the libdecor-gtk.c addition;
- this creates 3 shared libs: libdecor-0.so, libdecor-cairo.so, libdecor-gtk.so.
The last 2 are plugins, one of which is loaded by dlopen() by the 1st shared lib.
- define environment var LIBDECOR_PLUGIN_DIR to the directory containing libdecor-gtk.so
(this variable is the means for libdecor to discover its plugin)
- re-build FLTK with OPTION_USE_SYSTEM_LIBDECOR set to ON
- run an FLTK app: its window appears in GTK-style.
Events are :
libfltk calls libdecor which is found in libdecor-0.so, that from the Debian package libdecor-0;
libdecor-so loads with dlopen() the plugin it finds in $LIBDECOR_PLUGIN_DIR,
this plugin, libdecor-gtk.so, draws a GTK-styled window titlebar.
I believe that's not a procedure adequate for public use because it requires to download a modified
version of libdecor according to a pending Merge Request and to use meson + ninja.
That procedure should become practical once the code in the merge request will have found its way
up into Linux packages.
