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.

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.



-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.



--
Best regards, Sergey.

Reply via email to