Tooltip for disabled controls
Daniel Zwolenski
zonski at gmail.com
Thu Apr 4 16:21:14 PDT 2013
I vote 'yes' to disabled things getting sent mouse events.
I probably wouldn't use it most of the time but it gives the developer (me)
the choice, which is always better in my opinion. It is only complicated
here because it wasn't done that way in the first place, resulting in the
issue with backwards compatability.
>From the front line, I'd like to just highlight the fact that backwards
compatibility has so far been largely lip service rather than reality. Each
version of JFX requires you to look over your app and see what broke (e.g.
FXML broke a little while back, builders will break soon, various other
issues here and there). I´m not saying to open the floodgates but it is
perhaps worth noting this trend. I'd personally prefer a better platform
over the pretense of unachievable backwards compatibility.
Also worth noting is that cobundled JREs (and eventual app store deploys)
don't suffer from backwards compatability issues since the jre is tied to
the version of the app code. Only web based deploys (applets and jnlp)
suffer here.
I still vote for deprecating these web based deploys so they are locked to
the current version (and only get major security updates). From Java8
onwards no webstart and no applet. I'm sure others will passionately
disagree, but for me this would be cutting the dead weight that's sinking
Java deployment and preventing the newer/better options from blossoming and
getting Java on the forefront of desktop deployment where it belongs.
On Thu, Apr 4, 2013 at 6:11 PM, Scott Palmer <swpalmer at gmail.com> wrote:
> That's another issue (already filed) you can't put a tooltip on a
> MenuItem at all in JavaFX. You can with Swing.
>
> Anyway it seems clear that tooltips on disabled controls is standard
> practice.
>
> Scott
>
> On 2013-04-04, at 6:03 PM, John Smith <John_Smith at symantec.com> wrote:
>
> > Idea shows tooltips for disabled buttons and so does Windows for
> disabled ribbon controls in Paint and Outlook as well as and back/forward
> buttons in IE 9.
> >
> > Idea does have an ability when you mouseover a disabled menu item that
> it shows a description of the disabled menu item in a status bar at the
> bottom of the screen (it's a pretty subtle UI cue and easily missed) - not
> sure if you want to support that kind of functionality.
> >
> > -----Original Message-----
> > From: openjfx-dev-bounces at openjdk.java.net [mailto:
> openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Schindl
> > Sent: Thursday, April 04, 2013 2:40 PM
> > To: openjfx-dev at openjdk.java.net
> > Subject: Re: Tooltip for disabled controls
> >
> > 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!
> >
> > Tom
> >
> > 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>:
> >>
> >>> 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
> >
>
More information about the openjfx-dev
mailing list