to me demands attention sounds like the appropriate solution.

My reasoning is: the user minimizied the window to have it out of the way at 
the moment. He doesn't want to be bothered by this window and doesn't interact 
with it at the moment. Thus he also does not want to be bothered by any 
further windows being opened as modal windows to the minimized window.

Ergo: demands attention seems like the best solution for the given situation.

Hi Thomas, 
Thanks for starting this discussion - 

In my opinion, this depends on the situation - not just a per application situation, but also an environmental situation. 

Is there are reason the user can't be given the opportunity to choose the behaviour that will work in their given scenario?

(In reply to Bernard Gray from comment #2)
> but also an environmental situation. 
Actually, the only environment I can think of which could make this required would be a setup w/o any taskbar (like mine ;-)

Personally, I've so far not missed urgency hints (for this or other reasons), thgouh.
-> Any more hints on "environmental situations"?

> Is there are reason
Please notice that the code in question is so old that nobody around can but speculate on intentions/reasons/details, sorry.

> the user can't be given the opportunity to choose the behaviour
As for choosing, i firmly believe that the dialog should still honor the minimization rule, ie. if I explicitly set the dialog to initially be unminimized, that should also apply if the main window is minimized. Also the rules largely exist to fix "broken" clients.

On a wider range, one might reasonably "act dumb" if the focus stealing prevention is set to "None" (what implies "dumb" focus handling), but must then ask, who would be actually willing to sacrifice focus stealing for this very particular case (so this, while probably consistent, seems less like a solution to an actual problem to me)

(In reply to Thomas Lübking from comment #3)
> (In reply to Bernard Gray from comment #2)
> > but also an environmental situation. 
> Actually, the only environment I can think of which could make this required
> would be a setup w/o any taskbar (like mine ;-)
>
> Personally, I've so far not missed urgency hints (for this or other
> reasons), thgouh.
> -> Any more hints on "environmental situations"?

We have a relatively unskilled computer user base that this is rolling out to - they are using fast machines and big screens, and a little blink on an icon in the taskbar (particularly a full taskbar) of a high res monitor is extraordinarily easy to  miss.

> > Is there are reason
> Please notice that the code in question is so old that nobody around can but
> speculate on intentions/reasons/details, sorry.

This is not a question on past code - it's a question regarding a possible future feature


> > the user can't be given the opportunity to choose the behaviour
> As for choosing, i firmly believe that the dialog should still honor the
> minimization rule, ie. if I explicitly set the dialog to initially be
> unminimized, that should also apply if the main window is minimized. Also
> the rules largely exist to fix "broken" clients.

So does this mean you are working around other broken clients to make them work? Would they be easier to get fixed (given the size and complexity of the LO project?)

> On a wider range, one might reasonably "act dumb" if the focus stealing
> prevention is set to "None" (what implies "dumb" focus handling), but must
> then ask, who would be actually willing to sacrifice focus stealing for this
> very particular case (so this, while probably consistent, seems less like a
> solution to an actual problem to me)

While the option to choose may indeed break other applications handling, given that I have some control over the software in use, and the fact that LO is by far the most complicated and difficult to package(, debug and fix) tool in the environment:  
*I* would be willing to make this sacrifice.

From my perspective, I have a controlled SOE with a fixed set of applications and a showstopper bug, because KDE for some reason is handling the LO minimised windows differently to the other major DEs. 
It doesn't seem unreasonable to me to provide an option (even if it's off by default) to make the focus handling behave like those other DEs.

(In reply to Bernard Gray from comment #4)

> We have a relatively unskilled computer user base that this is rolling out
> to - they are using fast machines and big screens, and a little blink on an
> icon in the taskbar (particularly a full taskbar) of a high res monitor is
> extraordinarily easy to  miss.
This seems to render the entire "demand attention" concept useless - at least clients effectively fail to demand attention in the setup. (notice that clients also enter this state themself to gain attention in an unobtrusive way) 

> This is not a question on past code
Sorry, I really misunderstood it as one.

> So does this mean you are working around other broken clients to make them
> work?
OT: We're not working around particular clients, but allow the user to "know better than the client".
Among the thousands of clients in the wild, you may expect fluctuation or simply deviation from users expectation or sometimes "aggressiveness".

> Would they be easier to get fixed (given the size and complexity of the LO project?)
OT: As mentioned in the other bug, I'm pretty sure the dialog should not be transient for the document window (in case it opens a new one anyway) and if it re-uses a document window, it should probably seek to activate, but in any case map it (opening an ODS in a minimized empty document window caused absolutely no visible reaction in any WM here)

> > On a wider range, one might reasonably "act dumb" if the focus stealing
> > prevention is set to "None" (what implies "dumb" focus handling), but must

> While the option to choose may indeed break other applications handling,
FYI: Focus stealing prevention "None" would not break clients - it's actually the plain NETWM compliant behavior. It just causes nasty focus stealing (while you're typing in one window and another one believes it needs the keyboard focus *now*!)

> *I* would be willing to make this sacrifice.
I think you missed my point - ruling dialogs (or a specific one) to be initially not minimized would be the by far less invasive solution to the problem.
Altering the FSP:None behavior for the sake of coherence would (probably) be a reasonable alteration in general, but change the configured FSP only to impact the minimization state of a dialog would be an unreasonable step.
I was rather addressing Martin by this comment (he's the KWin maintainer)
 
> From my perspective, I have a controlled SOE with a fixed set of
> applications and a showstopper bug
OT: As far as your particular scenario is concerned, please see my initial post.
I firmly believe that you (and LibreOffice) would be better off by simply activating a present document window (if it's gonna be re-used) as response to an explicit user request - this does not only cover the csv dialog but opening documents in general. The latter on *any* WM.
I would fix it this way and I really can alter KWin anytime and as much as I want.

> to make the focus handling behave like those other DEs.
FYI: This is actually not strictly about focus handling - FSP would still apply.

To recap:
-------------
- My opinion and standing suggestion is to make this special dialog handling still adhere to the initially applying minimization rule (as well as depend on the FSP. Notice that I do not suggest to alter FSP to address this, though)
- This would allow you to deal with your situation from this side, but I doubt that would be the best approach (you'd end up with a working *.csv but not *.ods opening)
- I took your immediate problem as a trigger to this question, but do personally not consider it a valid reason to cause any behavioral changes (since it would not be an issue if LO would react to a direct user call - compare eg. "kate" when opening a file in a minimized window)

(In reply to Thomas Lübking from comment #5)
> To recap:
> -------------
> - My opinion and standing suggestion is to make this special dialog handling
> still adhere to the initially applying minimization rule (as well as depend
> on the FSP. Notice that I do not suggest to alter FSP to address this,
> though)
> - This would allow you to deal with your situation from this side, but I
> doubt that would be the best approach (you'd end up with a working *.csv but
> not *.ods opening)
> - I took your immediate problem as a trigger to this question, but do
> personally not consider it a valid reason to cause any behavioral changes
> (since it would not be an issue if LO would react to a direct user call -
> compare eg. "kate" when opening a file in a minimized window)

Ok, I think I'm out of my depth here on the specifics of how the FSP works, and what methods/calls exist in kwin to work with it. 
The LO behaviour is definitely wrong/a bug, but the kate behaviour is correct/exactly as I expect it. 

If it's possible for you to give me some specific info on what LO is _not_ doing, and what it needs to do in order to have the window behave correctly (like Kate), I'm happy to take the info to the LO bugtracker and try and push it through there. Kwin/generic wmctrl type behaviour/calls/interaction etc are way outside my area of knowledge I'm afraid.

PS I realise this discussion is not meant to be LO specific, but since it's the only program that I'm experiencing the behaviour on, I sort of have to reference it.

> PS I realise this discussion is not meant to be LO specific, but since it's
> the only program that I'm experiencing the behaviour on, I sort of have to
> reference it.

OT: it should be possible to fix this specific behavior with a KWin script.

(In reply to Martin Gräßlin from comment #7)
> OT: it should be possible to fix this specific behavior with a KWin script.

OT: Yep I used the example from the bug #339621 thread to get around it for now

(In reply to Bernard Gray from comment #6)
> If it's possible for you to give me some specific info on what LO is _not_
> doing, and what it needs to do in order to have the window behave correctly
> (like Kate)

It should be entirely sufficient to attempt to ask for activation of the relevant document window.
This will (on success) not only unminimize it, but WMs will also move you to the correct virtual desktop (and or "activity"), move to the correct tab (if the window is tabbed with others etc.)

In case the WM denies the activation for whatever reason (eg. if the focus stealing prevention was configured to "extreme" in KWin), you'd still be with the blinking taskbar, but then there's either a really good™ reason to deny activation or the WM is buggy.

> push it through there. Kwin/generic wmctrl type behaviour/calls/interaction
The wmctrl script snippet ("libreoffice" symlinks a "soffice" shell script that ultimately invokes the binary) I posted in the other bug simply activates ("all") libreoffice windows before going on with opening the document.

"wmctrl" is not part of KDE or related to KWin but a commandline tool to interact with NETWM compliant window managers (so it will help on gnome, enlightenment, fluxbox and others as well)

> PS I realise this discussion is not meant to be LO specific, but since it's
> the only program that I'm experiencing the behaviour on, I sort of have to
> reference it.
I do understand this, but it's a "bad" example.
The behvaior, as is, deals with "nasty" clients which popup dialogs "out of the void" (while the corresponding window is stashed), ie. the user is currently not really interested in this window/application and suddenly gets a dialog w/o context, likely stealing the input focus. 

This is obviously not the case in your scenario where the client has (private) knowledge that it's now requested and should just share that knowledge with the WM.