Bug 348083 - Hidden modal tool windows for inactive applications never reappear
Summary: Hidden modal tool windows for inactive applications never reappear
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/123...
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-21 18:48 UTC by Karl-Johan Karlsson
Modified: 2015-06-10 07:42 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
thomas.luebking: ReviewRequest+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Karl-Johan Karlsson 2015-05-21 18:48:49 UTC
This came up when testing Valentina (http://www.valentina-project.org/), a Qt-based sewing pattern drawing application. Downstream bug report in the URL above.

If Configure -> Advanced -> Hide utility windows for inactive applications is true, an application creates a window which is both a tool window and modal, and the application loses focus, there is now no way to restore focus to the application. The main window refuses input, and the modal tool window which would accept input is hidden.

Reproducible: Always

Steps to Reproduce:
Minimal reproducer:

#include <QApplication>
#include <QMainWindow>
#include <QDialog>

int main(int argc, char **argv)
{
   QApplication bug(argc, argv);

   QMainWindow window;
   window.resize(100, 100);
   window.show();

   QDialog dialog(&window);
   dialog.setWindowFlags(Qt::Tool);
   dialog.setModal(true);
   dialog.show();

   return bug.exec();
}

Make sure "Hide utility windows for inactive applications" is true. The program creates a main window and a modal tool window. Move focus away, and the tool window disappears. The main window does not accept input, and there is no way to make the tool window reappear.



This is KWin 4.11.19, which was not in the list.
Comment 1 Thomas Lübking 2015-05-21 20:28:41 UTC
valentina bug:
https://bitbucket.org/dismine/valentina/issue/303/

Out of curiosity:
What (tf ;-) is the reasoning behind making a utility window modal?

I mean, this is absolutely a bug in KWin (the modal window could be hidden for other reasons than being minimized or another virtual desktop) but the particular example is really weird and rather smells like a (usability) bug in valentina, because a modal (dialog) window and a utility window are contradicting concepts (and the NETWM spec even explicitly states that the utility window is *not* meant to be a transient dialog)
Comment 2 Roman 2015-05-22 05:20:12 UTC
(In reply to Thomas Lübking from comment #1)
> valentina bug:
> https://bitbucket.org/dismine/valentina/issue/303/
> 
> Out of curiosity:
> What (tf ;-) is the reasoning behind making a utility window modal?
> 
> I mean, this is absolutely a bug in KWin (the modal window could be hidden
> for other reasons than being minimized or another virtual desktop) but the
> particular example is really weird and rather smells like a (usability) bug
> in valentina, because a modal (dialog) window and a utility window are
> contradicting concepts (and the NETWM spec even explicitly states that the
> utility window is *not* meant to be a transient dialog)

I have one. :) Left window resizable, but hide maximize button. Just Qt::Dialog doesn't allow this.  But how i see it's ugly hack.
Comment 3 Thomas Lübking 2015-05-22 21:36:07 UTC
(In reply to Roman from comment #2)

> I have one. :) Left window resizable, but hide maximize button. Just
> Qt::Dialog doesn't allow this.  But how i see it's ugly hack.

That wouldn't work in KWin - if a window has a maximum size != its min size, it's maximizable.
But you might be on the right track: utility windows are not minimizable (and not in the tabbox and likely not in any taskbar) - that's probably why bug #317484 was linked.

From the valentina bug, the window in question sounds like it *should* be a dialog.
Ie. one sought to make the modal dialog unminimizable by setting it as utility window.

It's btw. maximizable AND minimizable in openbox - so it's either really a bug in valentina or a *very* crude hack =)

  Did you happen to git blame the line in question?
  Or could you? Try
   git blame -L96,+1 HEAD^ -- src/app/dialogs/app/configdialog.cpp



@Martin
netwm says:
_NET_WM_STATE_MODAL indicates that this is a modal *dialog* box. If the WM_TRANSIENT_FOR hint is set to another toplevel window, the *dialog* is modal for that window; if WM_TRANSIENT_FOR is not set or set to the root window the *dialog* is modal for its window group.

I feel very much tempted to resolve such contradiction, by failsafing - ie. since we cannot judge whether this should be a modal dialog or a utility window and it can hardly be both, we treat it as a non modal normal window (but still transient, that's orthogonal)?
Comment 4 Roman 2015-05-25 12:00:00 UTC
> It's btw. maximizable AND minimizable in openbox - so it's either really a bug in valentina or a *very* crude hack =)

Hi guys,

Thanks a lot for constructive criticism. I fixed this bug. Now Valentina returned to the light side. :)
Comment 5 Thomas Lübking 2015-06-10 07:42:58 UTC
Git commit 41be18e317155c282fa6778620903b906ada69c5 by Thomas Lübking.
Committed on 10/06/2015 at 06:50.
Pushed by luebking into branch 'master'.

Robust modal activation; ensure showing activated

...window

REVIEW: 123875

M  +2    -0    abstract_client.h
M  +6    -4    activation.cpp
M  +1    -1    client.h
M  +4    -0    shell_client.cpp
M  +1    -0    shell_client.h

http://commits.kde.org/kwin/41be18e317155c282fa6778620903b906ada69c5