<AWT Dev> RFR: 8232744 j.awt.Window::setShape(Shape) paints visible artifacts outside of the given shape
Sergey Bylokhov
Sergey.Bylokhov at oracle.com
Thu Apr 9 00:27:37 UTC 2020
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.
More information about the awt-dev
mailing list