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.
