> Second, we often face the situation, when two or more
> modal dialogs are shown simultaneously, and it should
> be specified which of them block others or remain
> unblocked. I can point out two approaches:
> range-based (we specify the range of blocking for
> each modal dialog) and time-based (the last shown
> window remains unblocked regardless of what windows
> have been shown before).
What is wrong with tree based?
Where any modal dialog only blocks the ones that it is a child of? Having two modal dialogs with a different parent is no problem this way. (But I'd have to talk to the WM guys to make sure)
This is a simpler approach to 'range' and is IIRC what the native WMs do as well.
I founded that the first message which should open the topic written by denismo appeared to be a separate topic with no replies. Below is the original text.
The J2SE desktop team is planning to implement new
modality modes in Mustang (the next major release). We
want this new API to satisfy the needs of developers,
so please help us by responding to this post.
Most of the specification is clearly defined and
reflects existing modality behaviors of different
platforms and toolkits. However, there are some
controversial parts, one of which we'd like to discuss
with you in this thread: application modality.
We start with the following definition: An
application-modal dialog is a modal dialog that blocks
input to all visible windows in its application.
What should happen when a second application-modal
dialog, D2, is made visible while D1 is still visible?
(This might occur either because D1 brings up D2 or
because D2 is shown from another thread.)
Currently, when setVisible(true) is invoked on a modal
dialog, the setVisible method does not return until the
dialog is closed. To implement such behavior, we start
an internal event pump. Assuming that we preserve this
behavior, a second application-modal dialog should
block the first; that is, D2 should block D1. This
comes from the fact that the event pump of D2 will be
started from inside the event pump of D1. We don't
currently plan to change this behavior.
Now consider the situation where one application-modal
dialog, D1, is shown. If we show Window W with D1 as
the owner (e.g., W is a tool tip or popup menu), or a
show a modal dialog D2 with D1 as the owner (e.g., D2
is a JFileChooser, which blocks only its owner), W and
D2 must not be blocked by D1. This also seems clear.
Finally, consider the situation where the
application-modal dialog D1 is shown, and then Frame F
is shown (e.g., as the result of some action in the
dialog D1). Here's the question:
Should F become blocked by D1 or not?
If you have an opinion about this question, please post
it and your reasoning. Thank you.
There are several modality issues desired to be discussed.
First, developers need some modes that are absent at the presend, they are (at least) parent and appcontext modalities. Currently the only one mode supported is Toolkit (or application) modality.
Second, we often face the situation, when two or more modal dialogs are shown simultaneously, and it should be specified which of them block others or remain unblocked. I can point out two approaches: range-based (we specify the range of blocking for each modal dialog) and time-based (the last shown window remains unblocked regardless of what windows have been shown before).
2 zander: Java modality definition operates with such terms as focus, size & position, z-order. Many WMs don't provide any means, for example, to control window z-order. Even those that formally support _NET protocol often appear to miss something. Thus, Java team mustn't rely much on WMs and do everything theirself. And don't forget about Windows platform that is also officially supported by Sun in Java.
thanks for joining in.
> Java modality definition operates with such
> terms as focus, size & position, z-order.
Are the specifications (expected behavior) written down somewhere? I have a hard time believing Java is asking too much from the WMs.
And if Java really is doing more complex things then all the WMs allow; then it might be an idea to adjust your requirements downwards.
This is again the same point I made in a former post; please write a specific set of problems and proposed solutions (a whitepaper if you will) so we can all work from the same baseline.
> Many WMs
> don't provide any means, for example, to control
> window z-order. Even those that formally support _NET
> protocol often appear to miss something. Thus, Java
> team mustn't rely much on WMs and do everything
In the last 2 major versions (1.4 and 1.5) java has changed many little things to make this work; the success is quite lacking. I have a very very sad collegue who found out his widget does not work anymore in 1.5 due to a focus 'fix'..
In short; doing it yourself is impossible if you a) want to be used with the 20 or-so different WMs, and b) if those WMs change more often then Java is released.
Don't forget that running inside a WM means you may have to counter the behavior of the current WM since you improperly said you are a top-level-window instead of a dialog.
And what about the value of honoring window placement? Java still fails to do that correctly even though my WM is trying hard to enforce it. (the java webstart splash is positioned half on one and half on the other monitor)
Sorry; but you will have to accept that The only way to get this correct is to work _with_ the WM specification-makers so anything not working properly will get fixed there.
> And don't forget about Windows platform
> that is also officially supported by Sun in Java.
Yes; I know. Its not a pretty picture to work with.
The fact that the Windows WM is completely different from the Unix ones, and pretty-feature-less as well makes solving the complete picture even harder.
From my point of view; having one implementation that will work consistently on Windows and 'the rest' is unrealistic. Please correct me if you feel different.
Make the best use of the Unix WMs (KDE/Gnome/etc) since these users also expect more since all applications on those platforms get managed better.
> Hi Artem,
> thanks for joining in.
Should I take the lack of response as a sign that my suggestions are looked into?
Please tell us about progress then.
Thanks, and have a good weekend.
We will think about your suggestions.
On Sun, 2004-10-24 at 12:55, email@example.com wrote:
> > Hi,
> > The J2SE desktop team is planning to implement new
> > modality modes in Mustang (the next major release).
> > We
> > want this new API to satisfy the needs of
> > developers,
> > so please help us by responding to this post.
> I hope you mean that the ones it currently has will do the right thing first.
> There are several severe bugs and overdesigns in the current implementation which are not needed at all.
> Having more then one appContext basically means you have 2 applications. But the AWT people keep saying bigger definitions are needed and we need to look at every corner case, which leads to the Gnome/KDE window managers not support their rediculously overdesigned modality questions.
> > This
> > comes from the fact that the event pump of D2 will be
> > started from inside the event pump of D1. We don't
> > currently plan to change this behavior.
> I suggest SUN participate in the opendesktop specification of the WM design which is the definition on how both KDE and Gnome implement their WMs.
What specification do you mean? _NET?
> As long as Java Swing keeps implementing their own without using the native WM (as you point out above) the solution will not work for me.
> Modality must come from the native WM, which then allows things like having a child dialog always in front of the parent dialog, and busy pointers as well.
> This works for each and every widgetset out there; if AWT can't work with the current featureset, then adjust your requirements downwards.
> Keep it simple and just look at the standards which you can then follow. I spent WAAAY to much time with the KWin developer finding workarounds for KDE to make java applications look somewhat decent. Only to find out that in 1.5 Java has a whole new set of bugs. I certainly don't plan to add more workarounds to KWin.
> Will this be solved with the redesign?
It is the primary target.
> Are you aware of a nasty regression (since 1.4.2) in 1.5 that a popup on popup stopped working :(
Which platform? Example? Is it filed as a bug?
> And that top-level jframes take focus on de-minimizing when the child dialog (non-modal) should have had focus?
No, I didn't hear about this bug. Is it filed?
> What specification do you mean? _NET?
> > As long as Java Swing keeps implementing their own
> without using the native WM (as you point out above)
> the solution will not work for me.
> > Will this be solved with the redesign?
> It is the primary target.
Sounds good; but from your post (please correct me if I am wrong) you are walking the wrong direction. You are still under the assumption Olegs answer posted in our previous discussion is valid; it no longer is.
Please discuss the actual method you guys are attempting to implement as one or two questions (which I fail to see as serious problems) don't give me a good idea if the solution is going to be a good one.
About wm-spec - yes, we know about this list and tried to cooperate with WM authors to extend the support for various Java needs. Deafness was the result, and it has been one of the reason why modality enhancements were delayed in Tiger. We didn't give up - but the chances that some improvements might happen on Linux side are close to zero. The modality support in _NET is inadequate (do you also think that modality specification can be provided in three lines of text?), and we can't rely on it for building API for business applications.
Could you please clarify what you think is not valid in Oleg's post?
The planned method is the usage ICCCM's WM_TAKE_FOCUS and WM_TRANSIENT_FOR, plus _NET_WM_WINDOW_TYPE, plus Java events filtering.
Returning back to the subject - do you have the opinion on it? Should a frame be blocked by application(or appcontext)-wide modal dialog or not when it is shown after the dialog?
> About wm-spec - yes, we know about this list and tried to cooperate with WM authors to extend the support for
> various Java needs. Deafness was the result
I talked to the main developers of these WMs and got a very different impression.
I got the impression that Sun was asking what it would take to implement [insert very complex solution here] with as little explenation as "Our customers might need it".
As I said in my previous post; come forward with your reasoning (a whitepaper if you wish) to first specify which problems you are trying to solve and then what your proposal is. This way if your proposal is impossible or unrealistic you will get counter-proposals or simply open discussion on the topic.
Just asking a very complex issue, which I am absolutely sure I am one of the very few on this forum who actually understands it, will not help. Don't expect people to grok a fully, but poorly, implemented solution. Open systems and open communication just does not work that way.
While I certainly have an opinion on the modality question you asked (yes) the question is irrelevant in the current context.
Oleg Wrote a year ago:
> special handling for events which are targeted to decoaration of our top-levels (e.g. we should
> deny resizing, changeing z-order, opening system menu).
All this is controlled (enforced even) by the WMs of today; Java only has to specify the correct window type and the rest is handled by the WM. It is even wanted that Java ignores that some WM might (maybe) not implement this functionality since the user made that choice. In other words; this stuff is native, respect the users wishes and just follow the spec.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.