I would call anything you dlopen a "plugin". What I call a "library" is directly named by the executable (you can list them on Linux with ldd) and is loaded before the executable is run.
I fully agree. With FLTK and Wayland, we have the same situation as with PNG: either the PNG code is compiled and put
into libfltk_png.a or .so, or the system's libpng.so is used. No dlopen involved. Thus, the libdecor code is either compiled and put into
libfltk.a or .so or the system's libdecor.so is used. No dlopen involved. Only static or dynamic linking done at build time.
The fact that this plugin when run then dlopen's even more files (as it's own internal plugin system) is not relevant for fltk.
Yes, at the FLTK level, there's no plugin, no dlopen called by FLTK. It's only when FLTK links to libdecor.so that dlopen is called
by libdecor.so to recruit another shared lib, libdecor-cairo.so.
I think the proper behavior for fltk is it should try to load this plugin (what you call the system-provided libdecor, I think). In theory a desktop would customize this file if they think it is important for titlebars to be consistent. If not found, fltk could fallback to drawing the titlebar itself, though I would like an investigation as to whether any proper wayland implementation is missing a plugin.
My understanding is that the Gnome people have decided to stop thinking about a system-level titlebar when they decided to go for CSD
(client-side decoration) : the client decorates its own windows. Gnome provides a toolkit that allows to construct CSD-adapted windows. If you use another toolkit, and FLTK is in that case, you're on your own: Gnome offers no decoration you could use without entering in GTK.
That's where libdecor is convenient because it fills this hole proposing to decorate windows.
I believe Gnome is a proper Wayland implementation that contains no plugin to decorate consistently windows. Only very recent Debian
versions have the libdecor package (it's not yet in Ubuntu) which decorates windows but not especially consistently with the desktop.
My understanding is also that this is not intrinsic to Wayland, because the KDE people have decided to go for SSD : KDE provides
a consistent decoration to windows. Libdecor is aware of that and calls on the Wayland compositor whien it runs on KDE.
It's enough for FLTK to use properly the libdecor API to itself adopt SSD when run on KDE.
I do not understand why any of this is a compile-time option, unless one of the options is to *remove* the dlopen and use the fallback always. Even if that is the case, the no-plugin case should not be the default.
Dynamically linking libfltk with libdecor is an option because, as I wrote, libdecor is present only on some extremely recent Linux versions, not yet on any released Ubuntu version. We could make this option ON by default instead of OFF because the option turns itself OFF when
libdecor-0-0.so isn't found at build time. There were also issues about bugs in libdecor that I could fix using the bundled libdecor version,
but this should be fixed soon in the libdecor gitlab repository..
