<AWT Dev> [8] Request for review: JDK-8022512 JLightweightFrame: the content pane should be transparent

[Anthony Petrov]

Looks fine to me. Thanks!

--
best regards,
Anthony

On 09/14/13 16:41, Anton V. Tarasov wrote:
> Here's the fix with a property:
>
> http://cr.openjdk.java.net/~ant/JDK-8022512/webrev.1
>
> Thanks,
> Anton.
>
> On 9/11/13 1:24 PM, Anthony Petrov wrote:
>> Thanks for the clarification. Sounds reasonable.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 09/11/2013 01:19 PM, Anton V. Tarasov wrote:
>>> On 11.09.2013 12:43, Anthony Petrov wrote:
>>>> Sure, I'm fine if for now this is an experimental, turned-off by
>>>> default feature.
>>>
>>> That's fine.
>>>
>>>>
>>>> BTW, do we really have to make any changes in JDK for it? Couldn't
>>>> app's or demo's code itself call the setOpaque(false) on its content
>>>> pane (from an addNotify() override, for example)?
>>>
>>> Sure, and this is what I do in the demo. However, the Content Pane, as
>>> the JLF frame itself are "transparent" to a user. The user just adds
>>> his/her JComponent to SwingNode and he/she theoretically should not
>>> bother about how we display it. At the same time, getParent() returns
>>> just the content pane, not null.
>>>
>>> So, we can tell the user either (1) feel free to retrieve the parent of
>>> your JComponent and go ahead with it or (2) use the experimental
>>> property to alter the transparency. In my opinion, we should discourage
>>> people from changing anything in the content pane or JLF on their own.
>>> That's my reasoning.
>>>
>>> Thanks,
>>> Anton
>>>
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 09/11/2013 11:19 AM, Anton V. Tarasov wrote:
>>>>> On 11.09.2013 0:11, Anthony Petrov wrote:
>>>>>>> I just thought there might be an interest in this functionality.
>>>>>>
>>>>>> Personally, I'd prefer to hold back with this feature then, until
>>>>>> such
>>>>>> an interest is explicitly expressed by developers.
>>>>>>
>>>>>> If we still decide to implement this now though, then I'd consider
>>>>>> the
>>>>>> option #2: setting the cut-out shape for the Swing content pane. We
>>>>>> have a similar API already [1], although it's currently applicable to
>>>>>> the HW/LW Mixing functionality only. We could either extend its
>>>>>> specification and area of applicability, or introduce a new similar
>>>>>> method.
>>>>>>
>>>>>> [1] com.sun.awt.AWTUtilities.setComponentMixingCutoutShape()
>>>>>
>>>>> Right, [1] is what I'd just looked at.
>>>>>
>>>>> Ok, I think this is a topic which can be discussed on the upcoming J1
>>>>> Interop BOF.
>>>>>
>>>>> In both cases, whether we decide to support it completely or not to
>>>>> support officially, I guess having it as an experimental feature (via
>>>>> introducing a property), switched off by default, wouldn't make any
>>>>> harm. Will it? Why I'm requesting this, is because I have a demo
>>>>> for J1
>>>>> which would benefit (as a demo) from this a lot. Moreover, it would
>>>>> be a
>>>>> good illustration to the discussion. (Currently, it hacks the
>>>>> transparency).
>>>>>
>>>>> So, what do you think about the property?
>>>>>
>>>>> Thanks,
>>>>> Anton.
>>>>>
>>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 09/10/2013 10:10 PM, Anton V. Tarasov wrote:
>>>>>>> Hi Anthony,
>>>>>>>
>>>>>>> Thanks for your point.
>>>>>>>
>>>>>>> On 09.09.2013 17:26, Anthony Petrov wrote:
>>>>>>>> Hi Anton,
>>>>>>>>
>>>>>>>> The fix looks good I suppose. However, are you sure we want to
>>>>>>>> support
>>>>>>>> transparent content in embedded components? I understand that it's
>>>>>>>> cool and stuff, but do we have to? We don't support transparency
>>>>>>>> for
>>>>>>>> heavyweight embedded frames (e.g. applets), why would we want to
>>>>>>>> support it for the JLF? How are you going to handle mouse events on
>>>>>>>> transparent parts? Will JFXPanel support the same?
>>>>>>>
>>>>>>> You're right, mouse events will anyway be caught by SwingNode on the
>>>>>>> transparent area. What would we do with that? I'm just thinking
>>>>>>> of the
>>>>>>> following:
>>>>>>>
>>>>>>> 1. Leave the Content Pane opaque.
>>>>>>>
>>>>>>> 2. Theoretically. Request a user to set a cutoff shape on the
>>>>>>> lightweight content, convert it then to a clip shape for SwingNode.
>>>>>>>
>>>>>>> 3. Document the restrictions concerning mouse events, and provide a
>>>>>>> property which would switch off the content pane's opacity.
>>>>>>>
>>>>>>> What do you think of the third approach? What if a node behind a
>>>>>>> semi-transparent SwingNode doesn't have any interactivity in
>>>>>>> mind, and
>>>>>>> simply is a one way display? I just thought there might be an
>>>>>>> interest
>>>>>>> in this functionality. So, providing a documented or even
>>>>>>> undocumented
>>>>>>> property could be useful.
>>>>>>>
>>>>>>> With regards to JFXPanel, as I can see it's the scene which stops
>>>>>>> transparency of the whole hierarchy (JFXPanel itself allows zero
>>>>>>> opacity). Allowing it to be transparent would make the case
>>>>>>> symmetrical.
>>>>>>> Wouldn't it?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Anton.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 09/03/2013 03:01 PM, Anton V. Tarasov wrote:
>>>>>>>>> Please, review a fix.
>>>>>>>>>
>>>>>>>>> jira: https://bugs.openjdk.java.net/browse/JDK-8022512
>>>>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8022512/webrev.0/
>>>>>>>>>
>>>>>>>>> Both JLF and its Content Pane are "transparent" to the client app,
>>>>>>>>> e.g.
>>>>>>>>> SwingNode, in terms of functionality. They should be physically
>>>>>>>>> transparent as well, in order to support translucent Swing
>>>>>>>>> content.
>>>>>>>>> This
>>>>>>>>> is the case for JLF, but not for the Content Pane yet.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Anton.
>>>>>>>
>>>>>
>>>
>