Bug 277847

Not showing the minimize button does not fix anything but only hides the problem (minimization would still be possible leading to the same inconsistent behavior).

Let's have a look at the different cases (in reverse order) to highlight the differences:

1. About dialog: The about dialog is a transient, non-modal normal dialog window which allows minimization (see xprop on the window). It is possible to focus this windows and to focus other windows. That it is non-modal is even visible as the "parent" window does not get darkened. The only possible bug here is that the tasks applet does not show a window entry. Minimizing a transient non-modal window is a valid use-case

2. Modal dialog in a normal application (like thunderbird): the modal dialog is a transient for the parent window (like the other case). It can be minimized and is a normal dialog window marked as modal. The behavior is as expected it blocks the parent window (this is visible). Minimization and other operations go in sync. Minimizing a modal window (together with the parent window) is a valid use-case.

3. Java application: Java is known to be broken in regards to window management. This is most likely a toolkit bug and I don't care about it. Feel free to investigate what it does wrong. From your description it sounds like it is a transient window (case 1) which is not modal, but treated like a modal window inside the application. This would be clearly a toolkit bug and we cannot do anything to prevent the toolkit to be non-standard compliant.


Overall I do not see anything wrong in the behavior of kwin (as said the behavior of Plasma might be doubtable, but that is up to Plasma developers). Concerning Java applications I can only recommend to not use Java on the desktop as it is known to be broken (yes it's a bad advice if you have to use Java).

You are right. The minimize button does not fix anything but only hides the problem.

But I disagree. And Yes, there is something wrong with the behaviour of kwin and I think it should be changed when the others window managers work in a different way (gnome, windows, etc..).

Minimization of a modal dialog should not be allowed, So the minimized buttom should not appear.

You said minimizing a modal window (together withe the parent window) is a valid use-case. Maybe you are right, but the environment should allow several behaviours because this is not a good solution for every situation.

And it is nod a good advice your recommendation about not use Java on the desktop. People would try to use a different environment like gnome and/or windows to make their applicatioins work.

Sorry to say, but you didn't understand the topic at all.

If you minimize a *modal* dialog in KDE, the modally blocked ("main") window will be minimized with it and re-show the blocked window will implicitly re-show the modal dialog with it.
The reason behind that is that the modal dialog virtually "controls" the main window. If the main window tried to get the focus, the modal dialog would get it asf.

=> There is no issue with modal dialogs at all and preventing them from minimization would only get them forced on screen even if their main window was minimized.

The client bug here is that the client treats the dialog as modal but doesn't tell anybody -> client bug.
From the WMs perspective the dialog is NOT modal, it doesn't know how the client would treat the window internally.

Your problem is likely rather bug #231544 which is esp. about NON modal transient dialogs, ie. a dialog that wants to stay above its main client but does (from the WMs perspective) not block it, therefore it's allowed to be minimized on its own.

FTR:
There's no common behavior among WMs about this.
Metacity was the only to disallow minimizing transient windows and compiz (and eventually now mutter) inherited it.
Other WMs act *completely* different.

Windows doesn't have sth. like a window manager at all, the "clients" mange windows themselve.

Sorry to say, but I do understand the topic quite well.

And, of course, there is an issue with modal dialogs and no preventing them from minimization. Because this is a needed option for some applications and this is how it works in other platforms. For example, let´s say we have an appplication with a warning modal dialog. The user must acknowledge the message within that dialog and must no be able to minimize the application from the dialog.

So, the current behaviour is good for some situations but no for all situations.

You may call this issue an improvement instead of a bug, but it is needed.

We are almost sure that there is also the client bug (jdk bug) you are talking about. 

And as a result we are also able to watch bug https://bugs.kde.org/show_bug.cgi?id=231544

> The user [...] must no be able to minimize the application from the dialog.

Why?
That is a completely unreasoned and unreasonable claim. It's actually so far remote that it made me assume you were not aware what you're talking about.

If the user wants to minimize windows and do something different for the moment, he's free to do so - it's not the clients nor the WMs choice what the user now wants to do - he could as well switch to another desktop instead, so that should by your logics be forbidden as well?

The mandatory condition is that the user cannot bypass the modal dialog, ie. he must not be able to minimize the modal dialog *exclusively* but he might very well wish to get rid of the blocked main window alone or the blocked main window AND the modal dialog.

Rule of thumb:
if the blocked window is visible, the modal dialog has to be visible and layered above it.
If you can break that condition, that's a valid bug.

> If the user wants to minimize windows and do something different for the
> moment, he's free to do so - it's not the clients nor the WMs choice what
> the user now wants to do
To support this: the user must be able to minimize the main window as he might 
need to access another window. I recently had such a case where I worked with 
several (three) KMail windows and one of them modal to another. But I needed 
to access information from the one which is not the dialog and not the blocked 
one. Only by minimizing (or other ways of moving the window away) the blocked 
one I was able to get this information.

KWin is designed to not force users into a specific workflow. This is one of 
the parts of it.

I understand your point of view.

I do agree with the above rule of thumb.

I do agree that the user must be able to get rid of the the blocked main window to access another window (using the mouse to move the window, using the taskbar, minimizing or other ways of moving the window away). He´s free to do so.

But we still think that the minimize button inside the modal dialog ( not the one in the blocked window ) should not (always) appear because it is really confusing (Other platforms behaves in a different way). Your example about several KMail windows fits perfectly the way is currently working. But If that way does not fif for everybody. What can we do ???

1 Nothing. Do not use this application. This does not sound pretty good.

2 Use a different platform for our multiplatform application. This does not sounds so bad, but we would like to support "KDE".

3 Comment this issue to KDE people to find a solution. We think this is the best option.

It would be great for us if the minimize button (functionality) inside the modal dialog could be disabled. Maybe from a configuration file and /or from the API, leaving the current behaviour as the default one.

I do not see the confusing part about the ability to minimize a window - and personally, I don't care whether other platforms like to artifically restrict their  users. "They" (is it "Gnome"?) could just as well follow the KWin behavior

Since you keep referring to "we" and "us" you apparently have a real-life item.
I think you should reference it, so we get a better idea about your concern.

The reason I first opened this ticket was because of the behavior I saw in Java apps when I accidentally minimized an app-modal dialog.  

Hiding this window put the java application into an unusable state (no keyboard events).
And finding that damned dialog again was also a trick in itself.

I wondered why I only did this by mistake when I was in KDE and never had this issue from Windows or Gnome. Then I noticed no minimize button in modal dialogs on the other platforms. So I assumed this was a bug in how KDE presents modal dialogs.
This might be a toolkit bug, but it is an undesireable behavior in Java apps that only appears in KDE and not on other desktop/platforms.

(In reply to comment #9)
> The reason I first opened this ticket was because of the behavior I saw in
> Java apps when I accidentally minimized an app-modal dialog.

Yes, that is understood.
We however recently went off-topic onto the "should modal windows be minimizable" road.

The original problem was (is?) that java/swing/awt/whatever (still?) doesn't annouce the modality, so it has no impact on the (newly raised) question whether KWin should forbid to minimize modal windows.

The claim would then be to prevent minimization of *all* transients (since they could be modal) - or actually any window (since any client can be buggy enough to implement internal modality w/o any hinting, ie. the internally modal window seems completely unrelated to the blocked window to the WM)

If this is still an issue with current Java dialogs, we should however maybe seek to ship a stock rule to prevent minimizability for java dialogs (if they can be sufficiently identified) - in this case please attach the output of "xprop" and "xwininfo" on the "not so modal"™ dialog and the blocked window (after running that command the cursor will turn into a cross. click the window and you'll get output in konsole)

Ultimately that's what the rules are there for: working around buggy clients.

Created attachment 82999 [details]
output of xprop and xwininfo for the "about jedit" modal dialog

To me the output looks like AWT doesn't support NETWM. It should be of type 
dialog and not normal. Normal is the fallback. Also there are some motif hints 
- I cannot mentally map those to what they mean, but that could explain why 
other systems do not provide the minimize button.

And they set skip taskbar which makes it of course quite difficult to restore 
after minimized if the user uses a taskbar.

Overall I do not see much we could use to map the window. Maybe the class...

You mean the wm.class, sun-awt-X11-XDialogPeer
actually, that is probably a good candidate!

Yes, it's a good candidate for a rule.

(In reply to comment #12)
> To me the output looks like AWT doesn't support NETWM. It should be of
> type dialog and not normal.

If type wasn't set, the window *had* to be taken as dialog (because of the transient state)

> Also there are some motif hints  - I cannot mentally map those to what 
> they mean, but that could explain why  other systems do not provide the 
> minimize button.

Let's start by this comment in kwin:
// To quote from Metacity 'We support those MWM hints deemed non-stupid'
The minimize and maximize button motif hints are those ignored "deemed stupid" mwm hints.

However, that doesn't matter.
Virtually no client handles MWM correctly - and neither does this one.

It does indeed set MWM_FUNC_MINIMIZE as well as MWM_FUNC_RESIZE and also MWM_DECOR_RESIZEH and MWM_DECOR_MINIMIZE what in this context sounds like it tries to disable minimization and resizing .... just that it does not.
To do that it also had to set MWM_DECOR_ALL and MWM_FUNC_ALL what turns the other flags into reversals.

So what it *does* is to say (via MWM) you may *only* minimize and resize me.
Please neiter close, move or maximize me.
Also despite i want a minimize button and a resize handle, please keep me entirely undecorated.

The complexity of this system (and the client errors because of it) is btw. the reason why only few WMs still support MWM at all.
(To do MWM just: it was designed as an internal motif thing and not as some open standard)

> And they set skip taskbar which makes it of course quite difficult to
> restore after minimized if the user uses a taskbar.
Hmmm... maybe a script that auto-unminimizes taskbar skipping windows after each minimize would help here (and for all non-modal transients reg. bug #231544)

Created attachment 83001 [details]
"Fixing" rule for sun-awt dialogs

Attached is a rule to prevent minimization for that client

This script will undo minimization of windows that likely don't show up in the taskbar:
http://kde-look.org/content/show.php?content=161366


Oh, and btw:
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE

=)

(In reply to comment #15)
> Oh, and btw:
> _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE,
> _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE,
> _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE
Don't forget: allowed actions is set by the WM.

Created attachment 83014 [details]
"Fixing" rule for SwingSet2 dialogs

I have just made some testing with a modified "fixing" rule in the following environment:

Linux 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux (CentOS 6.2)

KDE 4.3.4

java version "1.7.0_40"

Application under test: demo/jfc/SwingSet2.jar (JOptionPane Demo ) from Oracle java demo and examples

Attached is a rule that tries to prevent minimization and tries to disable close button for dialogs.

It works pretty well with the close button but the minimization option does not work.

Maybe I'm doing something wrong

What's the exact output of "xprop WM_CLASS" for that window?
Btw, no WM I tested has closing disabled for transient dialogs - rather maximizing.

WM_CLASS(STRING) = "sun-awt-X11-XDialogPeer", "SwingSet2"

Actually this rule https://bugs.kde.org/attachment.cgi?id=83001 should match as well and  so should yours.
The only thing I noticed: it only applies to dialogs and the props posted by Alan suggest the "dialog" was of normal type (while I found a Dialog type dialog in jedit, so i matched normal and dialogs)

If closing however applies but minimization does not, i could only assume there's a matching rule above that neglects the minimization prevention.

(Please also notice that there can still be a -disabled- minimization button, depending on the used decoration)

I think there is no other matching rule above.

I have just installed "jedit", and the jedit "about dialog" works the same way as the "swingset2 dialog".

After reading the KDE userbase kwin rules page, I think they are working as expected and it does not prevent minimization.

This is what the manual says about "minimized attribute" and "closeable attribute"

Minimized, Shaded
Toggle the Minimize and Shading window attribute. For example, a window can be started
Minimized or if it is started Minimized, it can be forced to not.

Closeable
Toggle whether to display the Close button on the title bar.

errr... which KDE version? (there might have been a change, resp. there was a bug about that rule which Martin fixed quite a while ago, but a window that is forced to be not minimized is not minimizable here)

(See comment #18)

ok, that explains a lot =)

Created attachment 83208 [details]
Another "Fixing" rule for java dialogs

This is the rule that works in our environment, don't ask me why :-)

Be warned that you prevent the dialog from getting the keyboard focus (through the WM) by this.

While I could assume the dialog takes focus itself on being clicked (*sigh*) this might cause issues with dialogs that do not (though need keybord input)