Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 512715

Summary:	Differentiate "transient" hover from "intended" hover
Product:	[Tools] GEF	Reporter:	Matthias Wienand <matthias.wienand>
Component:	GEF MVC	Assignee:	gef-inbox <gef-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	victor.johnsson
Version:	1.1.0
Target Milestone:	5.0.0 (Oxygen) M6
Hardware:	All
OS:	All
Whiteboard:

Description Matthias Wienand

2017-02-24 13:02:34 EST

Currently, GEF provides a HoverModel and a corresponding HoverBehavior for generating hover feedback and hover handles. However, the hover handles are not immediately generated, but only when the hovered part does not change for some amount of time. The same applies for hover handle removal, i.e. the handles are only removed when the corresponding part is not hovered for some amount of time.

Therefore, when the HoverModel is altered, e.g. the hovered part is set to null, existing hover handles are not immediately removed. This leads to errors when a part is removed for which hover handles are present, because the handles could access their host after it was removed.

In order to allow the clean removal of associated feedback and handles, another hover model could be introduced, the IntendedHoverModel. The old HoverModel would still be used to store the currently hovered part. But the corresponding HoverBehavior would not generate/remove handles after a delay. Instead, the hovered part should be transferred to the IntendedHoverModel if it is hovered for some amount of time (and cleared if it is unhovered for some time). And the corresponding IntendedHoverBehavior could immediately generate/remove handles depending on the state of the IntendedHoverModel. This would allow to remove feedback and handles by clearing the models.

Comment 1 Matthias Wienand

2017-02-27 05:46:00 EST

I think it is sufficient to provide another property within the exisiting HoverModel. Consequently, I added an "intentionalHoverProperty". However, I am unsatisfied with the name. Other names that I thought of: deliberate, intended, wanted, desired. I am open for suggestions and opinions.

Comment 2 Matthias Wienand

2017-03-07 06:39:31 EST

I renamed "intentionalHoverProperty" to "hoverIntentProperty", because "hoverIntent" is a term used by other GUI libraries already for the same functionality. Correspondingly, I implemented a separate HoverIntentBehavior that complements HoverBehavior for the generation of feedback and handles for hover intent. I adapted the examples so that the previous hover handles are now hover intent handles.

The hover intent functionality is split among several parts: HoverTool notifies about hover intent "events", i.e. it manages a PauseTransition that runs when the mouse is stationary; HoverOnHoverPolicy manipulates the HoverModel in response to "hover" and "hoverIntent" events; and the HoverBehavior and HoverIntentBehavior are responsible for feedback and handle generation.

The code is published on the master branch, therefore, I resolve this ticket as fixed for 5.0.0 M6.