Tooltip for disabled controls

[Will Hoover]

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