Tooltip for disabled controls

Thu Apr 4 14:34:42 PDT 2013

Eclipse shows tooltips for disabled buttons, too.

~ philipp

Am 04.04.2013 um 23:08 schrieb Sven Reimers <sven.reimers at gmail.com>:

> Hi,
> 
> 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.
> 
> -Sven
> 
> 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
>> one.
>> 
>> Scott
>> 
>> 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
>>> 
>> 
> 
> 
> 
> -- 
> Sven Reimers
> 
> * Senior Expert Software Architect
> * NetBeans Dream Team Member: http://dreamteam.netbeans.org
> * Community Leader  NetBeans: http://community.java.net/netbeans
>                              Desktop Java:
> http://community.java.net/javadesktop
> * 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
>                   http://www.linkedin.com/groups?gid=107402
>                   http://www.linkedin.com/groups?gid=1684717
> * Oracle: https://mix.oracle.com/groups/18497