Tooltip for disabled controls
tom.schindl at bestsolution.at
Thu Apr 4 14:40:30 PDT 2013
I think we start to mix different things. Disabled control should NOT
receive events but they should show tooltips. Disabled controls in SWT
does not receive any events!
On 04.04.13 23:34, Philipp Dörfler wrote:
> Eclipse shows tooltips for disabled buttons, too.
> ~ philipp
> Am 04.04.2013 um 23:08 schrieb Sven Reimers <sven.reimers at gmail.com>:
>> 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 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:
>>>> 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
>>>> 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?
>> Sven Reimers
>> * Senior Expert Software Architect
>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org
>> * Community Leader NetBeans: http://community.java.net/netbeans
>> Desktop Java:
>> * 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