As for Fluid, I can offer to change Fluid, so it compiles as a
pure command line app as well as a GUI app. It already avoids
calling any graphics calls, but if it helps the cause, I would
implement a pure .fl to .cpp translator.
Sorry, no, that's not the point. There's no reason to do that.
All FLTK GUI apps should behave like Gtk apps do today: if the
Wayland compositor is available they should use it, otherwise they
fall back to using old X11. On Wayland systems the latter is enabled
by running the X server XWayland under Wayland.
Since *users* have the choice to use X11-only login sessions
(e.g. on Debian: "Gnome/Xorg") or use a login session with Wayland
and X server (KDE/plasma or Gnome/Wayland) the applications should
be able do decide what to use on the fly for better desktop
integration (for instance using the desktop specific window
decorations).
If we didn't supply a "hybrid" FLTK library the (Linux) distributor
would have to build the X11-only FLTK lib and all dependent
applications would have to use it and thus all FLTK applications
would be X11 only. This would also concern users that build their
own applications with the distro's FLTK package.
Alternatively the Linux distro could build two different FLTK
libraries for apps that support Wayland or those that don't but that
qould likey be a maintenance nightmare for the disto managers and
I'm afraid they wouldn't want to do that.
The fact that I mentioned fluid was only an example. Building
another command-line fluid executable would not help for the
interactive (GUI) fluid, would it?
And there are, of course (!), other FLTK applications in the Linux
distro and their GUI executables would need such hybrid support.
Comments are owned by the poster. All other content is copyright 1998-2025 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.