Bug 407288

Can confirm the behavior on Linux too, on both Manjaro (Kate 19.04.0) and KDE Neon dev unstable (Kate from git master).

*** Bug 407286 has been marked as a duplicate of this bug. ***

We do this in the code:


void KateAppAdaptor::activate()
{
    KateMainWindow *win = m_app->activeKateMainWindow();
    if (!win) {
        return;
    }

    // like QtSingleApplication
    win->setWindowState(win->windowState() & ~Qt::WindowMinimized);
    win->raise();
    win->activateWindow();
}

Before we were more "foreful", this got removed in bug 371220

I think what's happening here is that KWin is ignoring the non-forceful request to raise the window because of some issue with the way the call is structured or how Kate is activated. KWin requires that it be done in a very specific way or else activateWindow() doesn't work. CCing some KWin developers who can shed more light on the situation.

This is the only thing that works for me:

+
+    // try to raise window, see bug 407288
+    KWindowSystem::raiseWindow(win->winId());

but the documentation states only pagers should use that.

Git commit 7ecdd0eaf94b3bba392f547a15594fb389e75f30 by Christoph Cullmann.
Committed on 24/05/2019 at 13:36.
Pushed by cullmann into branch 'master'.

try a bit harder to raise window for already running application

M  +2    -6    kate/kateapp.cpp
M  +3    -0    kate/kateappadaptor.cpp

https://commits.kde.org/kate/7ecdd0eaf94b3bba392f547a15594fb389e75f30

I commited now the aggressive variant.
That at least works here reasonable well, even if you open a file, hide the window, open the same file again from some konsole via "kate ...".
All other calls didn't to the trick for that.

Thanks! Is this backportable to the stable branch?

If somebody wants to cherry-pick that, feel free.
I am not sure if that is the right way to fix it thought, given the docs state one shall not use that method for what we do :=)

Some of the KWin developers may be able to help. I'll see if I can make them aware.

There's info on how to activate windows here https://phabricator.kde.org/D16648#450590

That means I should try

    KStartupInfo::setNewStartupId(win(), KStartupInfo::startupId());
    KWindowSystem::activateWindow(win()->effectiveWinId());

instead of 

    KWindowSystem::raiseWindow(win->winId());

?

Worth a try, at least. :)

There is another addition proposed here:
https://phabricator.kde.org/D21485

Git commit 18b05cb14bddfc1568d3082dfd862c62bcf77440 by Sergio Martins.
Committed on 30/05/2019 at 19:18.
Pushed by smartins into branch 'master'.

Fix window activation on Windows

Windows doesn't use the dbus stuff and instead uses qtsingleapplication,
which does support window activation if setActivationWindow is called.

setActivationWindow wasn't called anywhere.

Differential Revision: 21485

M  +4    -0    kate/main.cpp

https://commits.kde.org/kate/18b05cb14bddfc1568d3082dfd862c62bcf77440

> KStartupInfo::setNewStartupId(window(), KStartupInfo::startupId());
> KWindowSystem::activateWindow(window()->effectiveWinId());
Works for Dolphin so it should work for Kate too.

Git commit fd101540c21847df6df90cb6c546f6fdf92b74f6 by Christoph Cullmann.
Committed on 14/07/2019 at 11:58.
Pushed by cullmann into branch 'master'.

use same code as dolphin for window raising
works fine for me, too, even for minimized windows

M  +4    -1    kate/kateappadaptor.cpp

https://commits.kde.org/kate/fd101540c21847df6df90cb6c546f6fdf92b74f6

*** Bug 409677 has been marked as a duplicate of this bug. ***

I have installed Kate 23.04.3 in Windows 11 Enterprise (Version 21H2, OS build 22000.2176) and found that this bug has occurred again. If I double-click on a text file in Windows File Explorer, then Kate will open that file in the foreground as it should. If I then bring File Explorer to the foreground and double-click a different text file, that file will open in Kate, but Kate will remain in the background.

Yeah, doesn't work as it should.

We do now


void KateAppAdaptor::activate(const QString &token)
{
    KateMainWindow *win = m_app->activeKateMainWindow();
    if (!win) {
        return;
    }

    // like QtSingleApplication
    win->setWindowState(win->windowState() & ~Qt::WindowMinimized);
    win->raise();
    win->activateWindow();

    // try to raise window, see bug 407288
    if (KWindowSystem::isPlatformX11()) {
#if HAVE_X11
        KStartupInfo::setNewStartupId(win->windowHandle(), token.toUtf8());
#endif
    } else if (KWindowSystem::isPlatformWayland()) {
        KWindowSystem::setCurrentXdgActivationToken(token);
    }

    KWindowSystem::activateWindow(win->windowHandle());
}

that still is not enough, I would assume that is the same issue as on Wayland, Windows just doesn't allow for the window to be raised, one just gets the notification in the task bar.

I don't think we can fix that, like on Wayland the security mechanism to avoid focus stealing and Co. don't allow for that.

It's definitely possible to fix on Wayland, you just have to handle the activation token properly. I'm CCing some people who know how to do this.

(In reply to Nate Graham from comment #23)
> It's definitely possible to fix on Wayland, you just have to handle the
> activation token properly. I'm CCing some people who know how to do this.

If I start Kate it the terminal with

kate xxx.txt

I fail to see what I should send over via dbus to the main instance.

But if that is feasible on Wayland, help is welcome.

This bug is a bit confusing, it's originally for Microsoft Windows but it seems to have mutated?

On Wayland, if it's not working with Krusader or whatever, we need to have the application adapted to produce a token that will be handed over.

In the case of Konsole, we are not doing that because konsole (bash?) doesn't have a way to create this token. We should make Konsole create the environment variable that communicates the token. As such it's a Konsole bug, not Kate's.

Kate works fine, that's why it works when launched from an app that does the right thing, like dolphin.

(In reply to Aleix Pol from comment #25)
> This bug is a bit confusing, it's originally for Microsoft Windows but it
> seems to have mutated?
> 
> On Wayland, if it's not working with Krusader or whatever, we need to have
> the application adapted to produce a token that will be handed over.
> 
> In the case of Konsole, we are not doing that because konsole (bash?)
> doesn't have a way to create this token. We should make Konsole create the
> environment variable that communicates the token. As such it's a Konsole
> bug, not Kate's.
> 
> Kate works fine, that's why it works when launched from an app that does the
> right thing, like dolphin.

Ok, if for Wayland Kate is fine, we can close this. At least for Windows I found no proper way to make it work.

Thanks for taking a look at this @aleix!

Ah in that case the issue is Bug 442265.

Looks like it's my bad that this mutated back in 2019 from a Windows bug into a Wayland bug. Sorry about that.