<AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

<AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Alexander Zvegintsev
Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8176528

The test uses java.awt.Window which doesn't have button for its window
in the taskbar, thus we can't show progress for this window there.



--
Thanks,
Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Philip Race
The JCK comments in the bug are :
 >This may be a specification issue.
 >Window progress is not displayed in taskbar as specified.
 >The spec states that progress is displayed in a platform-dependent way.
I>f progress is not in fact displayed under some circumstances, that
should be specified.

So they already know the window isn't visible and are asking for an
explanation
of the circumstances for this so I don't think this update will satisfy
them without
more explanation.

At the very least we need to add that
"Some {@code Window}s are not visible in the task bar.
For example undecorated Windows may not be visible".

I do not know if we can say something stronger than that ?
Is this the case on all platforms ?

-phil.

On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:

> Hello,
>
> please review the fix
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/
>
> for the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8176528
>
> The test uses java.awt.Window which doesn't have button for its window
> in the taskbar, thus we can't show progress for this window there.
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Alexander Zvegintsev
> So they already know the window isn't visible and are asking for an
> explanation
> of the circumstances for this so I don't think this update will
> satisfy them without
> more explanation.
>
> At the very least we need to add that
> "Some {@code Window}s are not visible in the task bar.
> For example undecorated Windows may not be visible".
Actually java.awt.Window is not visible in taskbar because of its window
style flags(WS_EX_NOACTIVATE, WS_EX_TOOLWINDOW), it has nothing to do
with decorations.

I've replaced parameter type with Frame instead if Window to avoid such
misunderstanding. Frame still can be removed from taskbar by
f.setType(Window.Type.UTILITY) call.

> I do not know if we can say something stronger than that ?
> Is this the case on all platforms ?
This part of API is supported for Windows only.


http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/01/

--
Thanks,
Alexander.

On 14.03.2017 0:52, Phil Race wrote:

> The JCK comments in the bug are :
> >This may be a specification issue.
> >Window progress is not displayed in taskbar as specified.
> >The spec states that progress is displayed in a platform-dependent way.
> I>f progress is not in fact displayed under some circumstances, that
> should be specified.
>
> So they already know the window isn't visible and are asking for an
> explanation
> of the circumstances for this so I don't think this update will
> satisfy them without
> more explanation.
>
> At the very least we need to add that
> "Some {@code Window}s are not visible in the task bar.
> For example undecorated Windows may not be visible".
>
> I do not know if we can say something stronger than that ?
> Is this the case on all platforms ?
>
> -phil.
>
> On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:
>> Hello,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8176528
>>
>> The test uses java.awt.Window which doesn't have button for its
>> window in the taskbar, thus we can't show progress for this window
>> there.
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Philip Race
with this change maybe we should be renaming the parameters and update the doc
ie
279      * @param w window
could be
 @param f frame
?

Or is there precedent for what you have right now ?

-phil.

On 3/14/17, 5:33 AM, Alexander Zvegintsev wrote:
So they already know the window isn't visible and are asking for an explanation
of the circumstances for this so I don't think this update will satisfy them without
more explanation.

At the very least we need to add that
"Some {@code Window}s are not visible in the task bar.
For example undecorated Windows may not be visible".
Actually java.awt.Window is not visible in taskbar because of its window style flags(WS_EX_NOACTIVATE, WS_EX_TOOLWINDOW), it has nothing to do with decorations.

I've replaced parameter type with Frame instead if Window to avoid such misunderstanding. Frame still can be removed from taskbar by f.setType(Window.Type.UTILITY) call.

I do not know if we can say something stronger than that ?
Is this the case on all platforms ?
This part of API is supported for Windows only.


http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/01/

--
Thanks,
Alexander.

On 14.03.2017 0:52, Phil Race wrote:
The JCK comments in the bug are :
>This may be a specification issue.
>Window progress is not displayed in taskbar as specified.
>The spec states that progress is displayed in a platform-dependent way.
I>f progress is not in fact displayed under some circumstances, that should be specified.

So they already know the window isn't visible and are asking for an explanation
of the circumstances for this so I don't think this update will satisfy them without
more explanation.

At the very least we need to add that
"Some {@code Window}s are not visible in the task bar.
For example undecorated Windows may not be visible".

I do not know if we can say something stronger than that ?
Is this the case on all platforms ?

-phil.

On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:
Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8176528

The test uses java.awt.Window which doesn't have button for its window in the taskbar, thus we can't show progress for this window there.





Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Alexander Zvegintsev
There is no precedents here:

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/02/

Thanks,
Alexander.

On 14/03/2017 15:40, Philip Race wrote:

> with this change maybe we should be renaming the parameters and update the doc
> ie
> 279      * @param w window
> could be
>  @param f frame
> ?
>
> Or is there precedent for what you have right now ?
>
> -phil.
>
> On 3/14/17, 5:33 AM, Alexander Zvegintsev wrote:
>>> So they already know the window isn't visible and are asking for an
>>> explanation
>>> of the circumstances for this so I don't think this update will
>>> satisfy them without
>>> more explanation.
>>>
>>> At the very least we need to add that
>>> "Some {@code Window}s are not visible in the task bar.
>>> For example undecorated Windows may not be visible".
>> Actually java.awt.Window is not visible in taskbar because of its
>> window style flags(WS_EX_NOACTIVATE, WS_EX_TOOLWINDOW), it has
>> nothing to do with decorations.
>>
>> I've replaced parameter type with Frame instead if Window to avoid
>> such misunderstanding. Frame still can be removed from taskbar by
>> f.setType(Window.Type.UTILITY) call.
>>
>>> I do not know if we can say something stronger than that ?
>>> Is this the case on all platforms ?
>> This part of API is supported for Windows only.
>>
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/01/
>>
>> --
>> Thanks,
>> Alexander.
>>
>> On 14.03.2017 0:52, Phil Race wrote:
>>> The JCK comments in the bug are :
>>> >This may be a specification issue.
>>> >Window progress is not displayed in taskbar as specified.
>>> >The spec states that progress is displayed in a platform-dependent
>>> way.
>>> I>f progress is not in fact displayed under some circumstances, that
>>> should be specified.
>>>
>>> So they already know the window isn't visible and are asking for an
>>> explanation
>>> of the circumstances for this so I don't think this update will
>>> satisfy them without
>>> more explanation.
>>>
>>> At the very least we need to add that
>>> "Some {@code Window}s are not visible in the task bar.
>>> For example undecorated Windows may not be visible".
>>>
>>> I do not know if we can say something stronger than that ?
>>> Is this the case on all platforms ?
>>>
>>> -phil.
>>>
>>> On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:
>>>> Hello,
>>>>
>>>> please review the fix
>>>>
>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/
>>>>
>>>> for the issue
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8176528
>>>>
>>>> The test uses java.awt.Window which doesn't have button for its
>>>> window in the taskbar, thus we can't show progress for this window
>>>> there.
>>>>
>>>>
>>>>
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Philip Race
Hi,

I realise I need to clarify one thing that may be important.
Previously with Window this could apply to a Dialog.
Now it cannot. Are we disabling an important case with this change ?

-phil

On 3/14/17, 5:54 AM, Alexander Zvegintsev wrote:

> There is no precedents here:
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/02/
>
> Thanks,
> Alexander.
>
> On 14/03/2017 15:40, Philip Race wrote:
>> with this change maybe we should be renaming the parameters and
>> update the doc
>> ie
>> 279      * @param w window
>> could be
>>  @param f frame
>> ?
>>
>> Or is there precedent for what you have right now ?
>>
>> -phil.
>>
>> On 3/14/17, 5:33 AM, Alexander Zvegintsev wrote:
>>>> So they already know the window isn't visible and are asking for an
>>>> explanation
>>>> of the circumstances for this so I don't think this update will
>>>> satisfy them without
>>>> more explanation.
>>>>
>>>> At the very least we need to add that
>>>> "Some {@code Window}s are not visible in the task bar.
>>>> For example undecorated Windows may not be visible".
>>> Actually java.awt.Window is not visible in taskbar because of its
>>> window style flags(WS_EX_NOACTIVATE, WS_EX_TOOLWINDOW), it has
>>> nothing to do with decorations.
>>>
>>> I've replaced parameter type with Frame instead if Window to avoid
>>> such misunderstanding. Frame still can be removed from taskbar by
>>> f.setType(Window.Type.UTILITY) call.
>>>
>>>> I do not know if we can say something stronger than that ?
>>>> Is this the case on all platforms ?
>>> This part of API is supported for Windows only.
>>>
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/01/
>>>
>>> --
>>> Thanks,
>>> Alexander.
>>>
>>> On 14.03.2017 0:52, Phil Race wrote:
>>>> The JCK comments in the bug are :
>>>> >This may be a specification issue.
>>>> >Window progress is not displayed in taskbar as specified.
>>>> >The spec states that progress is displayed in a platform-dependent
>>>> way.
>>>> I>f progress is not in fact displayed under some circumstances,
>>>> that should be specified.
>>>>
>>>> So they already know the window isn't visible and are asking for an
>>>> explanation
>>>> of the circumstances for this so I don't think this update will
>>>> satisfy them without
>>>> more explanation.
>>>>
>>>> At the very least we need to add that
>>>> "Some {@code Window}s are not visible in the task bar.
>>>> For example undecorated Windows may not be visible".
>>>>
>>>> I do not know if we can say something stronger than that ?
>>>> Is this the case on all platforms ?
>>>>
>>>> -phil.
>>>>
>>>> On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:
>>>>> Hello,
>>>>>
>>>>> please review the fix
>>>>>
>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/
>>>>>
>>>>> for the issue
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8176528
>>>>>
>>>>> The test uses java.awt.Window which doesn't have button for its
>>>>> window in the taskbar, thus we can't show progress for this window
>>>>> there.
>>>>>
>>>>>
>>>>>
>>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Alexander Zvegintsev
It is fine too, because Dialog has no representation in the taskbar too.

--
Thanks,
Alexander.

On 14.03.2017 15:56, Philip Race wrote:

> Hi,
>
> I realise I need to clarify one thing that may be important.
> Previously with Window this could apply to a Dialog.
> Now it cannot. Are we disabling an important case with this change ?
>
> -phil
>
> On 3/14/17, 5:54 AM, Alexander Zvegintsev wrote:
>> There is no precedents here:
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/02/
>>
>> Thanks,
>> Alexander.
>>
>> On 14/03/2017 15:40, Philip Race wrote:
>>> with this change maybe we should be renaming the parameters and
>>> update the doc
>>> ie
>>> 279      * @param w window
>>> could be
>>>  @param f frame
>>> ?
>>>
>>> Or is there precedent for what you have right now ?
>>>
>>> -phil.
>>>
>>> On 3/14/17, 5:33 AM, Alexander Zvegintsev wrote:
>>>>> So they already know the window isn't visible and are asking for
>>>>> an explanation
>>>>> of the circumstances for this so I don't think this update will
>>>>> satisfy them without
>>>>> more explanation.
>>>>>
>>>>> At the very least we need to add that
>>>>> "Some {@code Window}s are not visible in the task bar.
>>>>> For example undecorated Windows may not be visible".
>>>> Actually java.awt.Window is not visible in taskbar because of its
>>>> window style flags(WS_EX_NOACTIVATE, WS_EX_TOOLWINDOW), it has
>>>> nothing to do with decorations.
>>>>
>>>> I've replaced parameter type with Frame instead if Window to avoid
>>>> such misunderstanding. Frame still can be removed from taskbar by
>>>> f.setType(Window.Type.UTILITY) call.
>>>>
>>>>> I do not know if we can say something stronger than that ?
>>>>> Is this the case on all platforms ?
>>>> This part of API is supported for Windows only.
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/01/
>>>>
>>>> --
>>>> Thanks,
>>>> Alexander.
>>>>
>>>> On 14.03.2017 0:52, Phil Race wrote:
>>>>> The JCK comments in the bug are :
>>>>> >This may be a specification issue.
>>>>> >Window progress is not displayed in taskbar as specified.
>>>>> >The spec states that progress is displayed in a
>>>>> platform-dependent way.
>>>>> I>f progress is not in fact displayed under some circumstances,
>>>>> that should be specified.
>>>>>
>>>>> So they already know the window isn't visible and are asking for
>>>>> an explanation
>>>>> of the circumstances for this so I don't think this update will
>>>>> satisfy them without
>>>>> more explanation.
>>>>>
>>>>> At the very least we need to add that
>>>>> "Some {@code Window}s are not visible in the task bar.
>>>>> For example undecorated Windows may not be visible".
>>>>>
>>>>> I do not know if we can say something stronger than that ?
>>>>> Is this the case on all platforms ?
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:
>>>>>> Hello,
>>>>>>
>>>>>> please review the fix
>>>>>>
>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/
>>>>>>
>>>>>> for the issue
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8176528
>>>>>>
>>>>>> The test uses java.awt.Window which doesn't have button for its
>>>>>> window in the taskbar, thus we can't show progress for this
>>>>>> window there.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Philip Race
OK. So this API change seems like a necessary one.

-phil.

On 3/14/17, 6:09 AM, Alexander Zvegintsev wrote:

> It is fine too, because Dialog has no representation in the taskbar too.
>
> --
> Thanks,
> Alexander.
>
> On 14.03.2017 15:56, Philip Race wrote:
>> Hi,
>>
>> I realise I need to clarify one thing that may be important.
>> Previously with Window this could apply to a Dialog.
>> Now it cannot. Are we disabling an important case with this change ?
>>
>> -phil
>>
>> On 3/14/17, 5:54 AM, Alexander Zvegintsev wrote:
>>> There is no precedents here:
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/02/
>>>
>>> Thanks,
>>> Alexander.
>>>
>>> On 14/03/2017 15:40, Philip Race wrote:
>>>> with this change maybe we should be renaming the parameters and
>>>> update the doc
>>>> ie
>>>> 279      * @param w window
>>>> could be
>>>>  @param f frame
>>>> ?
>>>>
>>>> Or is there precedent for what you have right now ?
>>>>
>>>> -phil.
>>>>
>>>> On 3/14/17, 5:33 AM, Alexander Zvegintsev wrote:
>>>>>> So they already know the window isn't visible and are asking for
>>>>>> an explanation
>>>>>> of the circumstances for this so I don't think this update will
>>>>>> satisfy them without
>>>>>> more explanation.
>>>>>>
>>>>>> At the very least we need to add that
>>>>>> "Some {@code Window}s are not visible in the task bar.
>>>>>> For example undecorated Windows may not be visible".
>>>>> Actually java.awt.Window is not visible in taskbar because of its
>>>>> window style flags(WS_EX_NOACTIVATE, WS_EX_TOOLWINDOW), it has
>>>>> nothing to do with decorations.
>>>>>
>>>>> I've replaced parameter type with Frame instead if Window to avoid
>>>>> such misunderstanding. Frame still can be removed from taskbar by
>>>>> f.setType(Window.Type.UTILITY) call.
>>>>>
>>>>>> I do not know if we can say something stronger than that ?
>>>>>> Is this the case on all platforms ?
>>>>> This part of API is supported for Windows only.
>>>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/01/
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Alexander.
>>>>>
>>>>> On 14.03.2017 0:52, Phil Race wrote:
>>>>>> The JCK comments in the bug are :
>>>>>> >This may be a specification issue.
>>>>>> >Window progress is not displayed in taskbar as specified.
>>>>>> >The spec states that progress is displayed in a
>>>>>> platform-dependent way.
>>>>>> I>f progress is not in fact displayed under some circumstances,
>>>>>> that should be specified.
>>>>>>
>>>>>> So they already know the window isn't visible and are asking for
>>>>>> an explanation
>>>>>> of the circumstances for this so I don't think this update will
>>>>>> satisfy them without
>>>>>> more explanation.
>>>>>>
>>>>>> At the very least we need to add that
>>>>>> "Some {@code Window}s are not visible in the task bar.
>>>>>> For example undecorated Windows may not be visible".
>>>>>>
>>>>>> I do not know if we can say something stronger than that ?
>>>>>> Is this the case on all platforms ?
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> please review the fix
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/
>>>>>>>
>>>>>>> for the issue
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8176528
>>>>>>>
>>>>>>> The test uses java.awt.Window which doesn't have button for its
>>>>>>> window in the taskbar, thus we can't show progress for this
>>>>>>> window there.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Sergey Bylokhov
In reply to this post by Alexander Zvegintsev
It has no representation on windows, but I assume it can have such on other platforms like OSX/Unity?

> It is fine too, because Dialog has no representation in the taskbar too.

We also exclude JWindow.

>
> --
> Thanks,
> Alexander.
>
> On 14.03.2017 15:56, Philip Race wrote:
>> Hi,
>>
>> I realise I need to clarify one thing that may be important.
>> Previously with Window this could apply to a Dialog.
>> Now it cannot. Are we disabling an important case with this change ?
>>
>> -phil
>>
>> On 3/14/17, 5:54 AM, Alexander Zvegintsev wrote:
>>> There is no precedents here:
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/02/
>>>
>>> Thanks,
>>> Alexander.
>>>
>>> On 14/03/2017 15:40, Philip Race wrote:
>>>> with this change maybe we should be renaming the parameters and update the doc
>>>> ie
>>>> 279      * @param w window
>>>> could be
>>>> @param f frame
>>>> ?
>>>>
>>>> Or is there precedent for what you have right now ?
>>>>
>>>> -phil.
>>>>
>>>> On 3/14/17, 5:33 AM, Alexander Zvegintsev wrote:
>>>>>> So they already know the window isn't visible and are asking for an explanation
>>>>>> of the circumstances for this so I don't think this update will satisfy them without
>>>>>> more explanation.
>>>>>>
>>>>>> At the very least we need to add that
>>>>>> "Some {@code Window}s are not visible in the task bar.
>>>>>> For example undecorated Windows may not be visible".
>>>>> Actually java.awt.Window is not visible in taskbar because of its window style flags(WS_EX_NOACTIVATE, WS_EX_TOOLWINDOW), it has nothing to do with decorations.
>>>>>
>>>>> I've replaced parameter type with Frame instead if Window to avoid such misunderstanding. Frame still can be removed from taskbar by f.setType(Window.Type.UTILITY) call.
>>>>>
>>>>>> I do not know if we can say something stronger than that ?
>>>>>> Is this the case on all platforms ?
>>>>> This part of API is supported for Windows only.
>>>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/01/
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Alexander.
>>>>>
>>>>> On 14.03.2017 0:52, Phil Race wrote:
>>>>>> The JCK comments in the bug are :
>>>>>> >This may be a specification issue.
>>>>>> >Window progress is not displayed in taskbar as specified.
>>>>>> >The spec states that progress is displayed in a platform-dependent way.
>>>>>> I>f progress is not in fact displayed under some circumstances, that should be specified.
>>>>>>
>>>>>> So they already know the window isn't visible and are asking for an explanation
>>>>>> of the circumstances for this so I don't think this update will satisfy them without
>>>>>> more explanation.
>>>>>>
>>>>>> At the very least we need to add that
>>>>>> "Some {@code Window}s are not visible in the task bar.
>>>>>> For example undecorated Windows may not be visible".
>>>>>>
>>>>>> I do not know if we can say something stronger than that ?
>>>>>> Is this the case on all platforms ?
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> please review the fix
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/
>>>>>>>
>>>>>>> for the issue
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8176528
>>>>>>>
>>>>>>> The test uses java.awt.Window which doesn't have button for its window in the taskbar, thus we can't show progress for this window there.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Alexander Zvegintsev
> It has no representation on windows, but I assume it can have such on other platforms like OSX/Unity?
OSX/Unity functionality doesn't have per window concept, they have per
application. For these operating system you should use
setProgressValue() instead of setWindowProgressValue()(and so on).

> We also exclude JWindow.
It doesn't show up in the taskbar too like java.awt.Window.

--
Thanks,
Alexander.

On 14.03.2017 20:44, Sergey Bylokhov wrote:

> It has no representation on windows, but I assume it can have such on other platforms like OSX/Unity?
>
>> It is fine too, because Dialog has no representation in the taskbar too.
> We also exclude JWindow.
>
>> --
>> Thanks,
>> Alexander.
>>
>> On 14.03.2017 15:56, Philip Race wrote:
>>> Hi,
>>>
>>> I realise I need to clarify one thing that may be important.
>>> Previously with Window this could apply to a Dialog.
>>> Now it cannot. Are we disabling an important case with this change ?
>>>
>>> -phil
>>>
>>> On 3/14/17, 5:54 AM, Alexander Zvegintsev wrote:
>>>> There is no precedents here:
>>>>
>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/02/
>>>>
>>>> Thanks,
>>>> Alexander.
>>>>
>>>> On 14/03/2017 15:40, Philip Race wrote:
>>>>> with this change maybe we should be renaming the parameters and update the doc
>>>>> ie
>>>>> 279      * @param w window
>>>>> could be
>>>>> @param f frame
>>>>> ?
>>>>>
>>>>> Or is there precedent for what you have right now ?
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 3/14/17, 5:33 AM, Alexander Zvegintsev wrote:
>>>>>>> So they already know the window isn't visible and are asking for an explanation
>>>>>>> of the circumstances for this so I don't think this update will satisfy them without
>>>>>>> more explanation.
>>>>>>>
>>>>>>> At the very least we need to add that
>>>>>>> "Some {@code Window}s are not visible in the task bar.
>>>>>>> For example undecorated Windows may not be visible".
>>>>>> Actually java.awt.Window is not visible in taskbar because of its window style flags(WS_EX_NOACTIVATE, WS_EX_TOOLWINDOW), it has nothing to do with decorations.
>>>>>>
>>>>>> I've replaced parameter type with Frame instead if Window to avoid such misunderstanding. Frame still can be removed from taskbar by f.setType(Window.Type.UTILITY) call.
>>>>>>
>>>>>>> I do not know if we can say something stronger than that ?
>>>>>>> Is this the case on all platforms ?
>>>>>> This part of API is supported for Windows only.
>>>>>>
>>>>>>
>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/01/
>>>>>>
>>>>>> --
>>>>>> Thanks,
>>>>>> Alexander.
>>>>>>
>>>>>> On 14.03.2017 0:52, Phil Race wrote:
>>>>>>> The JCK comments in the bug are :
>>>>>>>> This may be a specification issue.
>>>>>>>> Window progress is not displayed in taskbar as specified.
>>>>>>>> The spec states that progress is displayed in a platform-dependent way.
>>>>>>> I>f progress is not in fact displayed under some circumstances, that should be specified.
>>>>>>>
>>>>>>> So they already know the window isn't visible and are asking for an explanation
>>>>>>> of the circumstances for this so I don't think this update will satisfy them without
>>>>>>> more explanation.
>>>>>>>
>>>>>>> At the very least we need to add that
>>>>>>> "Some {@code Window}s are not visible in the task bar.
>>>>>>> For example undecorated Windows may not be visible".
>>>>>>>
>>>>>>> I do not know if we can say something stronger than that ?
>>>>>>> Is this the case on all platforms ?
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> please review the fix
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/
>>>>>>>>
>>>>>>>> for the issue
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8176528
>>>>>>>>
>>>>>>>> The test uses java.awt.Window which doesn't have button for its window in the taskbar, thus we can't show progress for this window there.
>>>>>>>>
>>>>>>>>
>>>>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Alexander Zvegintsev
It turned out that if Dialog has no owner(e.g. new Dialog((Frame) null))
it is visible in the taskbar.

So I am reverting API change.

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/03/

Thanks,
Alexander.

On 14/03/2017 23:43, Alexander Zvegintsev wrote:

>> It has no representation on windows, but I assume it can have such on
>> other platforms like OSX/Unity?
> OSX/Unity functionality doesn't have per window concept, they have per
> application. For these operating system you should use
> setProgressValue() instead of setWindowProgressValue()(and so on).
>
>> We also exclude JWindow.
> It doesn't show up in the taskbar too like java.awt.Window.
>
> --
> Thanks,
> Alexander.
>
> On 14.03.2017 20:44, Sergey Bylokhov wrote:
>> It has no representation on windows, but I assume it can have such on
>> other platforms like OSX/Unity?
>>
>>> It is fine too, because Dialog has no representation in the taskbar
>>> too.
>> We also exclude JWindow.
>>
>>> --
>>> Thanks,
>>> Alexander.
>>>
>>> On 14.03.2017 15:56, Philip Race wrote:
>>>> Hi,
>>>>
>>>> I realise I need to clarify one thing that may be important.
>>>> Previously with Window this could apply to a Dialog.
>>>> Now it cannot. Are we disabling an important case with this change ?
>>>>
>>>> -phil
>>>>
>>>> On 3/14/17, 5:54 AM, Alexander Zvegintsev wrote:
>>>>> There is no precedents here:
>>>>>
>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/02/
>>>>>
>>>>> Thanks,
>>>>> Alexander.
>>>>>
>>>>> On 14/03/2017 15:40, Philip Race wrote:
>>>>>> with this change maybe we should be renaming the parameters and
>>>>>> update the doc
>>>>>> ie
>>>>>> 279      * @param w window
>>>>>> could be
>>>>>> @param f frame
>>>>>> ?
>>>>>>
>>>>>> Or is there precedent for what you have right now ?
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 3/14/17, 5:33 AM, Alexander Zvegintsev wrote:
>>>>>>>> So they already know the window isn't visible and are asking
>>>>>>>> for an explanation
>>>>>>>> of the circumstances for this so I don't think this update will
>>>>>>>> satisfy them without
>>>>>>>> more explanation.
>>>>>>>>
>>>>>>>> At the very least we need to add that
>>>>>>>> "Some {@code Window}s are not visible in the task bar.
>>>>>>>> For example undecorated Windows may not be visible".
>>>>>>> Actually java.awt.Window is not visible in taskbar because of
>>>>>>> its window style flags(WS_EX_NOACTIVATE, WS_EX_TOOLWINDOW), it
>>>>>>> has nothing to do with decorations.
>>>>>>>
>>>>>>> I've replaced parameter type with Frame instead if Window to
>>>>>>> avoid such misunderstanding. Frame still can be removed from
>>>>>>> taskbar by f.setType(Window.Type.UTILITY) call.
>>>>>>>
>>>>>>>> I do not know if we can say something stronger than that ?
>>>>>>>> Is this the case on all platforms ?
>>>>>>> This part of API is supported for Windows only.
>>>>>>>
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/01/
>>>>>>>
>>>>>>> --
>>>>>>> Thanks,
>>>>>>> Alexander.
>>>>>>>
>>>>>>> On 14.03.2017 0:52, Phil Race wrote:
>>>>>>>> The JCK comments in the bug are :
>>>>>>>>> This may be a specification issue.
>>>>>>>>> Window progress is not displayed in taskbar as specified.
>>>>>>>>> The spec states that progress is displayed in a
>>>>>>>>> platform-dependent way.
>>>>>>>> I>f progress is not in fact displayed under some circumstances,
>>>>>>>> that should be specified.
>>>>>>>>
>>>>>>>> So they already know the window isn't visible and are asking
>>>>>>>> for an explanation
>>>>>>>> of the circumstances for this so I don't think this update will
>>>>>>>> satisfy them without
>>>>>>>> more explanation.
>>>>>>>>
>>>>>>>> At the very least we need to add that
>>>>>>>> "Some {@code Window}s are not visible in the task bar.
>>>>>>>> For example undecorated Windows may not be visible".
>>>>>>>>
>>>>>>>> I do not know if we can say something stronger than that ?
>>>>>>>> Is this the case on all platforms ?
>>>>>>>>
>>>>>>>> -phil.
>>>>>>>>
>>>>>>>> On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> please review the fix
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/
>>>>>>>>>
>>>>>>>>> for the issue
>>>>>>>>>
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8176528
>>>>>>>>>
>>>>>>>>> The test uses java.awt.Window which doesn't have button for
>>>>>>>>> its window in the taskbar, thus we can't show progress for
>>>>>>>>> this window there.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Philip Race
Good that got cleared up but since bar slight change in the wording
we are back to v0 of the webrev, then we are also back to v0 of my
comments. What are you going to say to JCK about what windows
they can expect to be  visible ?
Can we say
- Frames  are always visible
- Dialogs are always visible if they have no owner
- All other cases (eg Window) are platform dependent ?
   Or can we say for the latter, other descendants of Window (including
    Window itself) are never visible ?

-phil.

On 3/15/17, 7:15 AM, Alexander Zvegintsev wrote:

> It turned out that if Dialog has no owner(e.g. new Dialog((Frame)
> null)) it is visible in the taskbar.
>
> So I am reverting API change.
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/03/
>
> Thanks,
> Alexander.
>
> On 14/03/2017 23:43, Alexander Zvegintsev wrote:
>>> It has no representation on windows, but I assume it can have such
>>> on other platforms like OSX/Unity?
>> OSX/Unity functionality doesn't have per window concept, they have
>> per application. For these operating system you should use
>> setProgressValue() instead of setWindowProgressValue()(and so on).
>>
>>> We also exclude JWindow.
>> It doesn't show up in the taskbar too like java.awt.Window.
>>
>> --
>> Thanks,
>> Alexander.
>>
>> On 14.03.2017 20:44, Sergey Bylokhov wrote:
>>> It has no representation on windows, but I assume it can have such
>>> on other platforms like OSX/Unity?
>>>
>>>> It is fine too, because Dialog has no representation in the taskbar
>>>> too.
>>> We also exclude JWindow.
>>>
>>>> --
>>>> Thanks,
>>>> Alexander.
>>>>
>>>> On 14.03.2017 15:56, Philip Race wrote:
>>>>> Hi,
>>>>>
>>>>> I realise I need to clarify one thing that may be important.
>>>>> Previously with Window this could apply to a Dialog.
>>>>> Now it cannot. Are we disabling an important case with this change ?
>>>>>
>>>>> -phil
>>>>>
>>>>> On 3/14/17, 5:54 AM, Alexander Zvegintsev wrote:
>>>>>> There is no precedents here:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/02/
>>>>>>
>>>>>> Thanks,
>>>>>> Alexander.
>>>>>>
>>>>>> On 14/03/2017 15:40, Philip Race wrote:
>>>>>>> with this change maybe we should be renaming the parameters and
>>>>>>> update the doc
>>>>>>> ie
>>>>>>> 279      * @param w window
>>>>>>> could be
>>>>>>> @param f frame
>>>>>>> ?
>>>>>>>
>>>>>>> Or is there precedent for what you have right now ?
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 3/14/17, 5:33 AM, Alexander Zvegintsev wrote:
>>>>>>>>> So they already know the window isn't visible and are asking
>>>>>>>>> for an explanation
>>>>>>>>> of the circumstances for this so I don't think this update
>>>>>>>>> will satisfy them without
>>>>>>>>> more explanation.
>>>>>>>>>
>>>>>>>>> At the very least we need to add that
>>>>>>>>> "Some {@code Window}s are not visible in the task bar.
>>>>>>>>> For example undecorated Windows may not be visible".
>>>>>>>> Actually java.awt.Window is not visible in taskbar because of
>>>>>>>> its window style flags(WS_EX_NOACTIVATE, WS_EX_TOOLWINDOW), it
>>>>>>>> has nothing to do with decorations.
>>>>>>>>
>>>>>>>> I've replaced parameter type with Frame instead if Window to
>>>>>>>> avoid such misunderstanding. Frame still can be removed from
>>>>>>>> taskbar by f.setType(Window.Type.UTILITY) call.
>>>>>>>>
>>>>>>>>> I do not know if we can say something stronger than that ?
>>>>>>>>> Is this the case on all platforms ?
>>>>>>>> This part of API is supported for Windows only.
>>>>>>>>
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/01/
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thanks,
>>>>>>>> Alexander.
>>>>>>>>
>>>>>>>> On 14.03.2017 0:52, Phil Race wrote:
>>>>>>>>> The JCK comments in the bug are :
>>>>>>>>>> This may be a specification issue.
>>>>>>>>>> Window progress is not displayed in taskbar as specified.
>>>>>>>>>> The spec states that progress is displayed in a
>>>>>>>>>> platform-dependent way.
>>>>>>>>> I>f progress is not in fact displayed under some
>>>>>>>>> circumstances, that should be specified.
>>>>>>>>>
>>>>>>>>> So they already know the window isn't visible and are asking
>>>>>>>>> for an explanation
>>>>>>>>> of the circumstances for this so I don't think this update
>>>>>>>>> will satisfy them without
>>>>>>>>> more explanation.
>>>>>>>>>
>>>>>>>>> At the very least we need to add that
>>>>>>>>> "Some {@code Window}s are not visible in the task bar.
>>>>>>>>> For example undecorated Windows may not be visible".
>>>>>>>>>
>>>>>>>>> I do not know if we can say something stronger than that ?
>>>>>>>>> Is this the case on all platforms ?
>>>>>>>>>
>>>>>>>>> -phil.
>>>>>>>>>
>>>>>>>>> On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> please review the fix
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/
>>>>>>>>>>
>>>>>>>>>> for the issue
>>>>>>>>>>
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8176528
>>>>>>>>>>
>>>>>>>>>> The test uses java.awt.Window which doesn't have button for
>>>>>>>>>> its window in the taskbar, thus we can't show progress for
>>>>>>>>>> this window there.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Sergey Bylokhov
I guess that we cannot guarantee that some windows are visible and other one are not.
We can say something general like in the current fix, or we can provide an explanation of our internal implementation.

15 марта 2017 г., в 18:49, Philip Race <[hidden email]> написал(а):

Good that got cleared up but since bar slight change in the wording
we are back to v0 of the webrev, then we are also back to v0 of my
comments. What are you going to say to JCK about what windows
they can expect to be  visible ?
Can we say
- Frames  are always visible

It is not necessary, if the frame has utility type.

- Dialogs are always visible if they have no owner

This is implementation details on windows. I am not sure why it was implemented this way, is it really intended behavior or not.

- All other cases (eg Window) are platform dependent ?
 Or can we say for the latter, other descendants of Window (including
  Window itself) are never visible ?


Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Philip Race
The current fix isn't even "general" in this respect.
Unless there are some existing words somewhere, in
which case we would just have pointed JCK to those ..

On 3/15/17, 9:12 AM, Sergey Bylokhov wrote:
I guess that we cannot guarantee that some windows are visible and other one are not.
We can say something general like in the current fix, or we can provide an explanation of our internal implementation.

implNote isn't something JCK can (or should) use.
We can say something is not specified since it is platform dependent
and then they just know they can't test it .. although may not like it.

15 марта 2017 г., в 18:49, Philip Race <[hidden email]> написал(а):

Good that got cleared up but since bar slight change in the wording
we are back to v0 of the webrev, then we are also back to v0 of my
comments. What are you going to say to JCK about what windows
they can expect to be  visible ?
Can we say
- Frames  are always visible

It is not necessary, if the frame has utility type.

So can we say this with that qualification ?


- Dialogs are always visible if they have no owner

This is implementation details on windows. I am not sure why it was implemented this way, is it really intended behavior or not.

So we'd have to say its platform and implementation dependent
and add an implNote for audiences other than JCK.

- All other cases (eg Window) are platform dependent ?
 Or can we say for the latter, other descendants of Window (including
  Window itself) are never visible ?

What about the last point ?

-phil.
Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Sergey Bylokhov

The current fix isn't even "general" in this respect.
Unless there are some existing words somewhere, in
which case we would just have pointed JCK to those ..

All this stuff have a notion that «xxx in a platform-dependent way.». The only things we can say is that we will try to show a something.


On 3/15/17, 9:12 AM, Sergey Bylokhov wrote:
I guess that we cannot guarantee that some windows are visible and other one are not.
We can say something general like in the current fix, or we can provide an explanation of our internal implementation.

implNote isn't something JCK can (or should) use.
We can say something is not specified since it is platform dependent
and then they just know they can't test it .. although may not like it.

15 марта 2017 г., в 18:49, Philip Race <[hidden email]> написал(а):

Good that got cleared up but since bar slight change in the wording
we are back to v0 of the webrev, then we are also back to v0 of my
comments. What are you going to say to JCK about what windows
they can expect to be  visible ?
Can we say
- Frames  are always visible

It is not necessary, if the frame has utility type.

So can we say this with that qualification ?

This is also implementation detail, that such windows are not visible in taskbar. This is not specified anywhere and can be changed in the future.



- Dialogs are always visible if they have no owner

This is implementation details on windows. I am not sure why it was implemented this way, is it really intended behavior or not.

So we'd have to say its platform and implementation dependent
and add an implNote for audiences other than JCK.

Not sure that we can describe all the cases when it works.

To me the description like «Has no effect if this window is not visible in the task area.» is enough because it also covered the case when the window is invisible.


- All other cases (eg Window) are platform dependent ?
 Or can we say for the latter, other descendants of Window (including
  Window itself) are never visible ?

What about the last point ?

It depends from the implementation.

Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Philip Race

On 3/15/17, 9:48 AM, Sergey Bylokhov wrote:

The current fix isn't even "general" in this respect.
Unless there are some existing words somewhere, in
which case we would just have pointed JCK to those ..

All this stuff have a notion that «xxx in a platform-dependent way.». The only things we can say is that we will try to show a something.


On 3/15/17, 9:12 AM, Sergey Bylokhov wrote:
I guess that we cannot guarantee that some windows are visible and other one are not.
We can say something general like in the current fix, or we can provide an explanation of our internal implementation.

implNote isn't something JCK can (or should) use.
We can say something is not specified since it is platform dependent
and then they just know they can't test it .. although may not like it.

15 марта 2017 г., в 18:49, Philip Race <[hidden email]> написал(а):

Good that got cleared up but since bar slight change in the wording
we are back to v0 of the webrev, then we are also back to v0 of my
comments. What are you going to say to JCK about what windows
they can expect to be  visible ?
Can we say
- Frames  are always visible

It is not necessary, if the frame has utility type.

So can we say this with that qualification ?

This is also implementation detail, that such windows are not visible in taskbar. This is not specified anywhere and can be changed in the future.

If this is consistent in our current implementation on all platforms then
there is no problem making this part of the spec and changing the spec in
the future if that changes.

We have to say something. I can't agree the current words are enough.

-phil.




- Dialogs are always visible if they have no owner

This is implementation details on windows. I am not sure why it was implemented this way, is it really intended behavior or not.

So we'd have to say its platform and implementation dependent
and add an implNote for audiences other than JCK.

Not sure that we can describe all the cases when it works.

To me the description like «Has no effect if this window is not visible in the task area.» is enough because it also covered the case when the window is invisible.


- All other cases (eg Window) are platform dependent ?
 Or can we say for the latter, other descendants of Window (including
  Window itself) are never visible ?

What about the last point ?

It depends from the implementation.

Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Sergey Bylokhov
It is not necessary, if the frame has utility type.

So can we say this with that qualification ?

This is also implementation detail, that such windows are not visible in taskbar. This is not specified anywhere and can be changed in the future.

If this is consistent in our current implementation on all platforms then
there is no problem making this part of the spec and changing the spec in
the future if that changes.

It was not implemented on systems other than windows, so if we change the signature we will not be able implement/change this on linux/osx.


We have to say something. I can't agree the current words are enough.

What is wrong in the current wording? If the element is not visible in taskbar we cannot show something on top of it. We never specified when something is visible/non-visible in taskbar.
We can update the words, but it will be good to use current methods signatures.


-phil.




- Dialogs are always visible if they have no owner

This is implementation details on windows. I am not sure why it was implemented this way, is it really intended behavior or not.

So we'd have to say its platform and implementation dependent
and add an implNote for audiences other than JCK.

Not sure that we can describe all the cases when it works.

To me the description like «Has no effect if this window is not visible in the task area.» is enough because it also covered the case when the window is invisible.


- All other cases (eg Window) are platform dependent ?
 Or can we say for the latter, other descendants of Window (including
  Window itself) are never visible ?

What about the last point ?

It depends from the implementation.



Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Philip Race

Even if all we can add (to what is already proposed) is
"whether an icon for a window is displayable in the task bar is
dependent on all of window type, platform, and implementation"
then I think that clearer than the current words which could be
misinterpreted as meaning something like addressing that
if you call hide() then of course it disappears ..

-phil.

On 3/15/17, 10:02 AM, Sergey Bylokhov wrote:
It is not necessary, if the frame has utility type.

So can we say this with that qualification ?

This is also implementation detail, that such windows are not visible in taskbar. This is not specified anywhere and can be changed in the future.

If this is consistent in our current implementation on all platforms then
there is no problem making this part of the spec and changing the spec in
the future if that changes.

It was not implemented on systems other than windows, so if we change the signature we will not be able implement/change this on linux/osx.


We have to say something. I can't agree the current words are enough.

What is wrong in the current wording? If the element is not visible in taskbar we cannot show something on top of it. We never specified when something is visible/non-visible in taskbar.
We can update the words, but it will be good to use current methods signatures.


-phil.




- Dialogs are always visible if they have no owner

This is implementation details on windows. I am not sure why it was implemented this way, is it really intended behavior or not.

So we'd have to say its platform and implementation dependent
and add an implNote for audiences other than JCK.

Not sure that we can describe all the cases when it works.

To me the description like «Has no effect if this window is not visible in the task area.» is enough because it also covered the case when the window is invisible.


- All other cases (eg Window) are platform dependent ?
 Or can we say for the latter, other descendants of Window (including
  Window itself) are never visible ?

What about the last point ?

It depends from the implementation.



Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Alexander Zvegintsev

How about that version?

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/04/

Thanks,
Alexander.
On 15/03/2017 20:18, Philip Race wrote:

Even if all we can add (to what is already proposed) is
"whether an icon for a window is displayable in the task bar is
dependent on all of window type, platform, and implementation"
then I think that clearer than the current words which could be
misinterpreted as meaning something like addressing that
if you call hide() then of course it disappears ..

-phil.

On 3/15/17, 10:02 AM, Sergey Bylokhov wrote:
It is not necessary, if the frame has utility type.

So can we say this with that qualification ?

This is also implementation detail, that such windows are not visible in taskbar. This is not specified anywhere and can be changed in the future.

If this is consistent in our current implementation on all platforms then
there is no problem making this part of the spec and changing the spec in
the future if that changes.

It was not implemented on systems other than windows, so if we change the signature we will not be able implement/change this on linux/osx.


We have to say something. I can't agree the current words are enough.

What is wrong in the current wording? If the element is not visible in taskbar we cannot show something on top of it. We never specified when something is visible/non-visible in taskbar.
We can update the words, but it will be good to use current methods signatures.


-phil.




- Dialogs are always visible if they have no owner

This is implementation details on windows. I am not sure why it was implemented this way, is it really intended behavior or not.

So we'd have to say its platform and implementation dependent
and add an implNote for audiences other than JCK.

Not sure that we can describe all the cases when it works.

To me the description like «Has no effect if this window is not visible in the task area.» is enough because it also covered the case when the window is invisible.


- All other cases (eg Window) are platform dependent ?
 Or can we say for the latter, other descendants of Window (including
  Window itself) are never visible ?

What about the last point ?

It depends from the implementation.




Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [9] Review request for 8176528: Progress state for window is not displayed in taskbar

Philip Race
+1 from me.

-phil.

On 3/15/17, 10:47 AM, Alexander Zvegintsev wrote:

How about that version?

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/04/

Thanks,
Alexander.
On 15/03/2017 20:18, Philip Race wrote:

Even if all we can add (to what is already proposed) is
"whether an icon for a window is displayable in the task bar is
dependent on all of window type, platform, and implementation"
then I think that clearer than the current words which could be
misinterpreted as meaning something like addressing that
if you call hide() then of course it disappears ..

-phil.

On 3/15/17, 10:02 AM, Sergey Bylokhov wrote:
It is not necessary, if the frame has utility type.

So can we say this with that qualification ?

This is also implementation detail, that such windows are not visible in taskbar. This is not specified anywhere and can be changed in the future.

If this is consistent in our current implementation on all platforms then
there is no problem making this part of the spec and changing the spec in
the future if that changes.

It was not implemented on systems other than windows, so if we change the signature we will not be able implement/change this on linux/osx.


We have to say something. I can't agree the current words are enough.

What is wrong in the current wording? If the element is not visible in taskbar we cannot show something on top of it. We never specified when something is visible/non-visible in taskbar.
We can update the words, but it will be good to use current methods signatures.


-phil.




- Dialogs are always visible if they have no owner

This is implementation details on windows. I am not sure why it was implemented this way, is it really intended behavior or not.

So we'd have to say its platform and implementation dependent
and add an implNote for audiences other than JCK.

Not sure that we can describe all the cases when it works.

To me the description like «Has no effect if this window is not visible in the task area.» is enough because it also covered the case when the window is invisible.


- All other cases (eg Window) are platform dependent ?
 Or can we say for the latter, other descendants of Window (including
  Window itself) are never visible ?

What about the last point ?

It depends from the implementation.




12