On 4/8/20, 5:27 PM, Sergey Bylokhov wrote:
On 4/8/20 5:14 pm, Philip Race wrote:
I was trying to make it flow better and avoid some repetition
I did not think it necessary to enumerate subclasses> What motivates
you to include "behavior" ?
To cover cases like animation during maximization/minimization of
windows,
or animations when the window appeared on the screen.
Behaviour means more than that to me. I think listing sample visual
effects and just
including animation as an example of a visual effect is sufficient.
Visual effects such as halos, shadows, motion effects and animations may
be applied to the window by the desktop window management system.
These are outside the knowledge and control of the AWT and so for the
purposes of this specification are not considered part of the
AWT-defined window.
I have never seen "AWT-defined window" term, I assume we never used it
before is it
clear enough? Usually, we use "Top level window" which will cover AWT
and Swing.
But the point here is the intent for this shape to visually defines the
window,
but the desktop did something else.
So the intent is to distinguish what the Java application requested vs
what happened.
I think it is clear enough.
Also Swing does not create Windows. Does it have native code to create
its own ?
No, it just asks AWT to. So don't worry about that.
-phil.
-phil.
On 4/8/20, 5:03 PM, Sergey Bylokhov wrote:
On 4/6/20 12:24 pm, Philip Race wrote:
If we have to add anything I prefer the following :
Visual effects such as halos, shadows, motion effects and
animations may
be added by the desktop and affect the actual or perceived
position, dimensions
or shape of the window.
These are usually outside the knowledge and control of the JDK and
so for the
purposes of this specification are not considered part of the
AWT-specified window.
Are this text more clear than my version? I create it using the text
forms/terms which
are already present in the javadoc.
The text where we describe bounds/location optionality:
126 * Note: the location and size of top-level windows (including
127 * {@code Window}s, {@code Frame}s, and {@code Dialog}s)
128 * are under the control of the desktop's window management
system.
129 * Calls to {@code setLocation}, {@code setSize}, and
130 * {@code setBounds} are requests (not directives) which are
131 * forwarded to the window management system. Every effort
will be
132 * made to honor such requests. However, in some cases the window
133 * management system may ignore such requests, or modify the
requested
134 * geometry in order to place and size the {@code Window} in a way
135 * that more closely matches the desktop settings.
The new text about visual perception:
137 * The visual appearance and behavior of top-level windows
(including
138 * normal/shaped/translucent/undecorated {@code Window}s,
{@code Frame}s,
139 * {@code Dialog}s) are under the control of the desktop's
window management
140 * system. The visual effects as shadows, motion effects,
animations,
141 * and others may not be controlled by the applications but
work according to
142 * the desktop settings.
Both look aligned.
