Some observations with the latest Wayland commit 06f6f01cc351859 (all
tests on Linux Mint with Weston):
Thanks for testing.
Drawing lines, points, circles, curves etc. is excellent, rotated text
is superb! The gleam scheme looks very good (with some really minor
artifacts when scaled). Tested with unittests and some more test programs.
This is 100% pure cairo+pango. Scaling is done by calling cairo_scale().
glpuzzle: very slow spinning when you drag the mouse on the board.
Hitting 'space' or 'n' key which should stop spinning reacts delayed
rather than immediately. There seems to be a very long "pipeline" of
events to be serviced before the app reacts. Even the window close
button seems to react delayed while the puzzle is spinning.
There's a special handling for top-level GL windows (as opposed to GL
subwindows) that may explain that.
threads: sluggish like glpuzzle when trying to stop the demo (delay ~5
seconds in my tests). This may be caused by the WM or Weston though, I
don't know.
Or by the virtual machine handling. This would need testing on a real Linux box.
sudoku: this app should change its window title but this doesn't happen
in my test environment. To test you can use the "Difficulty" menu.
That's most probably a Weston bug, because the title changes correctly with
Mutter and KDE. The code calls all functions to redraw the title, but it doesn't
show on the display. The changed title is visible as soon as the titlebar gets redrawn
(e.g. horizontal resize).
mandelbrot: dragging the mouse leaves a trace of rectangles. ISTR that
this is a known issue, but anyway.
Yes, it's a known issue. I believe it's done by cairo slightly leaking out of its clip box
when drawing an image, and I'm afraid it may be difficult to fix. I believe the same
cause also explains why, after zooming in or out the image, faint traces of the previous
scene remain visible in the new scene.
tile: the horizontal drag cursor is fine (FL_CURSOR_WE, the vertical
drag cursor (FL_CURSOR_NS) doesn't appear. Dragging an intersection of
more than two sections displays a somewhat uncommon "hand" cursor (a
normal cursor with a small white square or something similar). This is
obviously FL_CURSOR_MOVE (as displayed by the cursor demo).
None of that happens with Mutter or KDE. This looks like another Weston bug
that doesn't redraw the cursor when it should.
Note: the "cursor" demo displays FL_CURSOR_HAND correctly (a "hand") but
FL_CURSOR_NS is shown as the "normal" cursor.
In my hands (Debian or Ubuntu in a virtual machine), the cursor demo doesn't ever
change the cursor shape with weston, although all required shapes are found by the adequate
Wayland function (wl_cursor_theme_get_cursor). The same cursor executable works
flawlessly with Mutter and KDE. For me, that's a weston bug.
message and ask: the popup windows (fl_message et al.) seem to pop up at
arbitrary locations. Particularly the "hotspot" setting doesn't seem to
work (at least not always). I couldn't test this further though.
The Wayland FLTK implementation doesn't attempt to control the location of toplevel
windows on the display because Wayland offers no way to do it. That's a feature of Wayland.
It's possible, though, to locate a window relatively to another one. That's used for menu and
tooltip windows. That's also used, in the Wayland platform only, for the transient yellow
window that shows the new GUI scale factor which is centered relatively to the front
toplevel window. I see no way to position a window relatively to the cursor with Wayland.
Other observations:
It's sometimes difficult to drag a window border because the cursor
doesn't change when you hover over the border. This is particularly an
issue on the left and top sides and corners. It works *much* better at
the bottom and right sides and the bottom right corner. I got the
impression that you can drag the border even if the cursor doesn't
indicate it. If you do so the cursor changes as soon as you click the
mouse near the border or corner.
None of that is under FLTK control. It's all done by the wayland compositor,
Weston in your case. In my hands it's as difficult to resize an FLTK window
as it is for a non-FLTK window such as gedit or gnome-terminal. Again, other
compositors (Mutter, KDE) handle much better these things.
I ran out of time, hence I had to stop my tests here. Summary: many,
many things (which I didn't mention explicitly) work flawlessly but I
couldn't test every demo program. The glitches mentioned above are no
real show stoppers but in parts inconvenient.
Altogether: it's awesome! Great work! Thank you very much, Manolo.
In general terms, my feeling now is that Weston is not really usable (yet?) in a desktop
environment, whereas gnome's Mutter and KDE support much better all window
operations (resize, redraw, hide, show, rename, cursor changes, etc…) expected in a desktop setting. It's also
what I read in weston's presentation in its own source repository :
https://gitlab.freedesktop.org/wayland/weston
"Weston is the reference implementation of a Wayland compositor, as well as a
useful environment in and of itself.
Out of the box, Weston provides a very basic desktop, or a full-featured
environment for non-desktop uses…
If you are after a more mainline desktop experience, the
GNOME and KDE projects provide
full-featured desktop environments built on the Wayland protocol."
I also read that the gnome desktop can be installed under Linux Mint.
I have communicated with Jonas Ådahl, libdecor's lead author. He wrote that the traces left on the display when a window framed by libdecor is minimized under weston is a weston bug. Since he's also a weston developer, he committed a fix for that in the weston code repository (https://gitlab.freedesktop.org/wayland/weston/-/commit/56958aa6e9c7c20909c99e978514d99a3c943ed8). That will be included in the next weston release and later will make its way into linux distributions. Meanwhile, FLTK hides the window frame while a window is minimized under weston and restores it when that window gets unminimized.
