Wayland doesn't allow setting or getting Window.Left and Window.Top

Targets Linux
1

As I’ve been expanding my testing beyond the Ubuntu Bubble (which includes Mint), I found that I was getting weird window placement on all the other distros. It took me awhile, but I finally figured that the common denominator was that all the other distros were using Wayland, not X11, as the window server. I confirmed this to be the issue when I reconfigured Debian 10 “Buster” to use the latter, and the project ran as expected.

I have made a Feedback case with a sample project:
<https://xojo.com/issue/58937>

In the sample project, all of my windows have labels stating their opening Top and Left values. It is interesting that, while the windows are scattered willy-nilly when opening in Wayland, they nonetheless seem to think they’re in the right place.

2

I’ve tested your example with a default installation of “Debian 10.2 64Bit”.

  • Main Window shows up somewhere (but not centered as one would expect)
  • Left/Right Windows don’t open where one would expect them to open

In the mean time, a not quite nice workaround:
while in Wayland, you can force an application to use the x11 backend:

In Terminal, launch the application like this:

export GDK_BACKEND=x11 ./MyApplication

Note: If you run the ‘Remote Debugger’ like this, then the Remote-Debug-runned application will inherit that from the RemoteDebugger.

With the GDK_BACKEND set to x11, positioning will work as expected.

Unfortunately, I don’t know if it’s possible to change this within the Xojo-built application once it’s already launched…

Edit: Read more about that Environment Variable here: https://developer.gnome.org/gtk3/stable/gtk-running.html

3

I suppose I could include a shell script and ask the user to launch from that. But that’s definitely a kludge. :slight_smile:

4

Thanks Jürg, that worked for me on CentOS 8. But yeah, not pretty.

5

[quote=472705:@Jürg Otter]Unfortunately, I don’t know if it’s possible to change this within the Xojo-built application once it’s already launched…

[/quote]

Well, for fun I tried running the shell command in App.Open. No go.

6

While still a kludge but maybe a nicer one would be create an application that has no ui and simply launches the actual app using shell to run the script.

7

I’m looking at that now, but I’m whipped :slight_smile:

8

This simple shell script, based on Jürg’s help both here and privately, when included in the application folder, works for me on CentOS, Debian, Fedora and openSUSE. Presumably I could include a helper app, as Wayne says, to run it.

[code]#!/usr/bin/sh

export GDK_BACKEND=x11
./“My Program Name”
exit 0[/code]

The outlier VMs are my Ubuntus (Ubunti?) and Mint, where sh instead lives in /bin. But they’re X11 so I don’t need this there anyway.

9

I still think this is just a hacky workaround… it just shows that it’s in fact a “Xojo | Wayland” issue. And forcing x11 shows the expected results. But we don’t want to force that upon our users, do we?

I hope that Xojo looks at <https://xojo.com/issue/58937>, allowing Xojo built apps to position Windows/Dialogs on current Linux Distributions.

Or is there some other way? Maybe one could use some Declare to set a Window’s position - so that it works with Wayland?
I’ve quickly tried, but without success…

10

Agreed. As Wayne suggested, I did build a simple windowless app, to include in the main app folder, which
the user can double-click to run the shell script. But right now I have “Kludge” in its name. :slight_smile:

11

[quote=472715:@Jerry Fritschle]Well, for fun I tried running the shell command in App.Open. No go.
[/quote]
As you’ve probably determined by now, you must set that GDK_BACKEND var BEFORE the app is launched.

12

Yes, I got the result I expected. Hence, if you read further in the thread, the kludgy workaround shell script (and app to run it) that I put in. Meanwhile, I’m still waiting for Xojo to look at the feedback case. My workaround “fixes” nothing :slight_smile:

13

Another option is to add the GDK_BACKEND=x11 to the start of the Exec line in your app’s .desktop file:

Exec=GDK_BACKEND=x11 "/opt/ArGest Backup/ArGest Backup"

This way, the end user doesn’t need to do anything except launch via the icon. And, it’s not a kludge or workaround since that is what the option is designed for.

14

Well, it’s a kludge in the sense that we even have to resort to this or anything in Wayland, under which the app works in all other respects. Hence the Feedback case. My original post was about the bug but in the thread we’ve been focused on the workaround. Otherwise I would have marked this “answered” by now. :slight_smile:

15

Xojo apps are not the only apps affected by this issue in Wayland and therefore, it’s not a bug in Xojo. The fact that we have the GDK_BACKEND environment variable as an option indicates that it’s known that standard X11-based apps can run into Wayland-related problems. Think of it in much the same way that we have she-bang options in shell scripts and other scripted languages - If you want the script to run in bash, you tell the kernel via #!/bin/bash as the first line in the script. That way, no matter what shell the user uses (zsh, csh, ash, etc.), the script is launched under the bash shell environment.

That you don’t see the environment variable that was created explicitly for this purpose as your solution does not mean that it’s not the solution for the rest of us.

16

Thanks, Tim. As I understand this better, I’ll just relax and go the “it’s a feature, not a bug” route. :slight_smile:

What’s funny is how much effort I’m putting into Linux support. This is a cross platform application, a customized FTP/SFTP client, in which the end users are “my” customers’ clients. My Mac and Windows versions come in signed/notarized installers. The Linux one is just an “unzip and put where you want” thing. I’ve mostly supported Linux “because I can”, but have redoubled my efforts here when finding that at least one client DOES have Linux users. A big help was the modGTK project, and I am eminently grateful to those in the community who contributed to that.

Here’s where it got obsessive. I decided to create a larger VM farm, to check out more distros. This introduced me to the Wayland issue (once I figured out what it was), as well as which distros would likely need the user to pro-actively install gtk+3 and/or libunwind (also libwebkitgtk in my app’s case; for my windows with HTMLviewers, I have an exception handler that alerts the user to its absence.) Jürg got me pointed the right direction for dealing with Wayland.

Obsessive? Well, besides that Ubuntu/Mint “bubble”, I’ve now tested against Arch, Debian, CentOS, Fedora, Gentoo, OpenSUSE and Slackware.

Again, it’s a very high per-capita effort, for the number of Linux users I probably really have. But man, am I learning a lot about Linux by doing this! Perhaps it’s second nature to you, but I’m darned proud that I managed to build Arch and Gentoo! :slight_smile:

Thank you again, Tim and everyone.

Edit: Tim, thanks particularly for the advice on the .desktop file!

17

Tim, if you’re still reading, I got that .desktop file going. I just had to modify your suggestion to

exec=env GDK_BACKEND=x11 /path/to/app

Thank you so much. It has been like getting at least an undergraduate course in Linux, fiddling with this. I’m in my 60s now so I guess one is never too old. :slight_smile:

18

I’m hitting 61 myself :D. The day I “stop” learning is the day that they’re tossing my ashes off of Wailea Point!

Yes - sorry my typed entry should have been copied and pasted :). My .desktop files have the env part, as well.

Also, what you’re learning about Linux can also apply in theory to the real backend of the macOS platform.