Gambas Documentation
Application Repository
Code Snippets
Compilation & Installation from source code
Components
Controls pictures
Deprecated components
Developer Documentation
Development Environment Documentation
Documents
About The Best Formula In The World
Architecture details
Benchmarks
Books
By Reference Argument Passing
Compatibility between versions
Creating And Using Libraries
Database Datatype Mapping
Database Request Quoting
Date & time management
Dates and calendars
DBus and Gambas
Differences Between Shell And Exec
Differences From Visual Basic
Distributions & Operating Systems
Drag & Drop
DrawingArea Internal Behaviour
External functions datatype mapping
Frequently Asked Questions
Gambas Farm Server Protocol
Gambas Mailing List Netiquette
Gambas Markdown Syntax
Gambas Naming Conventions
Gambas Object Model
Gambas Scripting
Gambas Server Pages
Gambas Unit Testing
Gambas Wiki Markup Syntax
Getting Started With Gambas
Hall Of Fame
Housekeeping, cleaning up
Image Management In Gambas
Including Help Comments in Source Code
Installation from binary packages
Interpreter limits
Introduction
Just In Time Compiler
Just In Time Compiler (old version)
License
Localisation and Internationalization
Mailing Lists & Forums
Naming Conventions
Network Programming
ODBC Component Documentation
PCRE Pattern Syntax
Porting from Gambas 2 to Gambas 3
Previous News
Project Directory Structure
Release Notes
Reporting a problem, a bug or a crash
Rich Text Syntax
Screenshots
Text highlighting definition file syntax
The Program has stopped unexpectedly by raising signal #11
Variable Naming Convention
Wayland and gambas
WebPage Syntax
Web site home page
What Is Gambas?
Window & Form Management
Window Activation & Deactivation
Window Life Cycle
XML APIs
Error Messages
Gambas Playground
How To's
Language Index
Language Overviews
Last Changes
Lexicon
README
Search the wiki
To Do
Topics
Tutorials
Wiki License
Wiki Manual

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.

  • Moving a window without a border/titlebar is not possible at all. Only windows with Border = True can be moved using a mouse.

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

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

Desktop.Screenshot()

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.

So with wayland ANY use of Desktop.Screenshot() only does one thing, it opens up the screenshot dialog of the system (like you just hit the Print Screen button)

The best solution

If you cannot live without the x11 features then the only option is to install and use an x11 version of the desktop.

Your linux distribution should have x11 alternatives of the wayland desktops (for now).

Currently some Desktop variants like MATE are only x11 and do not have a wayland version.