Tooltip for disabled controls
sven.reimers at gmail.com
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
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 gmail.com> 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
> On 2013-04-04, at 11:38 AM, "Will Hoover" <java.whoover at gmail.com> 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 openjdk.java.net [mailto:
> openjfx-dev-bounces at openjdk.java.net] On Behalf Of Pavel Safrata
> > Sent: Thursday, April 04, 2013 9:34 AM
> > To: openjfx-dev at openjdk.java.net
> > 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: https://javafx-jira.kenai.com/browse/RT-28850
> > 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
* Senior Expert Software Architect
* NetBeans Dream Team Member: http://dreamteam.netbeans.org
* Community Leader NetBeans: http://community.java.net/netbeans
* Duke's Choice Award Winner 2009
* Blog: http://nbguru.blogspot.com
* XING: https://www.xing.com/profile/Sven_Reimers8
* LinkedIn: http://www.linkedin.com/in/svenreimers
Join the NetBeans Groups:
* XING: http://www.xing.com/group-20148.82db20
* NUGM: http://haug-server.dyndns.org/display/NUGM/Home
* LinkedIn: http://www.linkedin.com/groups?gid=1860468
* Oracle: https://mix.oracle.com/groups/18497
More information about the openjfx-dev