Towards a Wayland platform for the FLTK library ?

[Manolo]

I'd like to invite fellow FLTK developpers to discuss the possibility of
adding a Wayland platform to the FLTK library.

My proposal is in branch "wayland" of https://github.com/ManoloFLTK/fltk
See file README.Wayland.txt therein for installation instructions, including
a short list of required Debian packages.
That software should hopefully install on any Wayland-running Linux system.
It's been tested on Debian and Ubuntu.
At this time, the wayland branch is not complete but quite advanced :
all test/ and examples/ apps build and run.

Users can run xwininfo in a terminal, click on any FLTK window using this new code,
and conclude that such windows are not X11-based, in contrast to what happens with
FLTK programs for the X11 platform.

The "wayland" branch doesn't require any change to the platform-independent FLTK
code. It's expected that any FLTK app should link and mostly run as a Wayland client
program. `fltk-config --cxxflags --ldflags` can be used in makefiles as usual.
Nevertheless, X11-specific code delimited by
#if !defined(__APPLE__) && !defined(_WIN32)
... X11-specific code ...
#endif
will choke at compile-time because it will expose X11-specific function calls. Such
source code should be changed to
#if !defined(__APPLE__) && !defined(WIN32) && !defined(__WAYLAND__)
... X11-specific code ...
#endif

OpenGL and GLUT are supported as for other FLTK platforms. OpenGL3 is supported too,
but a minor source code change is required after the glewInit() call :
  GLenum err = glewInit(); // defines pters to functions of OpenGL V 1.2 and above
#ifdef __WAYLAND__
  if (err == GLEW_ERROR_NO_GLX_DISPLAY) err = GLEW_OK;
#endif
That's because glewInit() returns an error code value in the Wayland context.

The Wayland protocol accomodates either client-based or server-based window
decoration. The Gnome Wayland implementation does not contain server-based
window decoration and instead expects each client program to decorate its windows.
For that reason, the FLTK library is extended in my proposal by a library, libdecor,
(see https://gitlab.gnome.org/jadahl/libdecoration) which produces window decoration
for each FLTK client program. That library is governed by the MIT license which
allows unrestricted use, even in a commercial setting, but asks for a copy of the
license to be included in any copy of the software.

I believe it's too early at this point for you, fellow developers, to send "this
doesn't work" messages, but expect messages about attempts to install the new branch
and to build full-size FLTK apps, and about the opportunity of a Wayland FLTK platform.

Manolo

[Albrecht Schlosser]

On 6/6/21 11:40 AM Manolo wrote:
> I'd like to invite fellow FLTK developpers to discuss the possibility of
> adding a Wayland platform to the FLTK library.

We've been asked (not many, but a few, countable) times about our plans
to add Wayland support to FLTK. I was about to look how this would be
done a few times, but now I see you did it. Awesome!

> My proposal is in branch "wayland" of https://github.com/ManoloFLTK/fltk
> See file README.Wayland.txt therein for installation instructions,
> including
> a short list of required Debian packages.
> That software should hopefully install on any Wayland-running Linux
> system.
> It's been tested on Debian and Ubuntu.
> At this time, the wayland branch is not complete but quite advanced :
> all test/ and examples/ apps build and run.

I'll try that ASAP, but likely not tomorrow because I need to do some
other stuff.

> The "wayland" branch doesn't require any change to the
> platform-independent FLTK
> code. It's expected that any FLTK app should link and mostly run as a
> Wayland client
> program. `fltk-config --cxxflags --ldflags` can be used in makefiles
> as usual.
> Nevertheless, X11-specific code delimited by
> #if !defined(__APPLE__) && !defined(_WIN32)
> ... X11-specific code ...
> #endif
> will choke at compile-time because it will expose X11-specific
> function calls. Such
> source code should be changed to
> #if !defined(__APPLE__) && !defined(WIN32) && !defined(__WAYLAND__)
> ... X11-specific code ...
> #endif

Thanks for your notes. This could turn out helpful.

Regarding the code changes: WOW, that's a lot of code! The following is
just for my curiosity:

I'm seeing also that much code has been copied which might not be needed
due to the driver structure. What are your plans, will you do a mass
cleanup when the Wayland code is (almost) finished? I'm asking because
I'm concerned about duplicated code. One example seems to be timer
related code which could be reused rather than duplicated etc. etc.. I
take it that you first copied the entire driver code and are now working
on fleshing out the needed changes and what doesn't need to be changed.
Is that about correct?

> The Wayland protocol accomodates either client-based or server-based
> window
> decoration. The Gnome Wayland implementation does not contain server-based
> window decoration and instead expects each client program to decorate
> its windows.
> For that reason, the FLTK library is extended in my proposal by a
> library, libdecor,
> (see https://gitlab.gnome.org/jadahl/libdecoration) which produces
> window decoration
> for each FLTK client program. That library is governed by the MIT
> license which
> allows unrestricted use, even in a commercial setting, but asks for a
> copy of the
> license to be included in any copy of the software.

Interesting. I see that you added the library to the FLTK repo. Are
there plans to (finally) bundle it or would we take it as a prerequisite
to be installed by developers? Generally I'd prefer the latter, but I
don't know how well it is supported by (Linux) distros. Can you share
your thoughts about this?

> I believe it's too early at this point for you, fellow developers, to
> send "this
> doesn't work" messages, but expect messages about attempts to install
> the new branch
> and to build full-size FLTK apps, and about the opportunity of a
> Wayland FLTK platform.

Looking forward to install and test! I'll let you know about my results
and hopefully others will try as well.

[Bill Spitzak]

This all seems like a good idea.

Using that existing libdecor code is probably an ok start, but I would like to see it done reusing as much functionality from FLTK as possible. It does look like that code is pretty minimal (ie it does not link with GTK) so that is a relief. In the end the FlWindow object would do all of this.

I assume this is using Cairo for rendering? You should, as that is what the titlebar code is using. The Cairo code needs to be fixed up so it is an acceptable backend for FLTK, and use the same cairo api in both the X11 and Wayland versions.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/2f54295b-a4d4-ecb2-c62b-14668d0fd70f%40online.de.

[Manolo]

Le dimanche 6 juin 2021 à 21:03:01 UTC+2, Albrecht Schlosser a écrit :

I'll try that ASAP, but likely not tomorrow because I need to do some
other stuff.

I'm looking forward to your feedback.

Regarding the code changes: WOW, that's a lot of code!

Yes. Everything related to windows, drawing, events, keyboard, pointers, cursors

requires complete rewriting.

The following is just for my curiosity:

I'm seeing also that much code has been copied which might not be needed
due to the driver structure. What are your plans, will you do a mass
cleanup when the Wayland code is (almost) finished? I'm asking because
I'm concerned about duplicated code. One example seems to be timer
related code which could be reused rather than duplicated etc. etc.. I
take it that you first copied the entire driver code and are now working
on fleshing out the needed changes and what doesn't need to be changed.
Is that about correct?

Yes. I've focused till now on building a running platform. Shared code

between X11 and Wayland platforms could be put in an Fl_Linux_System_Driver

from which Fl_Wayland_System_Driver and Fl_X11_System_Driver could derive.

Interesting. I see that you added the library to the FLTK repo. Are
there plans to (finally) bundle it or would we take it as a prerequisite
to be installed by developers? Generally I'd prefer the latter, but I
don't know how well it is supported by (Linux) distros. Can you share
your thoughts about this?

libdecor is only at version 0.1 now, so it's not yet in Debian Linux distros.

That's why I propose to bundle it in FLTK as we do with libz, libpng, libjpeg and nanosvg.

Its author, Jonas Ådahl, is also one of the two maintainers of the xdg-shell stable

Wayland protocol in charge of creating Wayland desktop windows

(see https://github.com/wayland-project/wayland-protocols/tree/main/stable/xdg-shell).

Thus, libdecor is apparently code from the heart of the Wayland project.

Alternatively, if another library is available to decorate FLTK Wayland windows, I'm ready

to examine it. My first concern was that libdecor's license should be compatible with FLTK's.

[Manolo]

Le lundi 7 juin 2021 à 00:03:51 UTC+2, spi...@gmail.com a écrit :

This all seems like a good idea.

Thanks.

Using that existing libdecor code is probably an ok start, but I would like to see it done reusing as much functionality from FLTK as possible. It does look like that code is pretty minimal (ie it does not link with GTK) so that is a relief. In the end the FlWindow object would do all of this.

libdecor is used both by the FLTK library and by a component of the Wayland system itself (the compositor I believe).

That's why it's necessarily a shared library which plugs into the compositor.

That also makes it a software requiring deep Wayland knowledge.

Thus, using an existing library is an attractive solution.

I assume this is using Cairo for rendering? You should, as that is what the titlebar code is using. The Cairo code needs to be fixed up so it is an acceptable backend for FLTK, and use the same cairo api in both the X11 and Wayland versions.

Yes. All drawing is done using Cairo, and Pango for text.

Thus, there's now a complete Cairo+Pango-based graphics driver in he Wayland branch,

which could be used by the X11 platform too. That would bring antialiasing to the X11 platform.

[Albrecht Schlosser]

On 6/7/21 8:44 AM Manolo wrote:

Le dimanche 6 juin 2021 à 21:03:01 UTC+2, Albrecht Schlosser a écrit :

I'll try that ASAP, but likely not tomorrow because I need to do some
other stuff.

I'm looking forward to your feedback.

Well, not really much feedback, I just played with the demo programs. I'm really impressed how well everything is already. Great job!

I used a VM (Ubuntu) where I had installed Wayland some time ago for tests. Almost all programs run fine and smoothly.


Some observations:

The "graphics speed test" (test/unittests - schemes test - resize window) works *MUCH* faster than my tests with Windows/gdi+ in a VM on my Linux Notebook (supposedly a very similar VM config).

test/doublebuffer runs "faster than ever seen" and there's no noticeable difference between single and double buffer which is what I expected. Manolo, there is no difference, right?

test/glpuzzle does "funny things" (TM) if you let the game rotate (drag the mouse and see). Borders disappear, sometime there's a see-through effect.

Not all cursors appear as they should (test/cursor).

Screen scaling (ctrl/+/-/0) doesn't seem to work yet. Maybe in GL windows though (not sure). I've seen some weird effects.

test/resize-example* programs seem all to crash like this:
$ ./resize-example1
makeWindow:0x22499c0 wl_compositor_create_surface=0x2253bc0 scale=1
Segmentation fault (core dumped)


Oh, and one thing I did not expect:

  ./configure --enable-wayland --enable-cairo

doesn't work together. There are compilation errors (I don't remember exactly, something about fl_gc and unsupported platform; I could reproduce it but I'd need to reconfigure the build). I take it this is just the platform tests in some header files, but anyway, that's not important at all.

Manolo, well done! It's awesome to see that FLTK can work with Wayland.

Conclusion: Using Cairo doesn't seem to be that slow in conjunction with Wayland which uses (AFAICT) memory mapped buffers for communication (rather than sockets or network connections like X11 does). How does "local X11" communicate? Anybody?

Manolo, would you like me to add CMake support? I'd like to help if I can.

[Albrecht Schlosser]

On 6/7/21 9:03 PM Albrecht Schlosser wrote:
> test/glpuzzle does "funny things" (TM) if you let the game rotate
> (drag the mouse and see). Borders disappear, sometime there's a
> see-through effect.

Screenshot attached.

[Bill Spitzak]

Looks like the z buffering got disabled somehow

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/eccc8fa7-ccb8-4882-5de4-ca59d6f847df%40online.de.

[Greg Ercolano]

On 6/7/21 12:03 PM, Albrecht Schlosser wrote:

On 6/7/21 8:44 AM Manolo wrote:

Le dimanche 6 juin 2021 à 21:03:01 UTC+2, Albrecht Schlosser a écrit :

I'll try that ASAP, but likely not tomorrow because I need to do some
other stuff.

I'm looking forward to your feedback.

Well, not really much feedback, I just played with the demo programs. I'm really impressed how well everything is already. Great job!

    I don't have wayland here, but this sounds super impressive.
    Way to go Manolo, you're amazing!

Conclusion: Using Cairo doesn't seem to be that slow in conjunction with Wayland which uses (AFAICT) memory mapped buffers for communication (rather than sockets or network connections like X11 does). How does "local X11" communicate? Anybody?

    Pretty sure X11 when used locally now uses IPC + shared memory when running locally,
    unix domain sockets instead of the overhead of TCP/networking.

    I have a vague memory that Silicon Graphics donated some code to X11 to improve the speed
    of rendering under X11, but I can't remember if it was specific to OpenGL (GLX), or included X11
    as a whole (Xsgi).

    MIT was behind a lot of improvements too, I don't remember the history very well.

    There may be more details burried in here:

    [1] https://en.wikipedia.org/wiki/Xsgi
    [2] https://en.wikipedia.org/wiki/X_Window_System

[Bill Spitzak]

I think there is some mistakes in current FLTK, in particular the "Driver" api, which uses virtual functions for no reason whatsoever as the called code is chosen at compile time, and as seen here the design makes it really difficult to share code. Would prefer to use #if statements like they are supposed to. I don't consider the current design readable or maintainable. I may be missing some function of Driver where more than one can be used, please correct me if I am wrong.

The "Device" is somewhat useful as it allows you to draw widgets in GL windows. I think there is also an attempt to allow it to print, though I am unclear if it is actually possible to use it for that and if anybody has done so. I still feel the number of virtual functions on it is excessive.

It sounds like Cairo is nowhere near as slow as others have claimed. It would be great to get a real working implementation that can be used both by this and X11. I think all transformations have to be done by the calling code, as there is a need to adjust all paths for fill and stroke to remove antialiasing on horizontal and vertical lines, and allow 1-pixel lines to be usable. This indicates to me that transforms at least can be removed from the Device virtual functions.

Read through the libdecor code and it appears to be drawing everything directly. There is a "plugin", perhaps with the intention that the style of the window borders can change by changing the plugin, but I don't agree with this as the api to the plugin is going to swiftly grow to a baroque monstrosity, just like every other attempt to control the borders. There was a good reason Wayland wanted CSD. I personally do not see any problem with drawing the window borders ourselves, any complaint that they look different is IMHO not logical if the difference in appearance of every other widget is considered acceptable. Also not using this library will mean a single Wayland surface can be used, instead of two.

[Albrecht Schlosser]

On 6/7/21 10:01 PM Bill Spitzak wrote:
> I think there is some mistakes in current FLTK, in particular the
> "Driver" api, which uses virtual functions for no reason whatsoever as
> the called code is chosen at compile time, and as seen here the design
> makes it really difficult to share code. Would prefer to use #if
> statements like they are supposed to. I don't consider the current
> design readable or maintainable. I may be missing some function of
> Driver where more than one can be used, please correct me if I am wrong.

It's true that the selection of the standard display and system driver
is done at library build time. However, the driver design was chosen to
get rid of the unmaintainable #ifdef stuff. Currently there should only
be #if statements to differentiate compilers and/or options (for
instance Xft vs Pango, VS (MSVC) vs. GNU, etc.). You can really use more
than one graphics driver (although still only one at a time) for
printing (Fl_Printer), copying to the clipboard (Fl_Copy_Surface),
Fl_PostScript (files) and Fl_Offscreen. This is all done by changing the
driver(s) on the fly. I'm using this in some applications. For an
example see test/device.cxx (the code may be historically grown and not
as clean as possible but it shows the options).

Regarding the driver selection at build time: I would also like to see
an option to combine two or more "platforms" in one executable program,
i.e. in one FLTK library. The idea is to decide at program startup which
"driver" we want to use, for instance X11 for remote display, macOS
native display driver, or (in the future) Wayland or Cairo. An
environment variable or commandline switch would then decide at program
startup which device/driver to use on platforms that allow different
connections. This should not be difficult to achieve...

> The "Device" is somewhat useful as it allows you to draw widgets in GL
> windows. I think there is also an attempt to allow it to print, though
> I am unclear if it is actually possible to use it for that and if
> anybody has done so. I still feel the number of virtual functions on
> it is excessive.

Yes, it is used for printing and even more stuff (see above). And it
works pretty well. A recent extension is to "draw" to an Fl_SVG_Surface
which eventually outputs real SVG files.

The number of virtual functions may be excessive in some parts (it's the
'.0' version), I'm sure there's room for improvement.

> It sounds like Cairo is nowhere near as slow as others have claimed.
> It would be great to get a real working implementation that can be
> used both by this and X11.

... which may be a logical step when the Wayland platform is done as
Manolo wrote already. Experience with Wayland is a good first step
(let's do one step after the other) before we go to the next (Cairo)
device. I could also have imagined to create a Cairo driver on X11
first, before Wayland, but now Wayland won.

> I think all transformations have to be done by the calling code, as
> there is a need to adjust all paths for fill and stroke to remove
> antialiasing on horizontal and vertical lines, and allow 1-pixel lines
> to be usable. This indicates to me that transforms at least can be
> removed from the Device virtual functions.

I'm not sure what this means.

> Read through the libdecor code and it appears to be drawing everything
> directly. There is a "plugin", perhaps with the intention that the
> style of the window borders can change by changing the plugin, but I
> don't agree with this as the api to the plugin is going to swiftly
> grow to a baroque monstrosity, just like every other attempt to
> control the borders.

ISTR that the "plugin" is really for defining other border and
decoration styles. I think I read about this in the README files of
libdecor in connection with setting up the demo program or something
like that.

> There was a good reason Wayland wanted CSD.

What is CSD? Client Server XXX ???

> I personally do not see any problem with drawing the window borders
> ourselves, any complaint that they look different is IMHO not logical
> if the difference in appearance of every other widget is considered
> acceptable. Also not using this library will mean a single Wayland
> surface can be used, instead of two.

I agree that this would be logical. I can't speak for Manolo but I think
using a library was considered easier than writing everything from
scratch. Would your (Bill's) old flwm code be helpful in doing window
decorations and stuff? Should be take a look at it? It's still available
somewhere...

[Greg Ercolano]

On 6/7/21 1:51 PM, Albrecht Schlosser wrote:

There was a good reason Wayland wanted CSD.

What is CSD? Client Server XXX ???

Pretty sure that's "Client Side Decorations"
https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/

[Albrecht Schlosser]

Oh, yes, that makes sense. And thanks for the link. Reading ...

[Ian MacArthur]

On 7 Jun 2021, at 20:03, Albrecht Schlosser wrote:
>
> I used a VM (Ubuntu) where I had installed Wayland some time ago for tests. Almost all programs run fine and smoothly.

> test/glpuzzle does "funny things" (TM) if you let the game rotate (drag the mouse and see). Borders disappear, sometime there's a see-through effect.

I would not preclude the possibility that the VM is involved in that misbehaviour - I was doing some testing on (IIRC Fedora) VM and the GL rendering was a bit glitchy.
The same binary running native on another machine was fine.
(The Fedora VM was because the end-user was on RHEL-something-or-other and I was working on debian, so I just wanted to see what happened on something more RHEL-like. The GL misbehaviour caused me some distress. But apparently the end-user did not see that. so I guess it was OK on their machines...)

[Bill Spitzak]

What I meant for Device was to replace it with code like this:

#if X11

#include <X11code.C>

#elif Windows

#include <Windowscode.C>

...

This is what was attempted in FLTK 2.

This should result in something exactly as maintainable as Device virtual functions, but there is no overhead and mistakes show up as unlinkable code.

It may be plausible to use Device to make a program that works on different devices but a lot of stuff, in particular timeouts and polling, are in it and there is just no way you can switch that to a different one.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/60E28EC3-E2DE-4B98-B0B9-C8AADA9CE3C3%40gmail.com.

[Ian MacArthur]

On 7 Jun 2021, at 21:01, Bill Spitzak wrote:
>
> I think there is some mistakes in current FLTK, in particular the "Driver" api, which uses virtual functions for no reason whatsoever as the called code is chosen at compile time, and as seen here the design makes it really difficult to share code. Would prefer to use #if statements like they are supposed to. I don't consider the current design readable or maintainable. I may be missing some function of Driver where more than one can be used, please correct me if I am wrong.

I think the *idea* (if not yet the actuality) of this is that at some point it stops being a compile time option and becomes more of a runtime option: indeed X11 vs. Wayland (or GDI vs. GDI+) might be ideal cases where that might come into play... But not quite yet.

> The "Device" is somewhat useful as it allows you to draw widgets in GL windows. I think there is also an attempt to allow it to print, though I am unclear if it is actually possible to use it for that and if anybody has done so. I still feel the number of virtual functions on it is excessive.

The printing support works pretty well, I’ve used it a fair bit and been quite pleased with the outcomes...
I have no opinion on what constitutes “too many” virtual functions. (Though, if the compiler can resolve the types statically, and often it can, then the virtualisation may be “free” at that point anyway. Which doesn’t help readability, I concede, but it’s helpful for runtimes.)

> It sounds like Cairo is nowhere near as slow as others have claimed.

It can be - just when you think it’s all going so well, it sneaks around and sticks you from behind!
There’s just “some things” on “some machines” where it suddenly runs like treacle; and I’m not even sure if it is the *same* things in each case...

[Greg Ercolano]

On 6/7/21 2:26 PM, Bill Spitzak wrote:

What I meant for Device was to replace it with code like this:

#if X11

#include <X11code.C>

#elif Windows

#include <Windowscode.C>

I had used that technique in the native file chooser, but it was changed.

That technique was generally recommended IIRC in an old O'Reilly book
on multiple platform code management I've had for decades now.

[Albrecht Schlosser]

And that's exactly the point. It's decades old!

This type of code is not at all scalable (by platform). You can see this in our old (1.3) code that has exactly that, with the (above missing) #else case. It was usually something like:

#ifdef _WIN32 // Windows
...
#elif defined(__APPLE__) // macOS
...
#else // X11
...
#endif

which *implied* that the #else case is Unix/Linux/X11. This also precluded (basically) using X11 on macOS (which is definitely possible). Whenever you add another device/platform/driver/backend (call it as you like) you need to add yet another #elif case at *uncountable* places. That's the nightmare we got rid of by moving to the "driver" structure.

This driver structure is unlimited extensible by adding "just another class" with selected virtual methods that need to be overridden (sharing the code of not overridden methods). This is the ideal case. You can see it in the drawing code of the Wayland graphics driver which reuses existing Cairo driver code.

In practice, I admit, this is not as easy as it sounds. It tends to "copy and paste" code from one driver to another one, fix the "few statements" that need to be replaced, and then you end up with lots of duplicated code that needs to be maintained (mainly in the system specific parts). That's bad and not intended. The "correct" way needs a finer granularity of functions (virtual methods) and a good design. This is harder to achieve but possible (and that's why I asked Manolo about the current status of his edits and his plans for completion).

Example: We have three totally different ways to implement timer related code: Unix/Linux (Posix), Windows, and macOS. This led to incompatibilities (macOS) and lack of accuracy (Windows). I don't want to write about more details here, but I believe that a better implementation would be doable in platform-agnostic code with only minor system specific functions (here: virtual driver methods). Copying the Linux/Unix/Posix code to "Wayland drivers" (which has been done during the development) is NOT the final solution (hopefully). That's only one example...

[Bill Spitzak]

FLTK2 did change it so there was not a fallback in the if statements, making it easy to rearrange them and to make it clear when things were for X11. I certainly agree this should be done here too.

What I was saying is that the contents of the if statements were #include statements. This put each machine's code in it's own file, without any overhead of virtual functions.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/13c59d6a-ef8b-298b-c932-e3858c8803dc%40online.de.

[Manolo]

Le lundi 7 juin 2021 à 21:03:45 UTC+2, Albrecht Schlosser a écrit :

test/doublebuffer runs "faster than ever seen" and there's no noticeable difference between single and double buffer which is what I expected. Manolo, there is no difference, right?

Yes. There's no such thing as a Wayland single window because it's not possible with Wayland to draw in the window. All drawing goes to a buffer,

and then this buffer is "committed" to Wayland. The two windows of test/doublebuffer follow exactly the same code.

test/glpuzzle does "funny things" (TM) if you let the game rotate (drag the mouse and see). Borders disappear, sometime there's a see-through effect.

Bill's hint below about the z buffer is probably the way to look to fix that. Help needed. I dont know GL.

Not all cursors appear as they should (test/cursor).

Yes, that happens with some Ubuntu themes but not all, and not with Debian, where all cursor shapes work.

Cursors are searched in a system folder and some shapes are absent for some Ubuntu themes. Who knows why?

Screen scaling (ctrl/+/-/0) doesn't seem to work yet. Maybe in GL windows though (not sure). I've seen some weird effects.

Wayland was born when HighDPI existed, so it contains natively a way to handle HighDPI in the form of an integer scale whose value

grows with pixel density.  FLTK apps follow this scaling without need for change nor ctrl/+/.

Go to Settings -> Display -> Scale and set it to 200% or 300 % on a large display, you'll see FLTK Wayland apps follow the change.

They're not adaptive while running yet, though.

 

test/resize-example* programs seem all to crash like this:
$ ./resize-example1
makeWindow:0x22499c0 wl_compositor_create_surface=0x2253bc0 scale=1
Segmentation fault (core dumped)

I'll look into that. I had not tried any of these test apps.

Oh, and one thing I did not expect:

  ./configure --enable-wayland --enable-cairo

doesn't work together. There are compilation errors (I don't remember exactly, something about fl_gc and unsupported platform; I could reproduce it but I'd need to reconfigure the build). I take it this is just the platform tests in some header files, but anyway, that's not important at all.

I had not tried that yet.

Manolo, well done! It's awesome to see that FLTK can work with Wayland.

Conclusion: Using Cairo doesn't seem to be that slow in conjunction with Wayland which uses (AFAICT) memory mapped buffers for communication (rather than sockets or network connections like X11 does). How does "local X11" communicate? Anybody?

I have organized the code with 2 buffers of the same size for each window and subwindow:

- a drawing buffer where all drawing is made by Cairo. It's an array of bytes.

- a window buffer where the drawing buffer is copied after each drawing round. It has a Wayland-defined type (struct wl_buffer)

and contains memory shared with the compositor. When appropriate, that buffer gets 'committed' which means that Wayland

makes its content appear in the window.

Each window contains also two boolean state variables wl_buffer_ready and draw_buffer_needs_commit :

- draw_buffer_needs_commit becomes true after each drawing round and false after the drawing buffer has been copied to the window buffer;

- wl_buffer_ready becomes true when Wayland informs the program that the window buffer is ready to be loaded and committed,

and false when commit begins.

This way, only proper window content ever gets displayed, and Cairo can continue to draw when Wayland is not yet ready to display.
This synchronization is conspicuous with test/mandelbrot at maximized window size.

 

Manolo, would you like me to add CMake support? I'd like to help if I can.

Yes I do. Many thanks.

But I believe we should first decide whether we want to include Wayland in the FLTK repo

and whether we do that as a new branch, or in the main branch, just like Android or Pico.

I would also appreciate feedback about use on a native Linux system (as opposed to a virtual machine).

[Manolo]

Le lundi 7 juin 2021 à 22:02:00 UTC+2, spi...@gmail.com a écrit :

Read through the libdecor code and it appears to be drawing everything directly. There is a "plugin", perhaps with the intention that the style of the window borders can change by changing the plugin, but I don't agree with this as the api to the plugin is going to swiftly grow to a baroque monstrosity, just like every other attempt to control the borders. There was a good reason Wayland wanted CSD. I personally do not see any problem with drawing the window borders ourselves, any complaint that they look different is IMHO not logical if the difference in appearance of every other widget is considered acceptable. Also not using this library will mean a single Wayland surface can be used, instead of two.

Here's an investigation with gdb on program test/hello searching for what context calls static function draw_title_text()

from libdecor's src/plugin/cairo/libdecor-cairo.c which draws the text of window titlebars :

1) When a window is first created, libfltk code calls libdecor code which draws the window title :

#0  0x00007ffff7d3039f in draw_title_text ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#1  0x00007ffff7d30c25 in draw_component_content ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#2  0x00007ffff7d319c0 in draw_border_component ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#3  0x00007ffff7d31b89 in draw_title_bar ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#4  0x00007ffff7d31c5d in draw_decoration ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#5  0x00007ffff7d31ee3 in libdecor_plugin_cairo_frame_commit ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#6  0x00007ffff7d2c6c0 in libdecor_frame_commit ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#7  0x000000000043ab8a in handle_configure(libdecor_frame*, libdecor_configuration*, void*) (frame=0x4d5c00, configuration=0x533490, user_data=0x4c1380)
    at drivers/Wayland/Fl_Wayland_Window_Driver.cxx:747
 

2) Each time the window is deactivated or activated, its titlebar gets redrawn.
This is done by libfltk calling libwayland-client.so which calls libffi.so (what is it?)

which calls libdecor-0.1.so to draw the title :

#0  0x00007ffff7d3039f in draw_title_text ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#1  0x00007ffff7d30c25 in draw_component_content ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#2  0x00007ffff7d319c0 in draw_border_component ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#3  0x00007ffff7d31b89 in draw_title_bar ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#4  0x00007ffff7d31c5d in draw_decoration ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#5  0x00007ffff7d32d72 in synthesize_pointer_enter ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#6  0x00007ffff7d32ecf in pointer_enter ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#7  0x00007ffff7374d1d in  () at /lib/x86_64-linux-gnu/libffi.so.7
#8  0x00007ffff7374289 in  () at /lib/x86_64-linux-gnu/libffi.so.7
#9  0x00007ffff7db22d2 in  () at /lib/x86_64-linux-gnu/libwayland-client.so.0
#10 0x00007ffff7dae97a in  () at /lib/x86_64-linux-gnu/libwayland-client.so.0
#11 0x00007ffff7db003c in wl_display_dispatch_queue_pending ()
    at /lib/x86_64-linux-gnu/libwayland-client.so.0
#12 0x0000000000436940 in fd_callback(int, wl_display*)
    (unused=3, display=0x4b45f0)
    at drivers/Wayland/Fl_Wayland_Screen_Driver.cxx:925
#13 0x000000000044148c in Fl_Wayland_Screen_Driver::poll_or_select_with_delay(double) (this=0x4b43a0, time_to_wait=1e+20) at drivers/Wayland/Fl_wayland.cxx:225
#14 0x00000000004371cc in Fl_Wayland_Screen_Driver::wait(double)
    (this=0x4b43a0, time_to_wait=1e+20)
    at drivers/Wayland/Fl_Wayland_Screen_Driver.cxx:1146
#15 0x0000000000407aa6 in Fl::wait(double) (time_to_wait=1e+20) at Fl.cxx:449
#16 0x0000000000407ad3 in Fl::run() () at Fl.cxx:469

This, I interpret as showing that a shared library plugin is necessary for libdecor. Am I wrong?

FLTK could stop pulling in future libdecor updates when we would feel it's becoming

'a baroque monstrosity'.

I understand that FLTK could do CSD drawing a custom titlebar in the same surface as the window main area.

I see this path has not been followed by libdecor. May be it's because libdecor wants to be compatible

with desktops (and I believe KDE is one) that provide server-side decoration (SSD).

[Manolo]

Test apps resize-example* should run now on Wayland after git pull.

[Albrecht Schlosser]

On 6/8/21 9:30 AM Manolo wrote:

Here's an investigation with gdb on program test/hello searching for what context calls static function draw_title_text()

from libdecor's src/plugin/cairo/libdecor-cairo.c which draws the text of window titlebars :

1) When a window is first created, libfltk code calls libdecor code which draws the window title :

#0  ... (call stack elided)
 

2) Each time the window is deactivated or activated, its titlebar gets redrawn.
This is done by libfltk calling libwayland-client.so which calls libffi.so (what is it?)

FYI, from the docs of libffi:
"The libffi library provides a portable, high level programming interface to various calling conventions. This allows a programmer to call any function specified by a call interface description at run time. FFI stands for Foreign Function Interface."
https://github.com/libffi/libffi

This is obviously used to call plugins in a portable way.

which calls libdecor-0.1.so to draw the title :

#0  ...

This, I interpret as showing that a shared library plugin is necessary for libdecor. Am I wrong?

It seems like plugins are the used to implement actual decorations/themes:

From the docs (README) of libdecor:
"... libdecor will look for plugins in the target directory of the installation. Therefore, when running the demos directly from the build directory, no plugins will be found and the fallback plugin without any decorations will be used."
https://gitlab.gnome.org/jadahl/libdecoration

FLTK could stop pulling in future libdecor updates when we would feel it's becoming

'a baroque monstrosity'.

I understand that FLTK could do CSD drawing a custom titlebar in the same surface as the window main area.

I see this path has not been followed by libdecor. May be it's because libdecor wants to be compatible

with desktops (and I believe KDE is one) that provide server-side decoration (SSD).

Whatever the reasoning behing libdecor is and notwithstanding the option to draw only into one buffer I think that we can independently investigate if it makes sense for us to draw the decorations ourselves. I do also think that an option to not draw decorations at all (particularly the title bar) would be useful so programs can draw their own "header bar" if they are modified to do so. But this is a future issue and not necessary for functional evaluation of the Wayland port.

[Albrecht Schlosser]

On 6/7/21 11:21 PM Ian MacArthur wrote:
> On 7 Jun 2021, at 20:03, Albrecht Schlosser wrote:
>> test/glpuzzle does "funny things" (TM) if you let the game rotate (drag the mouse and see). Borders disappear, sometime there's a see-through effect.
> I would not preclude the possibility that the VM is involved in that misbehaviour - I was doing some testing on (IIRC Fedora) VM and the GL rendering was a bit glitchy.

That's a valid point, I've also seen VM setups that had issues with
OpenGL in the past.

But I think we can rule this out here. I tried both the X11 version and
the Wayland version of glpuzzle side by side on the Ubuntu VM and the
X11 version works well. There must be something different in the Wayland
version, see attached screenshot with a similar view of the scene.

I will also try to use another setup with Wayland on a bare metal Linux
system later.

[Albrecht Schlosser]

On 6/8/21 12:05 PM Manolo wrote:
> Test apps resize-example* should run now on Wayland after git pull.

Yep, confirmed. Thanks.

[Albrecht Schlosser]

On 6/8/21 8:52 AM Manolo wrote:

Le lundi 7 juin 2021 à 21:03:45 UTC+2, Albrecht Schlosser a écrit :

test/doublebuffer runs "faster than ever seen" and there's no noticeable difference between single and double buffer which is what I expected. Manolo, there is no difference, right?

Yes. There's no such thing as a Wayland single window because it's not possible with Wayland to draw in the window. All drawing goes to a buffer, and then this buffer is "committed" to Wayland. The two windows of test/doublebuffer follow exactly the same code.

Thanks, that's exactly what I had expected. Wayland is always "double buffered" and, from a user's point of view, Fl_Window will be functional identical to Fl_Double_Window on the Wayland platform.

test/glpuzzle does "funny things" (TM) if you let the game rotate (drag the mouse and see). Borders disappear, sometime there's a see-through effect.

Bill's hint below about the z buffer is probably the way to look to fix that. Help needed. I dont know GL.

Neither do I, but my further test (see another message) seems to indicate that the wrong behavior is Wayland and not VM specific. Do you see this misbehavior too?

Not all cursors appear as they should (test/cursor).

Yes, that happens with some Ubuntu themes but not all, and not with Debian, where all cursor shapes work.

Cursors are searched in a system folder and some shapes are absent for some Ubuntu themes. Who knows why?

Hmm, that's a pity. I don't know but I'm sure we can find a way to make our own cursors as a fallback if necessary.

Screen scaling (ctrl/+/-/0) doesn't seem to work yet. Maybe in GL windows though (not sure). I've seen some weird effects.

FTR, see attached image running "$ FLTK_SCALING_FACTOR=1.3 test/fullscreen" with both X11 (left side) and wayland (right image).

Wayland was born when HighDPI existed, so it contains natively a way to handle HighDPI in the form of an integer scale whose value

grows with pixel density.  FLTK apps follow this scaling without need for change nor ctrl/+/.

FLTK apps don't seem to honor the environment variable FLTK_SCALING_FACTOR completely (see image). The scaling factor is recognized though (scale: 1.30) in both cases.

Go to Settings -> Display -> Scale and set it to 200% or 300 % on a large display, you'll see FLTK Wayland apps follow the change.

I can't find such a setting in my Ubuntu VM. I only have "Resolution" and "Fractional Scaling" (see screenshot).

They're not adaptive while running yet, though.

Do you think you can implement this too? ctrl/+/-/0 is IMHO an essential feature independent of the system/display setting.

Manolo, would you like me to add CMake support? I'd like to help if I can.

Yes I do. Many thanks.

But I believe we should first decide whether we want to include Wayland in the FLTK repo

and whether we do that as a new branch, or in the main branch, just like Android or Pico.

I will give it a try anyway. For me it's a valuable addition even for the testing phase, and I'm confident that we will add Wayland support sooner or later -- unless we find that it's not going to work which doesn't seem likely now, thanks to your awesome work so far.

I think, as long as you're developing the Wayland port it's okay to have it in your own fork. You could even create a PR so we (devs only) can also commit directly to your fork (if you like).

My suggestion is to rebase the branch from time to time so we are always in sync with the upstream master branch (please don't merge the master into your wayland branch though, this will only make things more difficult). I do also propose that we'll rebase and squash the wayland branch before the final merge to avoid having too many intermediate file versions in the main FLTK repository.

I would also appreciate feedback about use on a native Linux system (as opposed to a virtual machine).

I'll try to test on my bare metal Linux when time permits. I think I did already install 'weston' so I could maybe run it directly on my notebook. If that's not possible I can use another Debian Buster system on my ancient MacMini. ;-)

[Albrecht Schlosser]

On 6/8/21 2:30 PM Albrecht Schlosser wrote:

On 6/8/21 8:52 AM Manolo wrote:

I would also appreciate feedback about use on a native Linux system (as opposed to a virtual machine).

My test results follow...

I'll try to test on my bare metal Linux when time permits. I think I did already install 'weston' so I could maybe run it directly on my notebook.

FYI, from Wikipedia: "Weston is the reference implementation of a Wayland compositor also developed by the Wayland project."
https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#WESTON

Since I had already installed weston (Ubuntu package: weston, maybe together with some more '-dev' packages) I could build the FLTK wayland branch w/o installing anything else on my Linux Mint 20 system (which is based on Ubuntu 20.04 LTS).

I launched 'weston' which opened its own desktop window. All (FLTK) Wayland programs connect to this weston instance and show their windows on this weston desktop. Screenshot 'weston-wayland-x11.png' shows the weston desktop in the background, two FLTK Wayland programs on the left hand side, and two FLTK X11 programs on the right hand side in front, overlapping the weston window. The glpuzzle demo under Wayland exhibits the know issues.

For devs who can't test themselves I'm attaching the screenshot 'weston-fullscreen.png' so you can get an impression.

@Manolo: I showed intentionally the cursor FL_CURSOR_SE that (IIRC) did not show properly in my first Ubuntu test which seems to confirm what you wrote about cursor images.

Screenshot 'lines.png' shows a zoomed image of 'test/unittests:drawing lines' with pretty anti-aliased lines.


I also found a new bug which is described in attached 'wayland-error-in-client.txt': the first part shows the info displayed when running the program and clicking on 'fl_show_colormap()'. The program window disappears and lines 3-4 show an error message.

The "Error message in weston" is logged by the running 'weston' instance and may be interesting as well.

After this the running 'test/color_chooser' uses 100% CPU time and needs to be stopped with ctrl/c.


Other observations in this constellation with weston:

- mouse clicks seemed sometimes not to react immediately (maybe flushing the display was missing), but then it worked again flawlessly

- this also affected window resizing with the mouse (sometimes, not always)

- test/offscreen seemed to hang after the start, but after clicking on another window (multiple times IIRC) it seemed to work as expected

As I wrote above, these are observations running on my bare metal Linux Mint with weston. It is possible that the interaction with weston caused some of these effects. More tests with a "Wayland desktop system" like Ubuntu are needed.

[Albrecht Schlosser]

On 6/8/21 5:03 PM Albrecht Schlosser wrote:
>
> Other observations in this constellation with weston:
>
> - mouse clicks seemed sometimes not to react immediately (maybe
> flushing the display was missing), but then it worked again flawlessly
>
> - this also affected window resizing with the mouse (sometimes, not
> always)
>
> - test/offscreen seemed to hang after the start, but after clicking on
> another window (multiple times IIRC) it seemed to work as expected
>
> As I wrote above, these are observations running on my bare metal
> Linux Mint with weston. It is possible that the interaction with
> weston caused some of these effects. More tests with a "Wayland
> desktop system" like Ubuntu are needed.

I tested two more constellations with Weston in my Ubuntu VM:

(1) I logged in as a "normal" Ubuntu system running the Ubuntu Desktop,
installed weston, and launched weston from the terminal. This opened a
"Weston Desktop" as previously on my Linux Mint system.

(2) After I had installed Weston on the Ubuntu system I looged out and
logged in again. This time I had a new choice to use "Weston" as the
desktop system. I selected this and logged in.

In both constellations the "Compositor" is Weston. Both constellations
showed the same issues as described above, I'd say even worse than on my
native Linux system: button clicks not visible, need to click on another
window (change window focus), programs controlled by timers like
test/offscreen and test/blocks don't update their windows etc..

The conclusion is that the combination of FLTK + Weston is less reliable
(in other words: almost not usable) in the current implementation. Note
that I'm not saying it's FLTK's fault - I'm only saying that this
combination doesn't work well, whereas the Ubuntu compositor (whatever
it's called) which provides the "Ubuntu Wayland" desktop appears to work
much better with FLTK (or vice versa).

Since Weston is the "reference implementation" it would be interesting
to find out if our (FLTK Wayland) implementation lacks some
(communication) details or if Weston is (maybe) "not ready for
production use". Tests with other applications running under Weston
might shed some light on this question.

That said, I'm really impressed how well the FLTK Wayland port works
already. Did I say this already? Great job, Manolo!

[Manolo]

Le mardi 8 juin 2021 à 14:30:06 UTC+2, Albrecht Schlosser a écrit :

Go to Settings -> Display -> Scale and set it to 200% or 300 % on a large display, you'll see FLTK Wayland apps follow the change.

I can't find such a setting in my Ubuntu VM. I only have "Resolution" and "Fractional Scaling" (see screenshot).

That's because enough pixels are required for the "Scale" button to appear. I see that 1440x900 is not enough,

whereas 1920x1200 has "Scale" appear.

[Manolo]

Le mardi 8 juin 2021 à 14:30:06 UTC+2, Albrecht Schlosser a écrit :

FLTK apps don't seem to honor the environment variable FLTK_SCALING_FACTOR completely (see image). The scaling factor is recognized though (scale: 1.30) in both cases.

FLTK on Wayland will now ignore  FLTK_SCALING_FACTOR until support for ctrl/+/-/0/ is programmed.
It supports Wayland's own scaling factor as explained before.

[Manolo]

The problem with glpuzzle should be fixed after git pull.

[Manolo]

Building with both Wayland and Cairo support will work after git pull.

[Albrecht Schlosser]

On Am 6/9/21 10:03 AM schrieb Manolo wrote:
> The problem with glpuzzle should be fixed after git pull.

Confirmed. Did you know that you can toggle the depth buffer while
running glpuzzle? It displays a short menu with ...

  b   Toggles the depth buffer on and off

The effect after pressing 'b' looks exactly like before.

On 6/9/21 12:06 PM Manolo wrote:
> Building with both Wayland and Cairo support will work after git pull.

Confirmed as well. Thanks.

No day without a new bug or not yet complete(d) feature ? ;-)

The 'mandelbrot' demo displays a trace of rectangles when you select a
part of the image by dragging the mouse, see screenshot. It's redrawn
correctly after releasing the mouse button.

[Manolo]

Le mercredi 9 juin 2021 à 12:44:10 UTC+2, Albrecht Schlosser a écrit :

The 'mandelbrot' demo displays a trace of rectangles when you select a
part of the image by dragging the mouse, see screenshot. It's redrawn
correctly after releasing the mouse button.

Yes, I know and have that in my TODO list.

After git pull, use with Weston should now be much improved.

Does Mint lack the wayland-enabled gnome desktop?

Do you know how to configure the keyboard layout with Weston?

[Albrecht Schlosser]

On 6/9/21 3:42 PM Manolo wrote:

Le mercredi 9 juin 2021 à 12:44:10 UTC+2, Albrecht Schlosser a écrit :

The 'mandelbrot' demo displays a trace of rectangles when you select a
part of the image by dragging the mouse, see screenshot. It's redrawn
correctly after releasing the mouse button.

Yes, I know and have that in my TODO list.

OK, great!

After git pull, use with Weston should now be much improved.

Indeed it is. Thank you very much for the quick fix.

Does Mint lack the wayland-enabled gnome desktop?

Honestly, I don't know for sure. Maybe you can install and configure it, I never tried. Mint comes with one of three (Cinnamon, MATE, Xfce) desktop systems preinstalled. I'm using the Cinnamon desktop because I wanted a "fast and light" ;-) desktop system when my previous Ubuntu system (at that time still in a VM under Windows) became slower and slower from version to version.

When I first tried to test Wayland (before you came up with the FLTK port) I installed Weston which did what I wanted to test. Later I also needed Wayland on Ubuntu for a copy-and-paste issue in FLTK and that's why I installed Ubuntu in another VM which enabled me to test on the normal Ubuntu (X11) and/or the Ubuntu-Wayland desktop (by logging into the respective desktop as you certainly know).

Do you know how to configure the keyboard layout with Weston?

No, unfortunately not, but I didn't need it yet. On my notebook Weston *seems* to take the key definitions from my "host" system and this appears to work well in 'terminal' and other apps. However

- test/keyboard seems to work fine WRT Fl::event_text()
- test/keyboard shows some "unknown" glyphs for non-ASCII characters (e.g. German Umlauts äöü) in Fl::event_key()

I'm not sure about the latter in X11 apps, I thought it displayed for instance 'ä' (with quotes) but now it doesn't. Maybe another FLTK config?


BTW: since you disabled the usage of the FLTK_SCALING_FACTOR environment variable in commit 2e715259ef30c (IIRC) FLTK apps crash when you type ctrl/+ (which is actually worse than before):

$ test/keyboard
makeWindow:0x7d0000 wl_compositor_create_surface=0x7f6b90 scale=1
makeWindow:0x968d60 wl_compositor_create_surface=0x978320 scale=1
makeWindow: xdg_wm_base_get_xdg_surface=0x978380
xdg_surface@34: error 3: xdg_surface has never been configured
---- app using 100% CPU, needs to be stopped with ctrl/c or killed ----
^C
$

[Manolo]

Le mercredi 9 juin 2021 à 16:46:01 UTC+2, Albrecht Schlosser a écrit :

BTW: since you disabled the usage of the FLTK_SCALING_FACTOR environment variable in commit 2e715259ef30c (IIRC) FLTK apps crash when you type ctrl/+ (which is actually worse than before):

A make clean; make might be useful.

[Albrecht Schlosser]

Yes, indeed, that worked. A better solution, however, is: 'make depend; make'. This fails though in the current wayland branch.

Please add the minimal attached patch to the wayland branch. This does not solve the entire dependency mess, but it enables all testers to execute `make depend' to update the dependencies rather than always using `make clean', although libdecor is not included (which leaves this as another source of trouble). The created 'makedepend' files are not compatible with the 'master' branch and should not be committed but can be used for testing.

I'll try to get CMake working which will resolve the dependency issues for free.

[Manolo]

Le jeudi 10 juin 2021 à 01:21:58 UTC+2, Albrecht Schlosser a écrit :

Please add the minimal attached patch to the wayland branch. This does not solve the entire dependency mess, but it enables all testers to execute `make depend' to update the dependencies rather than always using `make clean', although libdecor is not included (which leaves this as another source of trouble). The created 'makedepend' files are not compatible with the 'master' branch and should not be committed but can be used for testing.

Done.
Is it expected to receive loads of

makedepend: warning:  Fl.cxx (reading ../FL/fl_utf8.h, line 32): cannot find include file "stdio.h"
    not in ../stdio.h
makedepend: warning:  Fl.cxx (reading ../FL/Fl.H, line 45): cannot find include file "string.h"
    not in ../string.h
?

I'll try to get CMake working which will resolve the dependency issues for free.

Great. I'm looking forward to that.

[Manolo]

Le mercredi 9 juin 2021 à 15:42:24 UTC+2, Manolo a écrit :

Do you know how to configure the keyboard layout with Weston?

FTR: one solution, for my situation, is to create this file with this content

$HOME/.config/weston.ini

===============

[keyboard]

keymap_layout=fr(mac)

===============

[Albrecht Schlosser]

On 6/10/21 8:55 AM Manolo wrote:

Le jeudi 10 juin 2021 à 01:21:58 UTC+2, Albrecht Schlosser a écrit :

Please add the minimal attached patch to the wayland branch. This does not solve the entire dependency mess, but it enables all testers to execute `make depend' to update the dependencies rather than always using `make clean', although libdecor is not included (which leaves this as another source of trouble). The created 'makedepend' files are not compatible with the 'master' branch and should not be committed but can be used for testing.

Done.

Thanks.

Is it expected to receive loads of

makedepend: warning:  Fl.cxx (reading ../FL/fl_utf8.h, line 32): cannot find include file "stdio.h"
    not in ../stdio.h
makedepend: warning:  Fl.cxx (reading ../FL/Fl.H, line 45): cannot find include file "string.h"
    not in ../string.h
?

Yes, that's always the case for all system headers, i.e. also if you're executing in the main branch. It also creates 'makedepend.bak' files which you can delete.

FYI: I'm updating the dependencies in the main branch from time to time:

$ ./configure --enable-cairo
$ make -j7
$ make depend

optional (less frequently):

$ for d in cairo jpeg png zlib; do (cd $d; make depend); done

then commit the changed 'makedepend' files.

I just committed an update, but this should not concern the wayland branch.

Note: This *must* be done on a Linux system. Dependencies for other platforms including other configurations like `pango` need to be created/edited in the Makefiles "manually". This is what I called the "dependency mess". If anybody could show us an acceptable (i.e. "simple") way to create the dependendies dynamically (automatically during the build), cross-platform and independent of the chosen compiler (!) I'd appreciate that!

PS: one option is to drop autoconf/configure/make support and use CMake exclusively which "knows the correct dependencies". I'd like to do that but I'm aware that others want to keep configure/make builds. :-(

[Albrecht Schlosser]

Great that you found it, and thanks for the info. I also tried this yesterday (late in the evening). I used 'keymap_layout=fr' but could not see an effect, so I stopped it.

For others:

- man weston
- man weston.ini

[Ian MacArthur]

On 10 Jun 2021, at 11:48, Albrecht Schlosser wrote:
>
> Note: This *must* be done on a Linux system. Dependencies for other platforms including other configurations like `pango` need to be created/edited in the Makefiles "manually". This is what I called the "dependency mess". If anybody could show us an acceptable (i.e. "simple") way to create the dependendies dynamically (automatically during the build), cross-platform and independent of the chosen compiler (!) I'd appreciate that!

Part of the problem (and I think Albrecht and I have poked at this a bit in the past) is that makedepend is pretty ancient and was, IIRC, spun out of X11 work. It has a somewhat erratic behaviour too, in my experience, and often misses dependencies, and very occasionally adds others that do not really exits.

It bit me badly in the past (a build became corrupt because several key dependencies were missed) and I no longer trust it. I *suspect* this is also why the fltk configure builds occasionally fail to rebuild everything correctly after a pull, as the generated dependencies are actually incomplete.

For my part, I use gcc to generate the dependency list, which at least works reliably (in so far as it picks the same files during dependency generation as it picks during compilation...) but that’s not a very portable mechanism, since it doesn’t really work with MS cl.
Though the mechanism I use does work OK with the gcc personalities of icc and clang.

Hmmm, deja vu - did we not post possible options for doing this... at some point in the past...?

[Albrecht Schlosser]

On 6/10/21 10:29 PM Ian MacArthur wrote:
> On 10 Jun 2021, at 11:48, Albrecht Schlosser wrote:
>
> Note: This *must* be done on a Linux system. Dependencies for other platforms including other configurations like `pango` need to be created/edited in the Makefiles "manually". This is what I called the "dependency mess". If anybody could show us an acceptable (i.e. "simple") way to create the dependendies dynamically (automatically during the build), cross-platform and independent of the chosen compiler (!) I'd appreciate that!
>
> Part of the problem (and I think Albrecht and I have poked at this a bit in the past) is that makedepend is pretty ancient and was, IIRC, spun out of X11 work.

Yep, that's true, a quick packet search reveals the package is
xutils-dev (in Debian-based distros).

xutils-dev: /usr/bin/makedepend

>> It has a somewhat erratic behaviour too, in my experience, and often misses dependencies, and very occasionally adds others that do not really exits.

It's not a big problem if it adds unnecessary dependencies, but it's
really bad if it misses deps.

>> It bit me badly in the past (a build became corrupt because several key dependencies were missed) and I no longer trust it. I *suspect* this is also why the fltk configure builds occasionally fail to rebuild everything correctly after a pull, as the generated dependencies are actually incomplete.
>>
>> For my part, I use gcc to generate the dependency list, which at least works reliably (in so far as it picks the same files during dependency generation as it picks during compilation...) but that’s not a very portable mechanism, since it doesn’t really work with MS cl.
>> Though the mechanism I use does work OK with the gcc personalities of icc and clang.

That's the problem. As long as we don't have a working cross-platform
dependency system, makedepend (or make clean; make) is the best we have.

>> Hmmm, deja vu - did we not post possible options for doing this... at some point in the past...?

Yes, I think there were some gcc-based options, but since this doesn't
solve the problem ...

[Albrecht Schlosser]

On 6/10/21 10:07 AM Manolo wrote:

I tried this too, but it didn't have any effect on my keyboard layout. I was able to switch my keyboard with the system keyboard setup to "French" and this affected the keypresses in Weston.

Regarding test/keyboard: display of Fl::event_key(): I just fixed a display error which has been missed since we moved to UTF-8. It does not manifest in Xft configuration in the master and 1.3 branches, but can be seen when configured with Pango (master and/or wayland):




This has been fixed in master, commit 986a8b33a2. Now keypresses in the full latin1 (ISO-8859-1) range are displayed correctly.

You can either rebase the wayland branch on upstream/master or use

  git fetch upstream          # (or whatever your FLTK remote repo is called)
  git cherry-pick 986a8b33a2

to pull this single commit into the wayland branch. In a later rebase this commit will be skipped.

[W. B.]

As I'm one of the few who asked for Wayland support - this makes me VERY happy :) - thank you!

I tried it - looking good so far.

The only little problem I had with building it was with the libdecor library, only had to change one line to get there:

libdecor/build/Makefile, lines 28 and 29

original:

[code]

cursor-settings.o : ../src/cursor-settings.c

$(CC) $(CFLAGS)  -c ../src/cursor-settings.c -DHAS_DBUS -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 

[/code]

changed to:

[code]

cursor-settings.o : ../src/cursor-settings.c

$(CC) $(CFLAGS)  -c ../src/cursor-settings.c -DHAS_DBUS -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include 

[/code]

it's on archlinux, but would apply to manjaro etc also... the only file thats in there is "dbus-arch-deps.h". and arch has also the same file in /usr/lib64/dbus-1.0 also... for whatever reason...

hint:

[code]

pkg-config --cflags dbus-1
[/code]

[Manolo]

Le vendredi 11 juin 2021 à 14:02:07 UTC+2, Albrecht Schlosser a écrit :

Regarding test/keyboard: display of Fl::event_key(): I just fixed a display error which has been missed since we moved to UTF-8.

…

This has been fixed in master, commit 986a8b33a2. Now keypresses in the full latin1 (ISO-8859-1) range are displayed correctly.

You can either rebase the wayland branch on upstream/master or …

I've rebased the wayland branch which now adds support for drag--n-drop to and from  FLTK widgets.

It's still missing a dragging icon, though, but I've a hard time having that work.

[Manolo]

Le vendredi 11 juin 2021 à 14:33:01 UTC+2, W. B. a écrit :

As I'm one of the few who asked for Wayland support - this makes me VERY happy :) - thank you!

Glad you're happy.
Could you share your experience with your FLTK apps + Wayland?

I tried it - looking good so far.

The only little problem I had with building it was with the libdecor library, only had to change one line to get there:

libdecor/build/Makefile, lines 28 and 29

…

it's on archlinux, but would apply to manjaro etc also... the only file thats in there is "dbus-arch-deps.h". and arch has also the same file in /usr/lib64/dbus-1.0 also... for whatever reason...

hint:

[code]

pkg-config --cflags dbus-1
[/code]

I've committed this change. Thanks for the hint.

[W. B.]

Glad you're happy.
Could you share your experience with your FLTK apps + Wayland?

yes, of course. I set up new targets for 2 of my projects for wayland support.

One of them is pretty simple, it's basically a REST-api client for a webservice - get json-formatted data, show it. Well it's kind of a forum api, so writing posts, searching is also working etc...

The other one is for my work, an in-house database-management frontend of sorts, doing the inhouse office management, accounting etc. pretty complicated (but still very small in size - the DB-system doing the bulk of the work).

Got both to work under wayland. I did however build the libdecor as a static library (didn't want to install it systemwide). so both fltk and libdecor are statically linked.

the linker settings for the first one as follows:

on X11:

curl, fltk, dl, X11, Xrender, Xext, Xinerama, Xcursor, Xfixes, Xft, fontconfig

on Wayland:

curl, fltk, dl, fontconfig, wayland-client, wayland-cursor, cairo, xkbcommon, decor, cairo, pango-1.0, gobject-2.0, pangocairo-1.0, dbus-1

the second (db-management) one has basically the same + some more, like sqlite, mariadb, etc etc

first - I really dislike linking to "gobject". or anything glib related really. POS software. It's here because of Pango, I get it, still - imo stay away from Gnome libs as far as possible...

so far - both programs run. Both tested under "Weston".

The X11 versions of both were used all the time, the second app is mostly used on MacOS however (-> it's a very "apple" house ;) in production

On both the fontrendering is very blurry under wayland. Pango related I think. I remember you (= fltk-core-dev team) had some problems like that in the past. Pango changes. Even little version jumps can have "side-effects". Debian (+ ubuntu etc) stay longer on older versions, Arch etc jumps pretty fast on newer ones. It's a "gnome" library, sigh

On both of my apps it's possible to drag windows not only by the top-bar, just with the mouse, using the "unused" space of a window. This doesn't work on wayland - but the documentation mentions it, so I knew beforehand

On the smaller app I create a window before the Fl::run, it has a reload() function, and there Fl::check() is used 2 times. The window gets created, the reload function is called, afterwards the window->show() is called, and then Fl::run loop is run. It does work on X11 and MacOS just fine. On wayland it crashed - had to remove those two Fl::check() - then it ran. Hmm, don't know why ... - never had such on X11 and MacOS ^^

Besides of that - the smaller app runs just as good as the X11 version (but blurry text-rendering)

The second one however... is far more complex. A lot of Trees, Tables, input-widgets etc. A lot of "text" overall. The resizing of windows is waaaaay faster on X11 and MacOS. Wayland resize is much slower. I use a lot of pop-up windows here (like search dialogs, date/calendar widgets pop ups etc) - they open relative to the widgets on X11/MacOS. On wayland it's all random (the readme.wayland mentioned it, so that's known). It however also happens on Fl_Choices, Fl_Choice_Inputs etc. Fl_Trees with own drawing functions for Fl_Tree_Items seems to be fine.

I use quite a lot "Sub-Windows", so Fl_Windows inside of other Fl_Windows. On Weston if you have some windows open (something non fltk, and some fltk windows), if you use SUPER+tab you can switch between them - the active will be fully drawn, the others slightly transparent. If an fltk window has an "sub-window" inside - that subwindow will be drawn non-transparent (but only! the subwindow). Weston has the option to "minimize", but no real "app-bar". If you minimize it will just fade out and disappear. You can get it back through SUPER+tab switching. Fltk windows try to fade out, then they glitch, and you can see parts of them still (just move the mouse over those glitches to get that portion of the screen to redrawn)

Btw the resizing is much faster under Xwayland on Gnome3-wayland than in native wayland under weston. Need some more tests under Gnome3 wayland though

I do also have slightly modified versions of flVLC and flaxPDF somewhere. VLC itself is working with wayland, and flVLC uses nothing X11 related directly - that one should be relatively easy to get running.

flaxPDF however uses X11 functions directly - afair it uses X11 to directly copy betweedn SHM buffers to draw parts of the PDFs. These two come to my mind because they are relatively complex (= not using only FLTK stuff XD. So I would try to get them to run... My own programs are somewhere inbetween the two mentioned above - the DB-system-client is by far the most complex one

But honestly - it's very impressive so far :)

 

[Manolo]

It turns out I had to introduce slight differences in the FLTK Wayland code depending

on whether it's run with Weston or with Gnome-Wayland. This creates the need

for libfltk to detect whether Weston is running. I have found that environment variable

XDG_SESSION_DESKTOP may be where to get that info. I see its value is

weston or Ubuntu-wayland or gnome.

A question to Weston users Albrecht and W.B. :

Is XDG_SESSION_DESKTOP defined in your setup? and does its value contain the string "weston" ?

[Albrecht Schlosser]

I haven't tried this yet in my Ubuntu VM, but on my Linux Mint the
answers are unfortunately "yes" and "no". Here's an excerpt of maybe
related environment vars:

DESKTOP_SESSION=cinnamon
XDG_SESSION_DESKTOP=cinnamon
XDG_SESSION_TYPE=x11
WAYLAND_DISPLAY=wayland-0

I executed 'env' in a "terminal" session provided by my weston instance
on the Linux desktop, the output is filtered.

You can see that WAYLAND_DISPLAY is defined. This is the only related
variable that is different than in a normal X session, but that doesn't
help, unfortunately.

[Bill Spitzak]

Might be helpful to describe what the differences are, this may indicate mis-use of Wayland and there is some method to make a program work on both versions.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/1d723adb-1c3e-7768-9e48-5d0cd89eceab%40online.de.

[Manolo]

Le mercredi 16 juin 2021 à 17:57:57 UTC+2, Albrecht Schlosser a écrit :

 Here's an excerpt of maybe
related environment vars:
DESKTOP_SESSION=cinnamon
XDG_SESSION_DESKTOP=cinnamon
XDG_SESSION_TYPE=x11
WAYLAND_DISPLAY=wayland-0

OK. So I'll keep with a single code path for both compositors.

[Manolo]

The candidate source code for a new wayland platform for FLTK has progressed.

OpenGL views now behave correctly. All reported glitches have been repaired.

All test programs now run well both with Mutter and Weston, expect those that

ask for window positionning or unminimizing which is impossible with Wayland.

I specially focussed on improving Weston support, even if libdecor is not adapted to it.

To support window minimization under Weston, the titlebar disappears

also when the window becomes inactive. That makes minimization

and Super+Tab unminimization working corectly under Weston.

It would be possible to have the titlebar disappear only when a window

gets minimized by fiddling somewhat inside libdecor.

The repository has been synchronized with all changes till now of the reference FLTK repo.

As before, the code is in branch "wayland" of https://github.com/ManoloFLTK/fltk

and see file README.Wayland.txt therein for installation instructions.

[Greg Ercolano]

On 9/1/21 10:07 AM, Manolo wrote:

The candidate source code for a new wayland platform for FLTK has progressed.

OpenGL views now behave correctly. All reported glitches have been repaired.

All test programs now run well both with Mutter and Weston, expect those that

ask for window positionning or unminimizing which is impossible with Wayland.

This all sounds great! Thanks so much Manolo.

While I don't have Wayland yet, I'll be upgrading my workstation
in the near future, and if it ends up having Wayland under the hood,
I'll be sure to give it a test.

[Manolo]

Le mercredi 1 septembre 2021 à 19:07:36 UTC+2, Manolo a écrit :

I specially focussed on improving Weston support, even if libdecor is not adapted to it.

To support window minimization under Weston, the titlebar disappears

also when the window becomes inactive. That makes minimization

and Super+Tab unminimization working corectly under Weston.

It would be possible to have the titlebar disappear only when a window

gets minimized by fiddling somewhat inside libdecor.

As of today, window minimization and Super+Tab unminimization work almost

correctly under Weston; the only drawback is that the titlebar disappears from

a minimized window while it's being previewed by Super+Tab.

[Greg Ercolano]

On 9/2/21 6:44 AM, Manolo wrote:

As of today, window minimization and Super+Tab unminimization work almost

correctly under Weston; the only drawback is that the titlebar disappears from

a minimized window while it's being previewed by Super+Tab.

    By "Super+Tab" that means..

+Tab, or..

  + Tab

    ..right?

    I haven't seen a "Super" key since I used a Symbolics machine back in the 80's..!

   

[Manolo]

Le jeudi 2 septembre 2021 à 18:33:18 UTC+2, er...@seriss.com a écrit :

On 9/2/21 6:44 AM, Manolo wrote:

As of today, window minimization and Super+Tab unminimization work almost

correctly under Weston; the only drawback is that the titlebar disappears from

a minimized window while it's being previewed by Super+Tab.

    By "Super+Tab" that means..

+Tab, or..

  + Tab

    ..right?

The truth is that  I'm not sure because I'm using Weston with an Apple Macbook keyboard (via

a virtualization software called UTM). There, the winning key combination is function+command+Tab.

I'm sure that if you try all modifier keys of your keyboard in combination with tab, one will

start Weston's procedure to go through all active windows, both those shown and those minimized.

 https://wiki.archlinux.org/title/Weston#Shortcuts explains that Super is the Windows key.

[Bill Spitzak]

FLTK should probably rename the key "Super" as well to be consistent. When it was made I expected X to call that key "Meta".

--

You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/54decf1c-d8de-4c59-b686-088e782b707en%40googlegroups.com.

[Manolo]

FLTK should probably rename the key "Super" as well to be consistent. When it was made I expected X to call that key "Meta".

For some reason, the Weston documentation uses "Super" to name the default modifier key it uses,

e.g., man weston.ini contains :

       binding-modifier=ctrl
              sets the modifier key used for common bindings (string), such as
              moving surfaces, resizing, rotating, switching, closing and set‐
              ting the transparency for windows, controlling the backlight and
              zooming  the  desktop. See weston-bindings(7).  Possible values:
              none, ctrl, alt, super (default)

That's also how W.B. called it in his message dated June 12th above, which has also been my first read

ever of such a key name.

Fortunately, that business is strictly private to the Weston compositor. FLTK doesn't have to process such a key stroke,

which is defined by Weston and can be changed via file $HOME/.config/weston.ini. The other Wayland compositor

I know, Mutter, doesn't use a key stroke to gain access to minimized windows.

In short, the Wayland FLTK platform doesn't use the key name "super" anywhere.

[Bill Spitzak]

I meant that FLTK itself in it's header file should change the name of the symbol from META to SUPER, in order to match a vast amount of other Linux documentation, including Weston apparently. Also FLTK should report the shift key is pressed down when you push it and the window has keyboard focus, even if Weston eats some of the key combinations, and currently the symbols and the keyboard demo say "META".

--

You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/aa5bf9bd-acd9-47e3-a95f-071c1dc0cd76n%40googlegroups.com.

[Manolo]

The putative Wayland platform now begins to support a 3rd Wayland compositor, KDE.

In that situation, FLTK apps use SSD (server-side decoration), whereas they use

CSD (client-side) with the gnome and Weston compositors.

Any FLTK executable supports, unchanged, all 3 compositors.

But there is still a problem to be solved with progressive drawing under KDE.

[Albrecht Schlosser]

On 9/10/21 7:09 PM Manolo wrote:
> The putative Wayland platform now begins to support a 3rd Wayland
> compositor, KDE.
> In that situation, FLTK apps use SSD (server-side decoration), whereas
> they use
> CSD (client-side) with the gnome and Weston compositors.
> Any FLTK executable supports, unchanged, all 3 compositors.

Awesome!

Thanks for continuously working on improving FLTK and keeping us
informed. I really need to try the latest updates...

> But there is still a problem to be solved with progressive drawing
> under KDE.

I'm not using KDE in my working environments, this is something I will
likely not be able to try though.

[Manolo]

The attached image shows the FLTK hello app running in CSD (top) and SSD (bottom) contexts :

[Manolo]

Progress report for the proposed Wayland platform :

- added support of configure --enable-wayland --enable-shared

- renamed the preprocessor variable that signals use of the Wayland

platform from __WAYLAND__ to USE_WAYLAND. That parallels USE_X11

used for the X11 platform.

- the libdecor code to draw and handle window decorations is no longer in a shared

library. It's now put in an additional FLTK-created library called libfltk_decor.a,

and libfltk_decor.so.1.4 if --enable-shared is used.

- the code has been modified so all 3 compositors (Mutter, Weston and KDE) use

the same means to synchronize drawing requests with the display capabilities.

- added support for GUI scaling with ctrl/+/-/0/, in addition to Wayland-supported

scaling which is restricted to integer values (mostly 2).

[Bill Spitzak]

I am not clear on why part of it is in a different library, rather than just part of libfltk.

Will any of this work be helpful for also getting the X11 version to use Cairo?

--

You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/c1862f6e-1a7e-435c-96f8-4702196257ean%40googlegroups.com.

[Manolo]

Le jeudi 28 octobre 2021 à 20:25:09 UTC+2, spi...@gmail.com a écrit :

I am not clear on why part of it is in a different library, rather than just part of libfltk.

My idea was to allow other client programs, independently from FLTK, to link

to libdecor. That applies to the two demo programs (demo and egl) proposed by libdecor.
That also allows to use libdecor in C, instead of requiring C++.

If none of this is considered useful, then it's possible to put all libdecor code in libfltk.a.

Will any of this work be helpful for also getting the X11 version to use Cairo?

Yes it will. An Fl_Cairo_Graphics_Driver class can be built, from Fl_Wayland_Graphics_Driver,

and used both under X11 and Wayland.

But this requires first the Wayland platform code to be merged into the FLTK main branch.

[Manolo]

New progress report

- libdecor is now put in libfltk rather than in a separate libfltk_decor as before;

- Added support for CMake-based build, with or without OPTION_BUILD_SHARED_LIBS

[Albrecht Schlosser]

On 10/31/21 3:51 PM Manolo wrote:
> New progress report
> - libdecor is now put in libfltk rather than in a separate
> libfltk_decor as before;

Thanks

> - Added support for CMake-based build, with or without
> OPTION_BUILD_SHARED_LIBS

Great!  This was on my todo list but I didn't come to it yet. I'll try
it asap.

[Manolo]

New progress report:

- fixed support of fl_overlay_rect() at all GUI scaling values.
That's visible with test/mandelbrot

- added support of Fl::args()

- completed support of drag-n-drop from, to, and within FLTK apps

- added support of window size limits.

[Manolo]

New progress report:

All code previously repeated between the X11 and Wayland platforms has

been reorganized so it's no longer repeated when the Wayland platform

code will be merged.

The chosen solution was to define this hierarchy of "system driver" classes:

1. Fl_System_Driver
    2. Fl_Posix_System_Driver
         3. Fl_Nix_System_Driver
             4. Fl_X11_System_Driver
             4. Fl_Wayland_System_Driver
        3. Fl_Darwin_System_Driver
   2. Fl_WinAPI_System_Driver

and to put all shared code in the new class Fl_Nix_System_Driver.

Suggestions for better names than Fl_Nix_System_Driver are accepted.