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 :)
