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.
