Wayland and Gambas

Wayland is the "new" graphics systems that wants to replace the old X11 graphics systems on Linux. It's new between quotes because it is more than fifteen years old now.

Wayland took a different approach on many things, mostly for security reasons, leading to the following problems:

A lot of common features implemented by X11 (and the graphics systems on Windows and Mac operating systems as well) are not provided by Wayland.
The Wayland developers apparently refuse to change their design or implement the missing features, breaking a lot of applications that must be rewritten.
Consequently, every desktop and every toolkit has to provide these features on its own. So even if you rewrite your application, you can't be sure it will work depending on the GUI toolkit (Qt, GTK+...) you will use, and the desktop (Gnome, KDE, Mate, XFCE...) your application will run on.

We will try to list here all the problems you will encounter by running a Gambas application with Wayland.

Note that, when possible, workarounds have been already implemented to circumvent some Wayland limitations.

Moving a top-level window
Taking a screenshot, and desktop portals
Other problems
The real solution

Moving a top-level window

The way Wayland provides an application window space differs to how X11 does it.

The best way to understand the difference is to consider with Wayland your application window now opens in it's very own personal mini screen.

The compositor gives your program a private area the size of your applications window and sandboxes the application inside it.

The compositor also decides on the windows placement using a method Wayland refers to as "descriptive".

Unlike with X11 where your window is a smaller rectangle inside a larger screen rectangle, with Wayland your window is essentially fullscreen in it's own sandboxed screen space.

So, from the Gambas programs point of view, the screen is the size of your window and the windows X and Y position is always (0, 0). If you move the window manually, the X and Y coordinates do not change, and the window Move event will not trigger as expected.

This breaks any code that wants to move the main (top-level) window on the screen or code that responds to a window being moved.

The following window operations are not possible with Wayland:

Moving a window by setting Window.X , Window.Y or using Window.Move(X, Y).
Reading Window.X, Window.Y, Window.ScreenX, Window.ScreenY will not make sense.
The Form Move event will not trigger as expected.
Settings.Write() and Settings.Read() will not save and restore window position. Only the size is restored.

Since 3.21

At least it is now possible with Wayland to ask the window manager to start moving a window with the mouse. This is accomplished in Gambas by calling the Window.StartMove() method inside a mouse event.

See help for Window.StartMove() for more info.

For most code working inside the application area there is no real difference in the outcome of using say Control.ScreenX with Window.X values.

Consider this simple example:

' Get a control's X position relevant to the window border using Window.X and Control.ScreenX values...
Dim iXPos As Integer = hControl.ScreenX - hControl.Window.X

In that example the usage of .ScreenX and Window.X values will work just as well with Wayland as X11, as the difference/offset is handled internally.

Only when it comes to top-level window movement or reading top-level window positions will you find window position properties not making sense in Wayland as the "screen" as we know it is not the same as X11.

Otherwise it's probably code that will still work as expected on X11 and Wayland :)

Wayland's opinion of the inability to move windows by code or open them where you want them is that we must change how we write programs to fit their ideal of "the compositor knows where your window should go".

Any program using mouse drag events and code to move a borderless window on the desktop must be "re-thought" to work with Wayland.

Taking a screenshot, and desktop portals

See Desktop.ScreenShot.

For security reasons Wayland has declared a program can no longer arbitrarily "grab" any area of the screen without user interaction. The optional (X, Y, Width, Height arguments) will no longer do anything.

Taking a screenshot on Wayland now relies on desktop portals, i.e. running an external program triggered by a DBus call that depends on the desktop currently in use.

So with Wayland, it mostly opens up the screenshot dialog of the system, a bit like you just hit the "Print Screen" button.

You have the same problem if you want to pick a color on the screen.

Note the huge incompatibility matrix on the ArchLinux wiki page above. Good luck to know if your program will be able to take a screenshot, or use any other features that were previously implemented with some now deprecated xdg shell utilities...

Since 3.21

The Gambas desktop component maintains an internal copy of the xdg shell utilities, and uses them by default to implement the desktop agnostic features, because desktop portals implementation are not reliable.

But you can use the Desktop.UsePortal property to enable the use of desktop portals if you want.

Problem	Toolkit	Desktop	Workaround
The window manager forces the size of non-resizable dialogs.	Any	Gnome	Install Gnome Tweaks and disable this option.
Non-resizable windows still have the resizable buttons.	QT	Gnome	None.
The windows have no shadows.	QT	Gnome	None.
The mouse coordinates received on mouse moves by the editor are false.	QT	Gnome	None. But mouse press events are correct, go figure.
The resizable modal dialogs have a huge white border for no reason.	GTK+	Gnome	None.
Windows of applications run from the IDE do not have icons.	Any	Any	Gambas creates a temporary fake desktop file where it can, pointing at the application icon. A warning is displayed on the command line.
All windows of the same application have the same icons.	Any	Any	Wayland does not have the concept of windows icon at the moment. A new protocol for that is in "development".
The IDE window does not raise automatically when a debugged program stops somewhere.	Any	Any	None. Wayland does not allow a window to be raised.
Mouse cursor does not change when `Application.Busy` is set.	QT	Any	On Wayland, you must call the event loop, otherwise cursors are not refreshed.
The size of resizable IDE dialogs is not restored.	GTK+	KDE	Must check if it can be some bug in the GTK+ component.

The real solution