API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking

[Jeff McDonald]

Seriously? So backwards compatibility is a requirement of JavaFX at this
point? Or are you saying that the benefit of the proposal doesn't outweigh
breaking backwards compatibility?

On Wed, Apr 11, 2012 at 11:19 AM, Kevin Rushforth <
kevin.rushforth at oracle.com> wrote:

>
>> This will break the backwards compat of a stage so I think it is too
>> late for such an API.
>>
>
> Right. We need to keep the existing API unmodified. Adding a single method
> is the easiest way to compatibly extend the API and keep the ideas of
> modality separate from whether or not the caller is blocked.
>
>
> -- Kevin
>
>
> Tom Schindl wrote:
>
>> Am 11.04.12 18:58, schrieb Jeff McDonald:
>>
>>
>>> I put together a truth table of sorts to help me visualize the possible
>>> states. It's an ASCII chart so it needs to be viewed using a monspaced
>>> font
>>> for everything to line up.
>>>
>>>
>>> +-----------------------------**---+--------------------------**
>>> --------------+---------------**-----------------------------+
>>>    | Modality.NONE                  | Modality.WINDOW
>>>   | Modality.APPLICATION                       |
>>>    | initModality(Modality.NONE)    | initModality(Modality.WINDOW_**
>>> MODAL)
>>>   | initModality(Modality.WINDOW_**MODAL)        |
>>> +-------------------+---------**-----------------------+------**
>>> ------------------------------**----+-------------------------**
>>> -------------------+
>>> | un-blocked        | Supported (This is typical)    | Supported
>>>                   | Supported                                  |
>>> | show()            | 1. initModality(Modality.NONE) | 1.
>>> initModality(Modality.WINDOW_**MODAL) | 1.
>>> initModality(Modality.WINDOW_**MODAL)     |
>>> |                   | 2. show()                      | 2. show()
>>>                   | 2. show()                                  |
>>> |                   | or just                        |
>>>                   |                                            |
>>> |                   | 1. show()                      |
>>>                   |                                            |
>>> +-------------------+---------**-----------------------+------**
>>> ------------------------------**----+-------------------------**
>>> -------------------+
>>> | blocked           | Unsupported                    | Supported
>>>                   | Supported                                  |
>>> | showAndWait()     | Throws exception               | 1.
>>> initModality(Modality.WINDOW_**MODAL) | 1.
>>> initModality(Modality.**APPLICATION_MODAL)|
>>> | (proposed)        |                                | 2. showAndWait()
>>>                  | 2. showAndWait()                           |
>>> +-------------------+---------**-----------------------+------**
>>> ------------------------------**----+-------------------------**
>>> -------------------+
>>>
>>> I propose the following changes:
>>> 1. show() remains the same as it is now.
>>> 2. add showWindowModal(boolean wait)
>>> 3. add showAppModal(boolean wait)
>>> 4. remove initModality()
>>> 5. Add Tom's description of "modal" and "blocking" to the JavaDocs. His
>>> wording is clear and concise.
>>>
>>> The justification: The API is clearer and easier to understand because
>>> only
>>> one method call is required to execute the desired behavior instead of
>>> two
>>> method calls. The second benefit is that a single method call eliminates
>>> the potential of calling the initModality and show() / showAndWait()
>>> methods in the incorrect order.
>>>
>>>
>>>
>>
>> This will break the backwards compat of a stage so I think it is too
>> late for such an API.
>>
>> Tom
>>
>>
>>
>