Tooltip for disabled controls
phdoerfler at gmail.com
Thu Apr 4 13:18:05 PDT 2013
I do support the idea of events for disabled controls. There are other use cases besides tool tips (which seems to be a valid use case to me). Things like re-enabling based on certain events. Or using mouse coordinates for other purposes and the information of which mouse buttons are currently pressed on a disabled control. Let's get creative! Don't constrain the use of events more than necessary.
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.
The Pane-workaround suffers from the pane's bounding rect being different than the control's bounding. This does not matter that much for rectangular, non rotated controls - but circular controls or otherwise irregularly shaped controls might suffer from this. And in any case: That's not that intuitive. Sounds horrible for any application, not just for larger ones.
I don't think there is much overhead of unnecessary event propagation except for applications with really lots of disabled nodes.
just my 42 cent
Am 04.04.2013 um 20:08 schrieb Scott Palmer <swpalmer at gmail.com>:
> 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.
> 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?
More information about the openjfx-dev