Tooltip for disabled controls

[Pavel Safrata]

Let me first explain the current behavior. The disabled nodes are 
ignored during picking (just as mouseTransparent nodes). So the top-most 
node under the disabled node is picked. For controls it is usually the 
parent pane, but generally it can be any node from the other end of the 
scenegraph tree.

In my opinion this is a bug. The control is disabled, but it is still 
there on the screen, so why pick something obscured by it. Picking the 
parent node instead would make much more sense, wouldn't it? I think we 
should fix this regardless of the outcome of this discussion. Do you 
agree? It is a backward incompatible change but I can't imagine a 
use-case relying on the current behavior.


If we fix the above, we now at least have the events delivered along the 
chain leading to the disabled node, so we can start looking for a way to 
prolong the chain to the disabled node with minimum damage.

It seems to me that creating an alternative event dispatch chain is too 
wild idea. First, we would have to modify picking to return more nodes 
(before 2.0 we reworked the event system not to do that), or do separate 
picking (which would have performance impact). Second, the tooltip needs 
also entered/exited events; generating those events is quite 
complicated, needs to maintain state between the successive events, etc. 
I can't really imagine how we would do all this for alternative event 
dispatch chains, and what would we produce (alternative events?). Also I 
can't really imagine any straightforward way of delivering events via 
alternative chains (without confusing the nodes present on both chains).


Another option, also backward incompatible but should probably break 
only small amount of things, is: pick the disabled nodes normally and 
for disabled nodes deliver the events to event filters only (no 
handlers). The semantics would be quite clear: disabled nodes consume 
the event in the end of capturing phase (before bubbling phase).

Now switch tooltips to use event filters and they start to work. If you 
need anything else to work on disabled node, use event filter. The 
existing handlers are still not called. There are two issues:
1. We (and users) would have to go through existing event filters and 
make sure they don's tart doing something undesirable for disabled 
nodes. If we agree on this backward incompatibility, I think the 
required amount of work is feasible, filters are not used that much.
2. Applications that rely on events delivered to disabled node's parent 
will break. There wouldn't be many of such use-cases out there. The 
least awkward use-case we could make up is an enabled pane with an 
"enable" context menu and some disabled content, the context menu will 
stop working on the content. We can either break the backward 
compatibility there as well (I prefer this option), or deliver the event 
to all filters, then skip handlers of disabled nodes and continue with 
handlers of enabled nodes (would keep backward compatibility but is 
pretty complex and cumbersome).


Two more notes:

The active/inactive/disabled approach may work, but I don't really like 
it. I think the difference between inactive and disabled button would be 
confusing. Especially when the real reason behind it is "one of them 
shows tooltip".

There still is a tooltip-only solution where the enabled parent manages 
specific tooltip areas for its disabled children. This would require to 
add a bit of complex code to controls but it can work automatically and 
without breaking anything. I personally don't really long for this option.

Thanks,
Pavel

On 5.4.2013 15:15, Scott Palmer wrote:
> I'm not suggesting to propagate the events to the Nodes.  The idea is that
> the filter would be added only to the Scene if you wanted to see the event
> chain that includes disabled Nodes.
>
> Scott
>
>
> On Fri, Apr 5, 2013 at 7:55 AM, Will Hoover <java.whoover at gmail.com> wrote:
>
>> I still see any event propagation on disabled controls as an overly
>> zealous feature. I would assume that in most use cases event dispatch would
>> not be desired on a disabled control- and may even cause unintended
>> consequences. Is the overhead really justified for such a minute use case
>> scenario? On the other hand, I believe a request for tooltips on
>> un-editable controls is a very reasonable one (as many people have pointed
>> out pertaining to native behavior). I think you alluded to a possible
>> alternate "editable" property similar to a TextField in a prior post? At
>> least the intent of a disabled control will remain intact while avoiding
>> the overhead. I'm not sure that makes sense for other controls like a
>> button, but something similar may be a better alternative than using
>> disabled?
>>
>> -----Original Message-----
>> From: openjfx-dev-bounces at openjdk.java.net [mailto:
>> openjfx-dev-bounces at openjdk.java.net] On Behalf Of Scott Palmer
>> Sent: Thursday, April 04, 2013 10:19 PM
>> To: Richard Bair
>> Cc: <openjfx-dev at openjdk.java.net>
>> Subject: Re: Tooltip for disabled controls
>>
>> Is there a way to get the Tooltips without the events ever going to the
>> component?
>> Maybe the Tooltip implementation can change instead.  My idea is to create
>> an alternate event dispatch chain that is identical to the existing one
>> except that it ignores the disabled property on the Node.  It could handle
>> reacting to events that *would have* been delivered to Nodes had they not
>> been disabled.  You keep this separate from the existing event dispatch
>> chain so as not to alter any current behaviour, but implement a Tooltip
>> Manager with it. (And potentially other things.)
>>
>> I don't think this would have any significant performance impact since it
>> would normally share the same exact chain as the current event dispatch
>> mechanism.  It just has an extra bit that goes beyond the reach of the
>> regular event dispatch chain in the case where disabled Nodes are
>> encountered. I think it would open up new possibilities.... but perhaps
>> it's a bit to radical at this stage?
>>
>> Scott
>>
>>
>> On Thu, Apr 4, 2013 at 8:04 PM, Richard Bair <richard.bair at oracle.com
>>> wrote:
>>>> I vote for solution 1): Break backwards compatibility. It shouldn't
>>>> hurt
>>> that much, given that disabled controls did not receive events before.
>>> It would be worse if it were the other way around.
>>>
>>> I don't think we can so easily brush off the compatibility concern here.
>>> My guess (and it is just a guess at this point) is that Controls would
>>> have a major amount of work to make sure they're all working correctly
>>> after changing the semantics so that disabled nodes are delivered events.
>>>
>>> I'm also guessing this will result in widespread breakage. Maybe it
>>> will only break each app in 3 places (say), but that's a lot of pain to
>> inflict.
>>> Before going down that route somebody needs to prototype the behavior
>>> change on Node and run Ensemble and other apps and see if there is any
>>> appreciable breakage. I'm guessing it will be rampant. For example,
>>> Node toggles "hover" property based on the mouse enter/exit events.
>>> Now that disabled nodes will get these, they'll be hover:true. Any
>>> listeners on this will obviously be affected, but so will all of the
>>> CSS. So are the CSS rules designed such that disable will still be
>>> applied, or will the hover rules take precedence? We'd have to try it
>>> out. Also will customer applications break in this manner as well?
>>>
>>> Richard
>>