Skip to main content

Application modality definition

No replies
Joined: 2003-06-28


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.