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

[Jeff McDonald]

I disagree with your conclusion, but I respect your decision. Thank you for
considering my suggestions.

Cheers,
Jeff

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

> Both. What you propose would be a much bigger design change, and I am not
> sold on the need anyway. Also, there is a strong desire to not break
> compatibility.
>
>
> -- Kevin
>
>
> Jeff McDonald wrote:
>
>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>