Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support setting application ID for Wayland #1600

Closed
Detegr opened this issue May 7, 2022 · 4 comments · Fixed by #3007
Closed

Support setting application ID for Wayland #1600

Detegr opened this issue May 7, 2022 · 4 comments · Fixed by #3007
Labels
feature New feature or request

Comments

@Detegr
Copy link
Contributor

Detegr commented May 7, 2022

Is your feature request related to a problem? Please describe.
Applications using egui on Wayland have their app_id property set as null. As far as I can tell there is currently no way to set it.

Describe the solution you'd like
I'd like to have the window title to be used as app_id for Wayland. This looks to be as simple as calling the WindowBuilder's with_app_id function with the title string as the value.

Additional context
Some window managers, sway to name one, can make use of app_id value to detect windows of certain applications, and handle those windows in some different manner than others.

I'm willing to submit a pull request implementing this if this is something you agree would be an useful feature to have.

@Detegr Detegr added the feature New feature or request label May 7, 2022
@dimtpap
Copy link

dimtpap commented May 18, 2023

This would also allow some DEs/WMs to show an icon for the application in various places such as the title bar, if the application has provided desktop configuration files and icons

@thomaskrause
Copy link
Contributor

The winit API seems to have changed and now uses with_name when creating a window using WindowBuilder.

I hard-coded the application title with .with_name(title, "") at the end of

let mut window_builder = winit::window::WindowBuilder::new()

locally and this works in principle. I assume the hard part is to configure this source to only run on Wayland (I'm not sure if this is exposed to the eframe crate as configuration yet). I am also not sure if it is wise to re-use the application title here (which is the same as the application name currently, but will this always be the case?), or if a more specific option e.g. in eframe::NativeOptions would better.

@Detegr
Copy link
Contributor Author

Detegr commented May 18, 2023

I assume the hard part is to configure this source to only run on Wayland (I'm not sure if this is exposed to the eframe crate as configuration yet).

eframe has a wayland feature so you should be able to use #[cfg(feature = "wayland")].

I am also not sure if it is wise to re-use the application title here (which is the same as the application name currently, but will this always be the case?), or if a more specific option e.g. in eframe::NativeOptions would better.

I'm not sure about this either.

thomaskrause added a commit to thomaskrause/egui that referenced this issue May 21, 2023
This is used in the window builder to set the application ID, which is e.g. important for a proper configuration in `.desktop` files under Wayland.
When no application ID is explicitly set, it defaults to the title of the window.
thomaskrause added a commit to thomaskrause/egui that referenced this issue May 21, 2023
This is used in the window builder to set the application ID, which is e.g. important for a proper configuration in `.desktop` files under Wayland.
When no application ID is explicitly set, it defaults to the title of the window.
thomaskrause added a commit to thomaskrause/egui that referenced this issue May 21, 2023
This is used in the window builder to set the application ID, which is e.g. important for a proper configuration in `.desktop` files under Wayland.
When no application ID is explicitly set, it defaults to the title of the window.
thomaskrause added a commit to thomaskrause/egui that referenced this issue May 21, 2023
This is used in the window builder to set the application ID, which is e.g. important for a proper configuration in `.desktop` files under Wayland.
When no application ID is explicitly set, it defaults to the title of the window.
@thomaskrause
Copy link
Contributor

I added a pull request (#3007) for this, but decided against using the title as default. This would alter the behavior of existing programs, and I am uncertain if there are any limitations to application IDs that would conflict with more "weird" window titles. I used the NativeOptions instead, since there is already a macOS specific configuration value and so it makes sense to add a Wayland specific one there.

emilk added a commit that referenced this issue May 22, 2023
…3007)

* Add an optional app_id field to eframe's NativeOptions (#1600).

This is used in the window builder to set the application ID, which is e.g. important for a proper configuration in `.desktop` files under Wayland.
When no application ID is explicitly set, it defaults to the title of the window.

* Only enable NativeOptions::app_id under Linux.

The wayland feature is not sufficent as constraint and it won't compile e.g. under Windows.
While Wayland could also be used on other Unix-Systems like FreeBSD, this would probably need some specific testing. Winit uses the following definition as "wayland_platform" and on which the required packages are available:

> wayland_platform: { all(feature = "wayland", free_unix, not(wasm), not(redox)) },

* Do not use title as default application ID under Wayland.

The title might be used to also communicate state (opened file, ...) to the user and this might have unforeseen consequences for the application ID. It seems to be better to use the old behavior of not setting an application ID in this case. Also add an example on how to set the application ID in the documentation.

* Avoid as_deref(), which was a left-over of a previous version

Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>

---------

Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants