Bug 371220 - Kate aggressively activates it's window breaking minimize on show KWin rule
Summary: Kate aggressively activates it's window breaking minimize on show KWin rule
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Applications
Component: general (show other bugs)
Version: 16.08
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-19 13:15 UTC by Luis Fernando Planella Gonzalez
Modified: 2019-05-22 16:51 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
xprop output for the kate window (6.90 KB, text/plain)
2016-10-29 16:07 UTC, Luis Fernando Planella Gonzalez
Details
KWin rule for kate (218 bytes, text/plain)
2016-10-29 16:13 UTC, Luis Fernando Planella Gonzalez
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luis Fernando Planella Gonzalez 2016-10-19 13:15:24 UTC
Creating an window/application-specific rule, for an application to be initially minimized does not work.

Reproducible: Always

Steps to Reproduce:
(my system is in Brazilian Portuguese, so I'm guessing the English translations)
1. Open an application, i.e., Kate
2. Right click the window decoration. Select "More actions" > "Special application configurations"
3. On the "Size and position" tab, select "Minimized", "Apply initially", "Yes"
4. Close Kate if already running, and open it again

Actual Results:  
The Kate window is shown maximized (or whatever size it had last time)

Expected Results:  
The Kate window should be initially minimized

This is important for applications one wants to always be running, but initially minimized. I have such applications as auto-start, but I don't like KDE to remember the session, I prefer to start over with a fixed set of initial applications.
For example, I run Rambox, but it doesn't offer an option to start minimized on the application itself, and this fix is important.
Comment 1 Martin Flöser 2016-10-28 10:43:59 UTC
I just tried with kwrite and it worked just fine.

Can you share a rule for a window which is affected and also the xprop output of such a window?
Comment 2 Luis Fernando Planella Gonzalez 2016-10-29 16:07:39 UTC
Created attachment 101879 [details]
xprop output for the kate window
Comment 3 Luis Fernando Planella Gonzalez 2016-10-29 16:13:19 UTC
Created attachment 101880 [details]
KWin rule for kate
Comment 4 Luis Fernando Planella Gonzalez 2016-10-29 16:14:08 UTC
Here are the requested attachments.
It is a simple kate window, and the rule just have the initial minimized state to yes.
Comment 5 Martin Flöser 2016-10-31 13:27:23 UTC
I just changed the rule I had from kwrite to kate, installed kate and gave it a try. And it does not work for kate. The same rule works for kwrite.
Comment 6 Martin Flöser 2016-10-31 13:53:38 UTC
This is not a bug in KWin. KWin works as expected and does minimize the window initially (I verified by adjusting KWin code). But Kate performs a very aggressive "activate me", which results in KWin showing the window again.

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

    win->show();
    win->activateWindow();
    win->raise();

    KWindowSystem::forceActiveWindow(win->winId());
    KWindowSystem::raiseWindow(win->winId());
    KWindowSystem::demandAttention(win->winId());
}

So Kate shows the window, activates it and raises it. And then force activates it, raises it again and also demands attention. It looks like Kate devs try really hard to make sure Kate gets activated. I'm going to quote the documentation of forceActiveWindow:

"Note that this should be called only in special cases, applications shouldn't force themselves or other windows to be the active window. Generally, this call should used only by pagers and similar tools."

Could Kate try to be less aggressive for window showing? In general KWin will activate new windows and I'm wondering why it needs to be that aggressive. Especially the demandsAttention call looks to me like that Kate just tries everything to be active. DemandsAttention is a state not available to active windows: so after the force activate it doesn't make any sense to demand attention. It has all the attention it can get. Furthermore if a window manager refuses activation it will set it to demandsAttention by itself.
Comment 7 Luis Fernando Planella Gonzalez 2016-10-31 14:40:01 UTC
Ok, I first found this with Rambox, then I wanted to confirm it and tried kate.
Looks like both applications did this aggressive "activate me", and I was unlucky with the examples :)
Anyhow, later on I found the "Start minimized" option in Rambox, but the good thing is that it indeed revealed (minor) issue with kate.
Comment 8 Christoph Cullmann 2017-06-25 12:04:54 UTC
I think we went on that agressive rampage for the activation as we got issues in the past that you opened a new document e.g. from a terminal with "kate test.txt" and the already existing kate instance stayed in the background instead of getting raised (and people wondered why nothing happens).

Which calls should we use and which should go away for that usecase?
Comment 9 Christoph Cullmann 2018-08-17 20:21:52 UTC
Git commit 4dded43bcdc57281276f11d0fec05f93ce41c49e by Christoph Cullmann.
Committed on 17/08/2018 at 20:21.
Pushed by cullmann into branch 'master'.

remove forceful window activation

use the same sequence as QtSingleApplication

M  +7    -7    kate/kateapp.cpp
M  +3    -6    kate/kateappadaptor.cpp

https://commits.kde.org/kate/4dded43bcdc57281276f11d0fec05f93ce41c49e