I'm still thoroughly confused, as there are dlload calls in the fltk code for wayland titlebars. This implies it is code to LOAD a "plugin". If it is not capable of loading a system-provided plugin that draws the titlebars then something is seriously wrong. This should not be a compile-time option if one of the options contains a dlload call.
I've a hard time understanding the meaning of this paragraph. Does it refer to the dlopen() call at line 1383 of
file <FLTK source tree>/libdecor/src/libdecor.c ?
The relationship between FLTK and libdecor is exactly the same as that with libpng or libjpeg. FLTK can be built relying on
the system to provide libpng.so or libjpeg.so. Or, if that is not desired for any reason, it can be built using a built-in version
of any of these 2 libs.
If FLTK uses its built-in copy of libdecor, the code path doesn't go to the dlopen() call mentionned above. The code path goes
always to the built-in libdecor-cairo.c which draws all window titlebars and shades.
If FLTK uses the system-provided libdecor shared lib, obviously libdecor.so determines what happens. Libdecor uses a plugin
mechanism to load, via the dlopen() call seen above, another shared lib that implements a small libdecor-defined
API and that does the titlebar drawing job. There's also a libdecor-defined mechanism to determine where libdecor.so
searches for this plugin. At present and to the best of my knowledge, no other shared lib exists than libdecor-cairo.so
which uses Cairo to draw titlebars (with a big fontsize, too big according to some).
At present, the net result is the same in terms of window titlebars because ultimately libdecor-cairo.c does
the drawing in both cases.
If the running Wayland compositor provides SSD (server-side decoration), and independently of whether the system
or the built-in libdecor versions run, no plugin is necessary because the compositor draws titlebars. That can be
put in action running FLTK with the KDE desktop.
