Application title isn't reported correctly under Wayland

[freakboy3742]

Describe the bug

When running under Wayland, the GTK backend reports the app name as __main__.py, rather than the application's formal name.

Steps to reproduce

1. Run any Toga example under Wayland, rather than X Windows, using python -m myapp.

Expected behavior

The application title should report as "Tutorial 0" (or whatever the application's formal name is).

Note that this isn't the window title. The main window of the application correctly shows the formal name under Wayland; it's only the "top of screen" menubar that reports the app the currently has focus. Not all desktop environments provide this visual element; Gnome under Ubuntu and Fedora both do.

Screenshots

Correct rendering, under X

Incorrect rendering, under Wayland

Environment

• Operating System: Any Linux, running Wayland. Ubuntu 22.04 will use Wayland by default, but this can be configured.
• Python version: Any
• Software versions:
  • Toga: 0.3.1

Logs

No response

Additional context

See #1772, #1718, #1167 for previous errors reporting this problem.

[LunaMeadows]

Looked into making a PR for this but can't seem to find the right location to include the possible fix. From looking online about this error, there are 1 of 2 solutions that can be done.

1. Provide a .desktop file and run the application through the .desktop file instead of the .py file directly. This is already what is done with briefcase run and presumably build (Having issues with getting build to run on my system but that's a different issue).

2. Set the application_name with GLib.set_application_name. I have tried to use this in both window.py and app.py and can't seem to find a spot that makes it register and work. However, I also could not even make a barebones test work with that option so that may be something that is not allowed/implimented with wayland.

3. There is also mention of set.wmclass for Gtk.Window but that is both depreciated and not something that I could get working in the same vain as the last attempt.

TLDR: Given this only exists in briefcase dev or python -m myapp and the 'proper' way to give an application a title is through a .desktop file, the best option is to either make briefcase dev run through a .desktop file or wait till wayland implements a different option.

[freakboy3742]

1. Provide a .desktop file and run the application through the .desktop file instead of the .py file directly.

From a purely Toga perspective, we're not in a position to enforce this.

2. Set the application_name with GLib.set_application_name.
3. There is also mention of set.wmclass for Gtk.Window

FWIW - Toga has used both these APIs in the past, and removed them because they were either ineffective or raised deprecation warnings (this specific issue was raised directly as a result of removing the (3) implementation)

If this is something that can only be fixed at the Briefcase level (and the more I learn about Wayland, the more I'm convinced this is likely), then I'm entirely comfortable treating this as a documentation issue in Toga.

We can add a platform note to the docs for MainWindow, that highlights that the app name is outside the scope of what Wayland lets an application control; and call this issue fixed from the perspective of Toga.

If we also need to fix any issues with Briefcase (which, based on your description, sounds like might be required), we can do that separately.

[LunaMeadows]

I think adding a note on MainWindow documentation for toga is the best option if the 2 provided solutions got removed in the past. Maybe also add a way to detect if a person is running the app that way and put a warning in the terminal as well?

And it does look like the solution on briefcase usage is just making dev run a .desktop file and it should solve it. I can open that issue later when I get home if it hasn't already been done. I haven't had a lot of luck with understanding/fixing briefcase issues but can take a stab at it as well.

[freakboy3742]

I think adding a note on MainWindow documentation for toga is the best option if the 2 provided solutions got removed in the past. Maybe also add a way to detect if a person is running the app that way and put a warning in the terminal as well?

I get the inclination, but I'm not sure that's desirable here. A warning should always be actionable. It's either a bug I the code, or an indication that something could be done differently or better in some way. . This isn't going to be possible here - it's literally a case of "Wayland has Opinions (tm), and there's nothing we can do about it". We definitely need to document that these issues exist for the benefit of developers, but there's no need (IMHO) to surface them at runtime.

And it does look like the solution on briefcase usage is just making dev run a .desktop file and it should solve it. I can open that issue later when I get home if it hasn't already been done. I haven't had a lot of luck with understanding/fixing briefcase issues but can take a stab at it as well.

Running under dev always has differences to actual execution - on macOS, for example, the app presents as "python.exe", rather than the app name. If Briefcase's documentation isn't sufficiently explicit that dev is very much a development tool, and there will be differences between packaged and development behaviour, then those notes should be emphasised; but otherwise, I don't think it's worth excessive effort to make development mode be "more realistic".

[LunaMeadows]

That makes sense for not logging to the terminal about the naming issue, just a note then in the documentation and that should be sufficient in your opinion then correct?

And for briefcase, I agree. Wasn't sure by what you said before with briefcase if you were referring to dev mode or something else. If dev mode not showing the proper name is okay then everything else seemed to work in my testing on gnome Wayland. Just might want to double check packaging it up and running it to be safe which I can do when I get home.

[freakboy3742]

That makes sense for not logging to the terminal about the naming issue, just a note then in the documentation and that should be sufficient in your opinion then correct?

I think so.