Qt/Linux: Change StartupWMClass - #13982
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Thank you for submitting a contribution to PCSX2
As this is your first pull request, please be aware of the contributing guidelines.
Additionally, as per recent changes in GitHub Actions, your pull request will need to be approved by a maintainer before GitHub Actions can run against it. You can find more information about this change here.
Please be patient until this happens. In the meantime if you'd like to confirm the builds are passing, you have the option of opening a PR on your own fork, just make sure your fork's master branch is up to date!
|
@GovanifY Can you review if you're free? I don't want to boot up linux and spend 10 minutes updating packages (I use arch, btw :^) ), to test. |
F0bes
left a comment
F0bes
left a comment
There was a problem hiding this comment.
Please change the commit so it has a prefix.
Something like Qt/Linux: Change StartupWMClass
|
@Kyuyrii Is there a reproduction case you can supply so that we could compare both old and new behavior? Like something I could do which would potentially trigger the icon not being there? To date I have not had any issues with PCSX2's icon not working properly (Arch, KDE) so I would be curious to know if there's a specific scenario at play here. |
|
This example is with MPC-QT, but the same thing happens with PCSX2. |
|
Disclaimer: This is not my wheelhouse, I am just trying to provide some feelers in hopes it might help guide things. I have a strange feeling on this one and I'd just rather throw some thoughts out in case it helps avoid a broken desktop file and more issues down the line. Equally likely I'm just wrong and completely off target. When I read that other issue the thing that stands out to me is it seems like they are suggesting that adding the namespace to the WM_CLASS property (that line in the .desktop file ends up being used as such) is making the snap version of the package recognize the icon. Particularly helpful is it seems they are using Ubuntu flavors, and the 24.xx versions if I'm not mistaken will be X11 only, the 25.xx case they mention I think will have Wayland. I think ultimately this is going to be more an issue for package maintainers to sort out, I'm not sure this is relevant to us unless people have had issues with the icon being missing on our official releases. In their case, I presume adding the namespace fixed it because a snap, like a flatpak, I presume uses a full namespace to uniquely identify the package. That in turn helps the snap understand "oh, this is a window belonging to this full name" and the WM can then more easily marry the windows to their icons and the related windows in the taskbar, etc. I don't think there's anything necessarily wrong with this change, it does make sense, the binary file is after all named
I think that regardless of (1) this change would make sense to do, provided it does not break that. But, we probably should have an answer to this question before proceeding. I think that (2) will significantly impact this. If other packaging solutions are fine, but snaps depend on this to work right, then we will need to consider the effects from (1). If changing this fixes snaps, but negatively impacts our flatpak or appimage, then we need to reconsider. |
|
I'm using Kubuntu 25.10 and Wayland. The AppImage, Flatpak, and Snap versions of PCSX2 are identified as |
|
Can @kamfretoz tell me what their plans are w.r.t. this PR. |
|
The problem was we're not really sure what My preceding changes was built on @GovanifY's one year old PR (#12328) that essentially does the same thing which is fixing the broken appimage's window associations on GNOME.. Although i have extra changes added on top of it which is to set QApplication's name and property correctly. If you want @Kyuyrii could combine @GovanifY's and my changes (but make sure to test them properly beforehand). |
5 participants
Description of Changes
Simply changing the StartupWMClass from PCSX2 to pcsx2-qt
Rationale behind Changes
This is to avoid problems in Wayland, since the WMClass used there may be different from the one used in Xorg.
In KDE using Wayland, I've seen pinned apps being considered different apps from the app they open, and some apps using the Wayland icon instead of the icon defined in the .desktop, because the StartupWMClass is incorrect or missing.
Suggested Testing Steps
Did you use AI to help find, test, or implement this issue or feature?
No