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

[Anton V. Tarasov]

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