Summary: | Improvements to auto-scrolling behavior in GEF | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Tools] GEF | Reporter: | Cherie Revells <crevells> | ||||||
Component: | GEF-Legacy GEF (MVC) | Assignee: | gef-inbox <gef-inbox> | ||||||
Status: | NEW --- | QA Contact: | |||||||
Severity: | enhancement | ||||||||
Priority: | P3 | CC: | crevells, hudsonr, peter | ||||||
Version: | 3.4 | ||||||||
Target Milestone: | --- | ||||||||
Hardware: | PC | ||||||||
OS: | Windows XP | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Cherie Revells
2008-04-30 17:19:28 EDT
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. |