Community
Participate
Working Groups
I had a request to implement auto-scrolling support when resizing shapes in GMF. In doing this, I realized that GEF's auto-scrolling support is limited to TargetingTools and I don't think it needs to be. I suggest we support auto-scrolling in GEF when: - Resizing a shape with the resize handles. This has been specifically requested by multiple clients of GMF (see GMF Bug 111899). - Selecting multiple shapes with the marquee selection tool. A GEF request already exists for this: Bug 25314. GMF has handled this in its own code already. - Creating a shape of variable size (i.e. sizing it to extend beyond the viewport). This has been requested in GMF Bug 167243. I have an implementation to support the resizing shape scenario (patch to be attached), but it requires copying code from TargetingTool to the ResizeTracker as the ResizeTracker does not extend TargetingTool and this is where the auto-scroll behavior is added. Instead, I suggest we move the auto-scroll behavior from TargetingTool to AbstractTool so that other tools (like those mentioned above) could also make use of the auto-scroll behavior. Another complaint we have had in GMF and I see a similar complaint exists in GEF (see Bug 207053) is that users don't actually know that auto-scrolling is possible because it requires waiting the hover time near the edge of the diagram and there is no feedback to indicate this is what is required. We have fixed this in GMF when moving shapes and creating connections by auto-scrolling sooner and changing the cursor to provide a visual cue that something can happen near the edge of the diagram. I suggest we move this fix into GEF in all the tools that support auto-scrolling. I will attach a patch to illustrate the change required to the DragEditPartsTracker as an example.
Created attachment 98271 [details] Support auto-scrolling in the ResizeTracker I am attaching my patch to support auto-scrolling in the ResizeTracker but since there is lots of copied code from TargetingTool, I think we should refactor this so that the autoexpose code from TargetingTool is pulled up into AbstractTool.
Created attachment 98272 [details] Add feedback to auto-scrolling in DragEditPartsTracker. This patch adds feedback to indicate auto-scrolling is possible to the DragEditPartsTracker. I think we should do something like this whenever auto-scrolling occurs in GEF.
One more note... My fix to the ResizeTracker is blocked by Bug 168866. There is a patch in this bug that is required to get this to work.
(In reply to comment #2) > Created an attachment (id=98272) [details] > Add feedback to auto-scrolling in DragEditPartsTracker. Auto-scrolling is just one type of auto-expose. Auto-expose is also used when you have something that resembles a tabfolder, where hovering over the tab causes the top-most tab to change. Or for something like a tree, where hovering causes expansion. For those cases, I'm not sure a Hand cursor (I assume the one used by the Panning tool) makes a lot of sense. Also, auto-expose is invoked during native drag-and-drop. We have no control over which mouse cursor is displayed then. Another approach might be some new editpolicy that shows target feedback indicating scrolling can be performed near the edges of the currently targeted container (in this case, the primary layer?). Maybe some google-map-like arrow "buttons" or something. The target editpart could even implement a smarter solution to bug 168866. For example, if the request is a Resize SOUTH, only add insets to the bottom of the feedback layer. Clients may already be doing one or both of the above in their existing code, so if anything new is introduced, it should be optional rather than enabled by default. BTW, I just checked and even the latest version of Office PowerPoint only has limited auto-scroll function, and there's no feedback anywhere indicating that it exists. It would be nice to get auto-scroll working for resize, marquee, connection creation, bendpoints, etc., but visually communicating that it's available doesn't seem as critical nor is there an obvious, simple solution.
