It sounds like the GTK required a modification to libdecor, I'm guessing they wanted the API to the plugin altered? Was it a major change, or only a minor addition?
The 2 plugins use exactly the same API in their communication with libdecor.
The single change to libdecor was the addition of one source file libdecor-gtk.c.
That's reflected in the fact that FLTK with OPTION_USE_SYSTEM_LIBDECOR to ON, which uses the libdecor-0.so of the Debian package
and dlopen's libdecor-gtk.so of the GTK-extended modified libdecor source code, runs well.
My vague impression is the best method for fltk is to implement this api (by including the source code to libdecor) on the assumption that it will be able to load more plugins than the unmodified one. However I don't think fltk should include any plugins, instead there should be a compiled-in fallback that is used if the plugin could not be found or does not load.
We agree on that, for a future situation when GTK-styled plugins will be available to FLTK users.
This will allow a statically-linked fltk program to be distributed as a single executable. This fallback probably should be extremely simple though it should draw the window title text at least.
I'd say that libdecor-cairo.c does an excellent fallback mechanism.
There remains an issue. FLTK needs access to the pixel array of the titlebar to implement features that draw decorated windows.
That's not part of the libdecor public API.
I've put in libfltk a function that gives access to this pixel array for the cairo-style titlebars and another one for the GTK-style ones.
The problem is that libfltk needs to know which one to use.
Practically, access to the pixels of window titlebars doesn't work now with OPTION_USE_SYSTEM_LIBDECOR to ON and with the
GTK-style plugin because it uses the function adequate for the other plugin. Everythink works with OPTION_USE_SYSTEM_LIBDECOR
turned OFF.
The ideal solution for us would be for libdecor to add one piece to its public API: access to the pixel array of a window titlebar.
