Tooltip for disabled controls

Sven Reimers sven.reimers at
Thu Apr 4 14:08:58 PDT 2013


Well, looking at my favorite IDE (NetBeans Swing) I get tooltips on the
disabled buttons in the toolbar (anybody interested in checking with
Intellij or Eclipse?).

At least it seems as if Swing provides this feature - so is it really that
bad design?

I have to check our own big Swing-based app, but I think I can follow
Scott's idea - sometimes it is easy to guide the user by displaying info on
hovering with the mouse (maybe this behavior gets deprecated with touch?)

So I am still in for a disucssion if this is technically feasible.


P.S. I can see people coming from Swing saying - "JavaFX? No Tooltips on
disabled controls? Even Swing did this by default" ;-)

On Thu, Apr 4, 2013 at 8:08 PM, Scott Palmer <swpalmer at> wrote:

> I find it bizarre that this is being considered as "bad design".  It
> depends on how it is used.  Users find the feedback helpful. I use the
> pattern extensively with positive results. It avoids confusion for the
> users (always a good thing).
> When I have a complex form, where some choices invalidate others, Tooltips
> are great to explain why certain choices can't be made. You don't want to
> hide the disabled controls because it is very useful information for the
> user to see that the options can be available in some cases.  The form can
> already be complex, so trying to fit these messages into the normal layout
> just makes it awkward.
> I also have cases where some options are simply read-only depending on the
> situation.  For consistency I still show the same control as when they
> aren't read-only.  The tooltip explains why the value can't be changed.
>  For TextField I can actually set it to non-editable. But for checkbox
> there is no such option.
> I think the concept of "disabled" on a Node is not the same concept as
> disabled on a Control. For the Node case I agree with it not getting
> events.  For the Control case I just don't want the control to be active.
> I do have ways to workaround this for some controls. As mentioned, a
> TextField can be made non-editable instead.  But with a button it's more of
> a hack.
> Of course *the framework shouldn't be dictating design* anyway.
> That said, I expect the combination of me being out numbered and more
> importantly the difficulty of the fix, means that I'm going to lose this
> one.
> Scott
> On 2013-04-04, at 11:38 AM, "Will Hoover" <java.whoover at> wrote:
> > -1
> > I don't think supporting the use of tooltips on disabled controls is a
> good design pattern to follow (not to mention the overhead of typically
> unnecessary event propagation). If the behavior is really desired they can
> use option #3 or a similar solution using an icon/image with tooltip
> adjacent to the control.
> >
> > -----Original Message-----
> > From: openjfx-dev-bounces at [mailto:
> openjfx-dev-bounces at] On Behalf Of Pavel Safrata
> > Sent: Thursday, April 04, 2013 9:34 AM
> > To: openjfx-dev at
> > Subject: Tooltip for disabled controls
> >
> > Hello,
> > we've got a request to support tooltips for disabled controls. Tooltip
> can be used to explain why the control is disabled which sounds reasonable.
> Jira:
> >
> > We have the disableProperty on Node. When a node is disabled, it is not
> picked, so no mouse events are delivered to it, so tooltip can't be shown
> as it is based on mouse events.
> >
> > Perhaps not delivering events to a disabled node was a bad decision.
> > First, there are use-cases where disabled node wants them (showing
> tooltip). Second, for ignoring node during picking we have the
> mouseTransparent flag and it would be nicer if these two flags were
> orthogonal (the reason they're not is probably that mouseTransparent is
> much younger). But the behavior can't be easily changed - controls, and
> possibly other nodes in user apps, rely on the existing behavior.
> >
> > There are three basic approaches.
> >
> > 1. Make the events delivered to the disabled nodes. We would either
> break backward compatibility (and fix controls), or introduce yet another
> flag, something like pickIfDisabled. Then we would enable picking for the
> disabled control which would make the tooltip work. But it would make the
> entire control work, so we would somehow have to disable other event
> handling for such controls.
> >
> > 2. Don't change event delivery and rather introduce some control-layer
> solution specific to tooltips. Maybe the disabled control registering a
> special tooltip area on its parent or something like that.
> >
> > 3. Do nothing and force users to workarounds like put the disabled
> control into an enabled Pane and set the tooltip on the Pane. Sounds
> horrible, especially for complex applications.
> >
> > Thoughts? Ideas?
> >
> > Thanks,
> > Pavel
> >

Sven Reimers

* Senior Expert Software Architect
* NetBeans Dream Team Member:
* Community Leader  NetBeans:
                              Desktop Java:
* Duke's Choice Award Winner 2009
* Blog:

* LinkedIn:

Join the NetBeans Groups:
* LinkedIn:
* Oracle:

More information about the openjfx-dev mailing list