Wayland and gambas

The new Wayland desktop that many main linux systems are adopting as default has a few setbacks when it comes to what gambas GUI developers are used to.

The Gambas GUI environment was built around X11 and Wayland has taken a different approach to some things, mostly citing security reasons, this has caused a few limitations in GUI designing.

This is a list of known issues.

Top level window position/movement

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 (ish, depending on margins) If you move the window manually the X and Y coordinates do not change and the Form_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/restore window position, only the size is restored.

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...

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

Only when it comes to top-level window movement or reading top-level window positions () will you find Form 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 :)

Desktop.Screenshot()

See Desktop.Screenshot()

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

Now ANY use of Desktop.Screenshot() just opens up the screenshot dialog of the system (like you just hit the Print Screen button)

Clipboard.class