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