[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

2019-02-21 Thread Martin Flöser
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

2019-02-21 Thread Igor Kushnir
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

2019-02-21 Thread David Edmundson
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

2019-02-26 Thread Igor Kushnir
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

2019-02-26 Thread Martin Flöser
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

2019-02-27 Thread Igor Kushnir
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.