Tooltip for disabled controls

[Scott Palmer]

Yes.. for controls with state like 'selected' a read-only property might
make sense.  For other non-toggle buttons perhaps an "active" or "inactive"
property?  But I think that starts to change a lot of APIs, which is why I
was trying to factor out the problem: what nodes *would* be involved if
they weren't disabled?  Letting the Scene know that information while not
delivering the event any differently would allow for hooking in a Tooltip
manager of some sort at the Scene level.

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