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

[Anthony Petrov]

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