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.

Sign up for GitHub

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

Jump to bottom

Linux .desktop file improvements #12707

Closed
1 of 3 tasks
jansol opened this issue Jun 5, 2024 · 4 comments
Closed
1 of 3 tasks

Linux .desktop file improvements #12707

jansol opened this issue Jun 5, 2024 · 4 comments
Labels
enhancement [core label] linux

Comments

@jansol
Copy link
Contributor

jansol commented Jun 5, 2024 •
edited
Loading

Check for existing issues

  • Completed

Describe the feature

EDIT: incorporated clarifications from @ReillyBrogan . StartupWMClass is not needed if the wayland app id (and therefore the file name) is identical to the WM_CLASS on X11. This is already the case, so no action is needed on that front.
@jansol jansol added admin read Pending admin review enhancement [core label] triage Maintainer needs to classify the issue labels Jun 5, 2024
@github-actions github-actions bot mentioned this issue Jun 6, 2024
Open
@Moshyfawn
Copy link
Member

I seem to remember the app_id proposal that was resolved in #10909. Does this satisfy your second point?

@Moshyfawn Moshyfawn added needs info / awaiting response Issue that needs more information from the user linux and removed triage Maintainer needs to classify the issue labels Jun 7, 2024
@jansol
Copy link
Contributor Author

jansol commented Jun 7, 2024

The 2nd point is about also having that app id stated in the .desktop file.

@Moshyfawn Moshyfawn removed the needs info / awaiting response Issue that needs more information from the user label Jun 7, 2024
@github-actions github-actions bot mentioned this issue Jun 8, 2024
Open
@JosephTLyons JosephTLyons removed the admin read Pending admin review label Jun 9, 2024
@jansol jansol mentioned this issue Jun 12, 2024
Closed
13 tasks
@ReillyBrogan
Copy link

It seems that you are a bit mistaken about how some of the .desktop FreeDesktop standards work.

The 2nd point is about also having that app id stated in the .desktop file.

The StartupWMClass is ONLY for the X11 window class (it even has WMClass in the name which is an X11-only concept). If the Wayland appId and the X11 resource class are different then the .desktop file should be named after the Wayland app_id and the StartupWMClass should be the X11 resource class to be compliant with the standards.

The name of the .desktop file MUST match the Wayland appId sans the .desktop suffix. If the Wayland appId is dev.zed.Zed then the .desktop filename MUST be dev.zed.Zed.desktop. This is an explicit part of the FreeDesktop standards.

If the Wayland appId and the X11 resource class are the same then the StartupWMClass can be omitted from the .desktop file.

You may be using GNOME desktop which adds the value of the StartupWMClass field to the search path for matching Wayland windows via their appId. This is technically non-compliant with the FreeDesktop standards but it does some windows matched that would otherwise not be due to packaging mistakes which is why they did it. No other window manager or compositor implements this behavior. Frankly it's a mistake that has harmed the ecosystem as people see apps that are correctly matched on GNOME that don't work on Plasma or other DEs/WMs who then think that there is an issue with the other DE/WM when they should be reporting it to the app developers/package maintainers. If it's fixed in a compliant way it works for ALL Wayland DEs/WMs, instead of only working on GNOME.

@jansol
Copy link
Contributor Author

jansol commented Jun 15, 2024

Ooh, thanks for the clarification @ReillyBrogan !

@ReillyBrogan ReillyBrogan mentioned this issue Jun 17, 2024
Merged
@jansol jansol mentioned this issue Jul 4, 2024
Merged
@jansol jansol closed this as completed Jul 5, 2024
ReillyBrogan added a commit to ReillyBrogan/dosbox-staging that referenced this issue Jul 11, 2024
@ReillyBrogan
Centralize app_id handling
dce2e47 
On modern Linux it is preferred to use the fully qualified application ID for naming the desktop, icon, and metainfo files. Add a meson option to capture this variable and set it to `org.dosbox-staging.Dosbox-staging` which better matches that the homepage is dosbox-staging.org.

Then ensure that we're setting the X11 `resourceclass` and the Wayland app_id to this value. Those values need to match the name of the .desktop file in order for compositors/window managers to correctly associate windows to the appropriate .desktop file (see [here](zed-industries/zed#12707 (comment)) for an explanation I previously wrote on how that works). Now that we're ensuring that both X11 and Wayland should have correct window associations we can drop `StartupWMClass` from the desktop file as it is now unnecessary.

Also, since SDL3 changed how that is done I added some #if statements so that that's ready whenever dosbox-staging is ported to SDL3.

Signed-off-by: Reilly Brogan <reilly@reillybrogan.com>
@ReillyBrogan ReillyBrogan mentioned this issue Jul 11, 2024
Closed
10 tasks
ReillyBrogan added a commit to ReillyBrogan/dosbox-staging that referenced this issue Jul 13, 2024
@ReillyBrogan
Centralize app_id handling
94842e6 
On modern Linux it is preferred to use the fully qualified application ID for naming the desktop, icon, and metainfo files. Add a meson option to capture this variable and set it to `org.dosbox-staging.DOSBoxStaging` which better matches that the homepage is dosbox-staging.org.

Then ensure that we're setting the X11 `resourceclass` and the Wayland app_id to this value. Those values need to match the name of the .desktop file in order for compositors/window managers to correctly associate windows to the appropriate .desktop file (see [here](zed-industries/zed#12707 (comment)) for an explanation I previously wrote on how that works). Now that we're ensuring that both X11 and Wayland should have correct window associations we can drop `StartupWMClass` from the desktop file as it is now unnecessary.

Also, since SDL3 changed how that is done I added some #if statements so that that's ready whenever dosbox-staging is ported to SDL3.

Signed-off-by: Reilly Brogan <reilly@reillybrogan.com>
FeralChild64 added a commit to dosbox-staging/dosbox-staging that referenced this issue Aug 3, 2024
@FeralChild64
On modern Linux it is preferred to use the fully qualified applicatio…
5214ecd 
…n ID for naming the desktop, icon, and metainfo files. Add a meson option to capture this variable and set it to `org.dosbox-staging.DOSBoxStaging` which better matches that the homepage is dosbox-staging.org.

Then ensure that we're setting the X11 `resourceclass` and the Wayland app_id to this value. Those values need to match the name of the .desktop file in order for compositors/window managers to correctly associate windows to the appropriate .desktop file (see [here](zed-industries/zed#12707 (comment)) for an explanation). Now that we're ensuring that both X11 and Wayland should have correct window associations we can drop `StartupWMClass` from the desktop file as it is now unnecessary.

Also, since SDL3 changed how that is done some #if statements were added so that that's ready whenever dosbox-staging is ported to SDL3.

Co-authored--by: Reilly Brogan <reilly@reillybrogan.com>
FeralChild64 added a commit to dosbox-staging/dosbox-staging that referenced this issue Aug 3, 2024
@FeralChild64 @ReillyBrogan
On modern Linux it is preferred to use the fully qualified applicatio…
6bcc244 
…n ID for naming the desktop, icon, and metainfo files. Add a meson option to capture this variable and set it to `org.dosbox-staging.DOSBoxStaging` which better matches that the homepage is dosbox-staging.org.

Then ensure that we're setting the X11 `resourceclass` and the Wayland app_id to this value. Those values need to match the name of the .desktop file in order for compositors/window managers to correctly associate windows to the appropriate .desktop file (see [here](zed-industries/zed#12707 (comment)) for an explanation). Now that we're ensuring that both X11 and Wayland should have correct window associations we can drop `StartupWMClass` from the desktop file as it is now unnecessary.

Also, since SDL3 changed how that is done some #if statements were added so that that's ready whenever dosbox-staging is ported to SDL3.

Co-authored-by: Reilly Brogan <reilly@reillybrogan.com>
FeralChild64 added a commit to dosbox-staging/dosbox-staging that referenced this issue Aug 3, 2024
@FeralChild64 @ReillyBrogan
On modern Linux it is preferred to use the fully qualified applicatio…
7c659bb 
…n ID for naming the desktop, icon, and metainfo files. Add a meson option to capture this variable and set it to `org.dosbox-staging.DOSBoxStaging` which better matches that the homepage is dosbox-staging.org.

Then ensure that we're setting the X11 `resourceclass` and the Wayland app_id to this value. Those values need to match the name of the .desktop file in order for compositors/window managers to correctly associate windows to the appropriate .desktop file (see [here](zed-industries/zed#12707 (comment)) for an explanation). Now that we're ensuring that both X11 and Wayland should have correct window associations we can drop `StartupWMClass` from the desktop file as it is now unnecessary.

Also, since SDL3 changed how that is done some #if statements were added so that that's ready whenever dosbox-staging is ported to SDL3.

Co-authored-by: Reilly Brogan <reilly@reillybrogan.com>
@FeralChild64 FeralChild64 mentioned this issue Aug 3, 2024
Merged
10 tasks
FeralChild64 added a commit to dosbox-staging/dosbox-staging that referenced this issue Aug 4, 2024
@FeralChild64 @ReillyBrogan
On modern Linux it is preferred to use the fully qualified applicatio…
d643461 
…n ID for naming the desktop, icon, and metainfo files. Add a meson option to capture this variable and set it to `org.dosbox-staging.DOSBoxStaging` which better matches that the homepage is dosbox-staging.org.

Then ensure that we're setting the X11 `resourceclass` and the Wayland app_id to this value. Those values need to match the name of the .desktop file in order for compositors/window managers to correctly associate windows to the appropriate .desktop file (see [here](zed-industries/zed#12707 (comment)) for an explanation). Now that we're ensuring that both X11 and Wayland should have correct window associations we can drop `StartupWMClass` from the desktop file as it is now unnecessary.

Also, since SDL3 changed how that is done some #if statements were added so that that's ready whenever dosbox-staging is ported to SDL3.

Co-authored-by: Reilly Brogan <reilly@reillybrogan.com>
FeralChild64 added a commit to dosbox-staging/dosbox-staging that referenced this issue Aug 5, 2024
@FeralChild64 @ReillyBrogan
On modern Linux it is preferred to use the fully qualified applicatio…
3a527c1 
…n ID for naming the desktop, icon, and metainfo files. Add a meson option to capture this variable and set it to `org.dosbox-staging.DOSBoxStaging` which better matches that the homepage is dosbox-staging.org.

Then ensure that we're setting the X11 `resourceclass` and the Wayland app_id to this value. Those values need to match the name of the .desktop file in order for compositors/window managers to correctly associate windows to the appropriate .desktop file (see [here](zed-industries/zed#12707 (comment)) for an explanation). Now that we're ensuring that both X11 and Wayland should have correct window associations we can drop `StartupWMClass` from the desktop file as it is now unnecessary.

Also, since SDL3 changed how that is done some #if statements were added so that that's ready whenever dosbox-staging is ported to SDL3.

Co-authored-by: Reilly Brogan <reilly@reillybrogan.com>
johnnovak pushed a commit to dosbox-staging/dosbox-staging that referenced this issue Aug 6, 2024
@FeralChild64 @ReillyBrogan @johnnovak
On modern Linux it is preferred to use the fully qualified applicatio…
9fdba5f 
…n ID for naming the desktop, icon, and metainfo files. Add a meson option to capture this variable and set it to `org.dosbox-staging.DOSBoxStaging` which better matches that the homepage is dosbox-staging.org.

Then ensure that we're setting the X11 `resourceclass` and the Wayland app_id to this value. Those values need to match the name of the .desktop file in order for compositors/window managers to correctly associate windows to the appropriate .desktop file (see [here](zed-industries/zed#12707 (comment)) for an explanation). Now that we're ensuring that both X11 and Wayland should have correct window associations we can drop `StartupWMClass` from the desktop file as it is now unnecessary.

Also, since SDL3 changed how that is done some #if statements were added so that that's ready whenever dosbox-staging is ported to SDL3.

Co-authored-by: Reilly Brogan <reilly@reillybrogan.com>
@jansol jansol mentioned this issue Aug 6, 2024
Closed
johnnovak pushed a commit to dosbox-staging/dosbox-staging that referenced this issue Aug 8, 2024
@FeralChild64 @ReillyBrogan @johnnovak
On modern Linux it is preferred to use the fully qualified applicatio…
d78ab09 
…n ID for naming the desktop, icon, and metainfo files. Add a meson option to capture this variable and set it to `org.dosbox-staging.DOSBoxStaging` which better matches that the homepage is dosbox-staging.org.

Then ensure that we're setting the X11 `resourceclass` and the Wayland app_id to this value. Those values need to match the name of the .desktop file in order for compositors/window managers to correctly associate windows to the appropriate .desktop file (see [here](zed-industries/zed#12707 (comment)) for an explanation). Now that we're ensuring that both X11 and Wayland should have correct window associations we can drop `StartupWMClass` from the desktop file as it is now unnecessary.

Also, since SDL3 changed how that is done some #if statements were added so that that's ready whenever dosbox-staging is ported to SDL3.

Co-authored-by: Reilly Brogan <reilly@reillybrogan.com>
@notpeter notpeter mentioned this issue Nov 14, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement [core label] linux
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jansol @ReillyBrogan @Moshyfawn @JosephTLyons