So (and I caution here that I only had a fairly cursory look...) what I think happens to "choose" the Wayland window decorator, with the current fltk-1.4 head is:

+ If Wayland is "not available" at runtime, OR if FLTK_BACKEND=x11 is set explicitly, then the X11 "traditional" code paths are run and decorations are provided by the X11 WM in the "normal" fashion we're all used to.

+ If Wayland is available, then:

++ If there is a *system* libdecor available, it is loaded and thereafter *it* decides what decorator plugin to run, presumably based on some system-wide setting? FWIW, I have not seen this work since the (one) system I have does not provide any system libdecor.

++ If there is no system libdecor, then we use the fltk built-in libdecor which:

+++ Will load a gtk-3 based plugin, IF libgtk-3-dev was available *when fltk was compiled* (libgtk-3 is not on my WSL2 test set-up)

+++ Else will load a Cairo based decorator plugin (since Cairo has to be available for our Wayland port anyway.)

As best I can tell, the libdecor we have "built-in" is pretty much "stock" so we do not have to work too hard to maintain it in the short term (and I assume that in the long term we expect system libdecor to become commonplace so the built-in version is less likely to be invoked?)

So: we could probably fix the cosmetic issues with the Cairo decorator plugin, but doing so would put our built-in code out-of-synch with upstream and hence be a maintenance burden. Still might be worth a stab (I say this without looking at what the decorator plugin code actually does at all!)

Or we could maybe add our own fltk-based decorator plugin, alongside the "stock" plugins, that will be called in preference to the gtk-3 or Cairo options, if the built-in libdecor is used? That way we can mess with the cosmetic aspects without altering the code from upstream at all.

But previous caveat applies - I have no clue whether that is feasible nor how hard it might be...