Bug 453748 - Single-instance app that's already running is not raised when activated from global launch shortcut
Summary: Single-instance app that's already running is not raised when activated from ...
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kglobalaccel
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-05-13 16:22 UTC by Nate Graham
Modified: 2022-05-18 14:33 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: Plasma 5.25 with Frameworks 5.95


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2022-05-13 16:22:18 UTC
1. Be using the Plasma Wayland session
2. Make sure you have https://invent.kde.org/plasma/systemsettings/-/merge_requests/142 applied
3. Set a global keyboard shortcut to open System Settings
4. Open System Settings via any method
5. Press your global keyboard shortcut to try to Launch System Settings again

Actual Result:
System Settings' window turns orange in the Task Manager but is not raised

Expected result:
System Settings' window is raised

Additional information:
The window is raised if you launch it from Kickoff or KRunner, just not when you launch it from a kglobalaccel global keyboard shortcut.
Comment 1 Nicolas Fella 2022-05-13 16:38:22 UTC
There's a couple of issues here:
- We use an external process (kstart5) to lauch apps in kglobalaccel, that breaks xdg-activation. Using ApplicationLauncherJob would fix that, but would introduce a dependency cycle. The cycle could be solved in multiple ways though (e.g. moving ApplicationLauncherJob to KService, which is planned in the long term, or splitting the runtime part and library of kglobalaccel)
- On Wayland the runtime part of KGlobalAccel is inside KWin. KWin's kwindowsystem impl doesn't have xdg-activation wired up. It being inside kwin is probably a good thing though, since this is quite a special case that may be tricky to handle properly in a standalone kglobalacceld process
Comment 2 Aleix Pol 2022-05-13 23:53:03 UTC
- kstart5 should just forward the token.
- getting a token for kglobalaccel should work, I'll see if we can make it the least dirty.
Comment 3 Nicolas Fella 2022-05-14 14:40:30 UTC
See https://bugs.kde.org/show_bug.cgi?id=453785 for a similar issue
Comment 5 Aleix Pol 2022-05-18 14:02:12 UTC
Git commit ce28705bc9e6e0192108382a1c6bfb4ff59fddd7 by Aleix Pol.
Committed on 16/05/2022 at 16:39.
Pushed by ngraham into branch 'master'.

Use KWindowSystem to request activation tokens if necessary

This will allow us to get activation tokens when we are starting a
process with a global shortcut.

M  +65   -30   src/runtime/kserviceactioncomponent.cpp

https://invent.kde.org/frameworks/kglobalaccel/commit/ce28705bc9e6e0192108382a1c6bfb4ff59fddd7
Comment 6 Nate Graham 2022-05-18 14:33:42 UTC
Git commit 1176f31e0d4735ee56f95e828af161eb0d3120ef by Nate Graham, on behalf of Aleix Pol.
Committed on 18/05/2022 at 13:48.
Pushed by ngraham into branch 'master'.

Support KWindowSystem interface with activation support

Allow internal uses of KWindowSystem to support activating other
clients.
Related: bug 453785

M  +33   -1    src/plugins/windowsystem/windowsystem.cpp
M  +5    -1    src/plugins/windowsystem/windowsystem.h
M  +1    -1    src/wayland_server.cpp
M  +7    -0    src/wayland_server.h
M  +23   -16   src/xdgactivationv1.cpp
M  +3    -1    src/xdgactivationv1.h

https://invent.kde.org/plasma/kwin/commit/1176f31e0d4735ee56f95e828af161eb0d3120ef