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.
