Tooltip for disabled controls

steve.x.northover at oracle.com steve.x.northover at oracle.com
Fri Apr 5 13:56:36 PDT 2013


On 05/04/2013 4:48 PM, Pavel Safrata wrote:
> Hi Steve,
>
> On 5.4.2013 22:09, steve.x.northover at oracle.com wrote:
>> We can't start delivering events to disabled controls or we will 
>> break the universe (even for event filters).  Am I missing 
>> something?  There is potential for application code to start running 
>> that did not run in the past. Suddenly, disabled controls in some 
>> applications that add filters to standard controls might start to do 
>> something when they did not in the past.
>
> I have mentioned that explicitly. I said it is backward incompatible. 
> I said existing filters will start running and will need to be checked.
>
> I also said there is not many of them. I just grepped our controls and 
> there is about 15 event filters that would need to be looked at, 8 of 
> them copy-paste.
>

Agree.  I was mainly talking to Richard who thought this was worth 
investigating.  I think we can't make this sort of change at this time.

>>
>> The reason that disabled tool items on native platforms have hover 
>> help is that they are lightweight (ie. on Windows, no HWND). There is 
>> a separate API to disable them versus the API that disables a 
>> heavyweight.  So native platforms are relying on the implementation.  
>> You will notice that hover help dies not come for push buttons for 
>> example on Windows.
>>
>> Whether hover help should be displayed or not is specific to the 
>> control.  For example, in tool bars, we want the hover help. However, 
>> when a tree is disabled, we don't expect hover help for the tree item.
>>
>> The safest way to do this is to add new versions of the events that 
>> get delivered when the control is disabled.  Tool items can be 
>> changed to use the new events.  Tree items can be left alone.
>
> I think that new events would be too expensive. Apart from adding the 
> events, we would need separate picking (means 100% picking slowdown), 
> duplicating all the logic for entered/exited generating, etc. And 
> there might be design issues, from naming (MouseEventForDisabledNode?) 
> to defining what events to duplicate or how to handle DnD etc.
>

I wasn't necessarily going to duplicate every single event.  It might be 
that there are places in the code where we send the event and we could 
just send another one on the next line.  I'm not happy with duplicating 
events either.

What events are need by the toolkit to implement tool tips?
Which controls implement tool tips?

> Thanks,
> Pavel
>
>>
>> Thoughts?
>>
>> Steve
>>
>> On 05/04/2013 3:01 PM, Richard Bair wrote:
>>>>> So are the CSS rules designed such that disable will still be 
>>>>> applied, or will the hover rules take precedence? We'd have to try 
>>>>> it out.
>>>> I've tried. As I expected, controls fully rely on the events not 
>>>> being delivered. When I deliver events to a disabled button, the 
>>>> button stays grayed, but works normally - gets highlighted on 
>>>> hover/armed, gets pressed etc.
>>>>
>>>> When I deliver the events to filters but not to handlers, 
>>>> everything looks fine on the first sight.
>>> I like this idea, lets continue pursuing it and see if it works out.
>>>
>>> Richard
>>
>



More information about the openjfx-dev mailing list