Skip to main content

Enable/disable mouse events to a node or group of nodes?

8 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Jim Clarke

The particular demo I was porting actually had the nodes visible, but
had some that had opaque set to zero.
So I guess that is why they still got mouse events. I worked around the
issue using the visible
attribute, (when the old nodes started fading out, I turned on visible
for the new nodes that where to fade in).

I am not sure that this is the best approach for this fade-out/fade-in
pattern.

jim

Chris Campbell wrote:
> Hi Jim,
>
> I'm pretty sure that invisible SGNodes (i.e. isVisible() returns
> false) should not be receiving mouse events; if they are, that sounds
> like a bug.
>
> That said, in the Jazz-based JavaFX interpreter, there was a separate
> flag (Node.selectable, mapped to ZNode.pickable) for controlling
> whether a node received mouse events, and that was independent of
> visibility. When I was working on the port from Jazz to Scenario, I
> punted on this (there's still a TODO in the definition of
> Node.selectable reflecting that fact).
>
> Someone (probably Hans, since he's been responsible for input stuff)
> will need to decide what to do about all this. One option would be to
> drop the Node.selectable property altogether. If we do still want to
> maintain Node.selectable and keep it independent from Node.visible,
> then we'll probably need to add a selectable property to SGNode. In
> that case, the remaining question would be: do we only look at the
> selectable property, or should invisible (but selectable) nodes still
> receive input events?
>
> Thanks,
> Chris
>
>
> Jim Clarke wrote:
>> Is there an easy want to enable / disable mouse events for an SGNode
>> or SGGroup of nodes,
>> besides removing/adding the mouse listener?
>> Similar to java.awt.Component.enableEvents/disableEvents(long).
>>
>> I have a situation where a node is invisible until another button is
>> pushed.
>> However, the node still receives mouse events while invisible. I want
>> to disable
>> mouse events while it is invisible, then enable them when it becomes
>> visible.
>>
>> Or is there a different way to accomplish this?
>>
>> jim

--
* Jim Clarke *
OEM Software Sales - Principal Engineer

*Sun Microsystems, Inc.*
Phone x51695/+1 877 300 6162
Mobile 407.620.9065
Fax 407.380.1143
Email Jim.Clarke@Sun.COM

[att1.html]

Chet Haase

The decision to have a separate visibility property (which
controls the "active" state of a node, such as whether it
receives events) in addition to the opacity property
came from discussions we had around overloading the
opacity property too much.

There's probably more that I'm not remembering, but two
points come to mind:
- Setting a node to be transparent (opacity==0) to control
whether it's an active node in the scene felt like a hack.
Opacity is usually about how something is rendered, not
whether it is receiving events/etc.
- There may be cases when a node is transparent (opacity==0)
when you still want it to be active. For example, imagine
a node that is pulsating between opaque and transparent - if
we overload opacity==0 to mean that it can't receive events,
then this otherwise active node will pass through inactive
states in the process of performing this animation. So if
someone happens to click it at the wrong time, that
click won't be received.

I agree that setting visibility to true *and* fading a node
in seems like overkill (I've had to do the same in my demos), but
it feels less hacky than previous cases where I'd have to
set opacity==0 to mean "this node isn't active"

We can talk about changing this API as appropriate, but it
seemed worth mentioning the logic behind the current API.

Chet.

Jim Clarke wrote:
> The particular demo I was porting actually had the nodes visible, but
> had some that had opaque set to zero.
> So I guess that is why they still got mouse events. I worked around the
> issue using the visible
> attribute, (when the old nodes started fading out, I turned on visible
> for the new nodes that where to fade in).
>
> I am not sure that this is the best approach for this fade-out/fade-in
> pattern.
>
> jim
>
>
> Chris Campbell wrote:
>> Hi Jim,
>>
>> I'm pretty sure that invisible SGNodes (i.e. isVisible() returns
>> false) should not be receiving mouse events; if they are, that sounds
>> like a bug.
>>
>> That said, in the Jazz-based JavaFX interpreter, there was a separate
>> flag (Node.selectable, mapped to ZNode.pickable) for controlling
>> whether a node received mouse events, and that was independent of
>> visibility. When I was working on the port from Jazz to Scenario, I
>> punted on this (there's still a TODO in the definition of
>> Node.selectable reflecting that fact).
>>
>> Someone (probably Hans, since he's been responsible for input stuff)
>> will need to decide what to do about all this. One option would be to
>> drop the Node.selectable property altogether. If we do still want to
>> maintain Node.selectable and keep it independent from Node.visible,
>> then we'll probably need to add a selectable property to SGNode. In
>> that case, the remaining question would be: do we only look at the
>> selectable property, or should invisible (but selectable) nodes still
>> receive input events?
>>
>> Thanks,
>> Chris
>>
>>
>> Jim Clarke wrote:
>>> Is there an easy want to enable / disable mouse events for an SGNode
>>> or SGGroup of nodes,
>>> besides removing/adding the mouse listener?
>>> Similar to java.awt.Component.enableEvents/disableEvents(long).
>>>
>>> I have a situation where a node is invisible until another button is
>>> pushed.
>>> However, the node still receives mouse events while invisible. I want
>>> to disable
>>> mouse events while it is invisible, then enable them when it becomes
>>> visible.
>>>
>>> Or is there a different way to accomplish this?
>>>
>>> jim
>
> --
> * Jim Clarke *
> OEM Software Sales - Principal Engineer
>
> *Sun Microsystems, Inc.*
> Phone x51695/+1 877 300 6162
> Mobile 407.620.9065
> Fax 407.380.1143
> Email Jim.Clarke@Sun.COM
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
For additional commands, e-mail: dev-help@scenegraph.dev.java.net

Baechul at Sun

I was just curious how flash does in this case.
I don't mean the right thing but just FYI...

http://longpier.sfbay.sun.com:8080/javafx/fade.swf

img1_mc.onEnterFrame=function() {
img1_mc._alpha -= 1;
myTxt.text="Alpha value: "+img1_mc._alpha;
if(img1_mc._alpha <= 0) {
img1_mc._visible = false;
myTxt.text="Now the visible was set to false. Click the where
the duke was.";
delete img1_mc.onEnterFrame;
}
};

img1_mc.onMouseDown=function() {
myTxt.text = "Mouse pressed "+(num++)+" times.";
}

-Baechul

Chet Haase wrote:
>
> The decision to have a separate visibility property (which
> controls the "active" state of a node, such as whether it
> receives events) in addition to the opacity property
> came from discussions we had around overloading the
> opacity property too much.
>
> There's probably more that I'm not remembering, but two
> points come to mind:
> - Setting a node to be transparent (opacity==0) to control
> whether it's an active node in the scene felt like a hack.
> Opacity is usually about how something is rendered, not
> whether it is receiving events/etc.
> - There may be cases when a node is transparent (opacity==0)
> when you still want it to be active. For example, imagine
> a node that is pulsating between opaque and transparent - if
> we overload opacity==0 to mean that it can't receive events,
> then this otherwise active node will pass through inactive
> states in the process of performing this animation. So if
> someone happens to click it at the wrong time, that
> click won't be received.
>
> I agree that setting visibility to true *and* fading a node
> in seems like overkill (I've had to do the same in my demos), but
> it feels less hacky than previous cases where I'd have to
> set opacity==0 to mean "this node isn't active"
>
> We can talk about changing this API as appropriate, but it
> seemed worth mentioning the logic behind the current API.
>
> Chet.
>
>
> Jim Clarke wrote:
>> The particular demo I was porting actually had the nodes visible, but
>> had some that had opaque set to zero.
>> So I guess that is why they still got mouse events. I worked around
>> the issue using the visible
>> attribute, (when the old nodes started fading out, I turned on
>> visible for the new nodes that where to fade in).
>>
>> I am not sure that this is the best approach for this
>> fade-out/fade-in pattern.
>>
>> jim
>>
>>
>> Chris Campbell wrote:
>>> Hi Jim,
>>>
>>> I'm pretty sure that invisible SGNodes (i.e. isVisible() returns
>>> false) should not be receiving mouse events; if they are, that
>>> sounds like a bug.
>>>
>>> That said, in the Jazz-based JavaFX interpreter, there was a
>>> separate flag (Node.selectable, mapped to ZNode.pickable) for
>>> controlling whether a node received mouse events, and that was
>>> independent of visibility. When I was working on the port from Jazz
>>> to Scenario, I punted on this (there's still a TODO in the
>>> definition of Node.selectable reflecting that fact).
>>>
>>> Someone (probably Hans, since he's been responsible for input stuff)
>>> will need to decide what to do about all this. One option would be
>>> to drop the Node.selectable property altogether. If we do still
>>> want to maintain Node.selectable and keep it independent from
>>> Node.visible, then we'll probably need to add a selectable property
>>> to SGNode. In that case, the remaining question would be: do we
>>> only look at the selectable property, or should invisible (but
>>> selectable) nodes still receive input events?
>>>
>>> Thanks,
>>> Chris
>>>
>>>
>>> Jim Clarke wrote:
>>>> Is there an easy want to enable / disable mouse events for an
>>>> SGNode or SGGroup of nodes,
>>>> besides removing/adding the mouse listener?
>>>> Similar to java.awt.Component.enableEvents/disableEvents(long).
>>>>
>>>> I have a situation where a node is invisible until another button
>>>> is pushed.
>>>> However, the node still receives mouse events while invisible. I
>>>> want to disable
>>>> mouse events while it is invisible, then enable them when it
>>>> becomes visible.
>>>>
>>>> Or is there a different way to accomplish this?
>>>>
>>>> jim
>>
>> --
>> * Jim Clarke *
>> OEM Software Sales - Principal Engineer
>>
>> *Sun Microsystems, Inc.*
>> Phone x51695/+1 877 300 6162
>> Mobile 407.620.9065
>> Fax 407.380.1143
>> Email Jim.Clarke@Sun.COM
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
For additional commands, e-mail: dev-help@scenegraph.dev.java.net

Tom Ball

My vote is to combine the properties to keep things simple. If someone
needs an invisible node that receives input events, one option is to
make it visible and set its opacity to zero.

Tom

Chris Campbell wrote:
> Hi Jim,
>
> I'm pretty sure that invisible SGNodes (i.e. isVisible() returns false)
> should not be receiving mouse events; if they are, that sounds like a bug.
>
> That said, in the Jazz-based JavaFX interpreter, there was a separate
> flag (Node.selectable, mapped to ZNode.pickable) for controlling whether
> a node received mouse events, and that was independent of visibility.
> When I was working on the port from Jazz to Scenario, I punted on this
> (there's still a TODO in the definition of Node.selectable reflecting
> that fact).
>
> Someone (probably Hans, since he's been responsible for input stuff)
> will need to decide what to do about all this. One option would be to
> drop the Node.selectable property altogether. If we do still want to
> maintain Node.selectable and keep it independent from Node.visible, then
> we'll probably need to add a selectable property to SGNode. In that
> case, the remaining question would be: do we only look at the selectable
> property, or should invisible (but selectable) nodes still receive input
> events?
>
> Thanks,
> Chris
>
>
> Jim Clarke wrote:
>> Is there an easy want to enable / disable mouse events for an SGNode
>> or SGGroup of nodes,
>> besides removing/adding the mouse listener?
>> Similar to java.awt.Component.enableEvents/disableEvents(long).
>>
>> I have a situation where a node is invisible until another button is
>> pushed.
>> However, the node still receives mouse events while invisible. I want
>> to disable
>> mouse events while it is invisible, then enable them when it becomes
>> visible.
>>
>> Or is there a different way to accomplish this?
>>
>> jim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
For additional commands, e-mail: dev-help@scenegraph.dev.java.net

Patrick Forhan

On Jan 2, 2008 10:00 PM, Tom Ball wrote:
> My vote is to combine the properties to keep things simple. If someone
> needs an invisible node that receives input events, one option is to
> make it visible and set its opacity to zero.

Note that, in the jazz JavaFX Interpreter implementation, setting
opacity to 0 causes visible to be set to false and mouse events to be
ignored. There are a couple of posts on the users mailing list to
this effect. The workaround was to use a near-zero opacity... but
that's not obvious...

Pat.

--
Defy mediocrity.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
For additional commands, e-mail: dev-help@scenegraph.dev.java.net

mikaelgrev
Offline
Joined: 2006-09-27

Do not intermix properties and have one property value propagate to another one to be "smart". If there is a need to hinder events from propagate to a node add a property for that. Intermixing properties is an enemy to simplicity. Especially so when things get more complicated and even more so in a retained type of API where "if"s are harder.

Chris Campbell

Hi Jim,

I'm pretty sure that invisible SGNodes (i.e. isVisible() returns false)
should not be receiving mouse events; if they are, that sounds like a bug.

That said, in the Jazz-based JavaFX interpreter, there was a separate
flag (Node.selectable, mapped to ZNode.pickable) for controlling whether
a node received mouse events, and that was independent of visibility.
When I was working on the port from Jazz to Scenario, I punted on this
(there's still a TODO in the definition of Node.selectable reflecting
that fact).

Someone (probably Hans, since he's been responsible for input stuff)
will need to decide what to do about all this. One option would be to
drop the Node.selectable property altogether. If we do still want to
maintain Node.selectable and keep it independent from Node.visible, then
we'll probably need to add a selectable property to SGNode. In that
case, the remaining question would be: do we only look at the selectable
property, or should invisible (but selectable) nodes still receive input
events?

Thanks,
Chris

Jim Clarke wrote:
> Is there an easy want to enable / disable mouse events for an SGNode or
> SGGroup of nodes,
> besides removing/adding the mouse listener?
> Similar to java.awt.Component.enableEvents/disableEvents(long).
>
> I have a situation where a node is invisible until another button is
> pushed.
> However, the node still receives mouse events while invisible. I want to
> disable
> mouse events while it is invisible, then enable them when it becomes
> visible.
>
> Or is there a different way to accomplish this?
>
> jim

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
For additional commands, e-mail: dev-help@scenegraph.dev.java.net

Christopher Oliver

FWIW, in the Jazz version visible overrides selectable. visible ==
false implies you receive no events even if you're selectable.
Selectable is needed for having e.g transparent overlay that doesn't
block mouse events (selectable = false). In addition, the Jazz
version has a property "isSelectionRoot" which blocks mouse events
from propagating behind the current node. This provides a
declarative mechanism for "consuming" the event. Just FYI ...

Chris

On Jan 2, 2008, at 6:35 PM, Chris Campbell wrote:

> Hi Jim,
>
> I'm pretty sure that invisible SGNodes (i.e. isVisible() returns
> false) should not be receiving mouse events; if they are, that
> sounds like a bug.
>
> That said, in the Jazz-based JavaFX interpreter, there was a
> separate flag (Node.selectable, mapped to ZNode.pickable) for
> controlling whether a node received mouse events, and that was
> independent of visibility. When I was working on the port from Jazz
> to Scenario, I punted on this (there's still a TODO in the
> definition of Node.selectable reflecting that fact).
>
> Someone (probably Hans, since he's been responsible for input
> stuff) will need to decide what to do about all this. One option
> would be to drop the Node.selectable property altogether. If we do
> still want to maintain Node.selectable and keep it independent from
> Node.visible, then we'll probably need to add a selectable property
> to SGNode. In that case, the remaining question would be: do we
> only look at the selectable property, or should invisible (but
> selectable) nodes still receive input events?
>
> Thanks,
> Chris
>
>
> Jim Clarke wrote:
>> Is there an easy want to enable / disable mouse events for an
>> SGNode or SGGroup of nodes,
>> besides removing/adding the mouse listener?
>> Similar to java.awt.Component.enableEvents/disableEvents(long).
>> I have a situation where a node is invisible until another button
>> is pushed.
>> However, the node still receives mouse events while invisible. I
>> want to disable
>> mouse events while it is invisible, then enable them when it
>> becomes visible.
>> Or is there a different way to accomplish this?
>> jim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
For additional commands, e-mail: dev-help@scenegraph.dev.java.net