[kwin] [Bug 404643] Launching a second instance of single-instance application doesn't give focus to the running instance at Low or higher focus stealing prevention level
https://bugs.kde.org/show_bug.cgi?id=404643 Martin Flöser changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED --- Comment #1 from Martin Flöser --- We use regular X11 Startup notifications. Please implement the according standard. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 404643] Launching a second instance of single-instance application doesn't give focus to the running instance at Low or higher focus stealing prevention level
https://bugs.kde.org/show_bug.cgi?id=404643 --- Comment #2 from Igor Kushnir --- Do you mean that each non-KDE single-instance application should contain a duplicate KWindowSystemPrivateX11::forceActiveWindow() implementation (https://code.woboq.org/qt5/kf5/kwindowsystem/src/platforms/xcb/kwindowsystem.cpp.html#_ZN23KWindowSystemPrivateX1117forceActiveWindowEyl) and possibly KStartupInfo::setNewStartupId() implementation (https://api.kde.org/frameworks/kwindowsystem/html/kstartupinfo_8cpp_source.html#l00778) in order to get focus with default Plasma Window Management settings? Are you sure that there is no bug in KWin? Shouldn't KWin activate windows without "support for the underlying mechanism" at Low focus stealing prevention level as the option's documentation states? Note that currently a very low percentage of non-KDE windows (15% of those I've tested) gets focus if the already running instance is visible. And at least some of those ~15% get focus due to hackish workarounds rather than the according standard implementation. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 404643] Launching a second instance of single-instance application doesn't give focus to the running instance at Low or higher focus stealing prevention level
https://bugs.kde.org/show_bug.cgi?id=404643 David Edmundson changed: What|Removed |Added CC||k...@davidedmundson.co.uk --- Comment #3 from David Edmundson --- They should not contain a fork of forceActiveWindow. See https://www.freedesktop.org/wiki/Software/startup-notification/ >How should non-KDE, pure-Qt, single-instance applications request focus on >second instance launch to get it in all Plasma versions? Pass the startup ID to the second instance. See QX11Info::setNextStartupId() then calling activate will "just work" -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 404643] Launching a second instance of single-instance application doesn't give focus to the running instance at Low or higher focus stealing prevention level
https://bugs.kde.org/show_bug.cgi?id=404643 --- Comment #4 from Igor Kushnir --- > >How should non-KDE, pure-Qt, single-instance applications request focus on > >second instance launch to get it in all Plasma versions? > > Pass the startup ID to the second instance. See QX11Info::setNextStartupId() > then calling activate will "just work" 1. When an application is launched from terminal, it gets an empty QX11Info::nextStartupId(). So this simple implementation can't work as well as KDE applications in this case. 2. Even when I pass a nonempty QX11Info::nextStartupId() from the secondary instance, then pass it to QX11Info::setNextStartupId() in the primary instance, then activate the primary instance's main window, it still doesn't get focus if it is not minimized/hidden. So I haven't noticed any effect of the simple implementation. I use QtSingleApplication to pass messages between instances. Code that runs in the primary instance: QByteArray startupId = QByteArray::fromBase64(receivedBase64EncodedId); qCritical() << startupId; QX11Info::setNextStartupId(startupId); qApp->setActiveWindow(this); raise(); activateWindow(); A typical received id in a KDE neon VM is "KDE-neon-VM;1551168703;784674;950_TIME254792". I tried removing the "qApp->setActiveWindow(this)" line, reordering "raise()" and "activateWindow()" lines; setting StartupNotify both to true and false in the application desktop file. But nothing makes a difference. Does the secondary instance have to explicitly send the "remove" message to end the launch sequence as described in https://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 404643] Launching a second instance of single-instance application doesn't give focus to the running instance at Low or higher focus stealing prevention level
https://bugs.kde.org/show_bug.cgi?id=404643 --- Comment #5 from Martin Flöser --- I recommend using existing libraries like KRun in combination with KWindowsystem to achieve this. Way better solution than trying to reinvent the wheel. Also I recommend to remove everything where you try to activate or raise. That's where the window manager kicks in. If you get the startup notification done the window manager will ensure the window has focus and it's raised. That's his damn job. If you try to raise or active the window manager recognizes an attempt to steal focus and prevent it - that's also his damn job. Also ensure your user time stamps are up to date. That helps a lot. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 404643] Launching a second instance of single-instance application doesn't give focus to the running instance at Low or higher focus stealing prevention level
https://bugs.kde.org/show_bug.cgi?id=404643 --- Comment #6 from Igor Kushnir --- > I recommend using existing libraries like KRun in combination with > KWindowsystem to achieve this. Way better solution than trying to reinvent > the wheel. KRun is part of KIO - a tier 3 framework with complex dependencies. Few non-KDE applications would want to depend on it. Reinventing the wheel also doesn't belong to application code. No wonder that so few independent apps support the startup notification standard. This standard has to be implemented in widely used cross-platform frameworks, such as Qt, in order to increase adoption. Or at least in cross-platform, lightweight, easy-to-use libraries, such as QtSingleApplication. -- You are receiving this mail because: You are watching all bug changes.