Summary: | [DND] Tree is scrolling very slow when dragging an Item to the Bottom | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Benjamin Pasero <bpasero> |
Component: | SWT | Assignee: | Veronika Irvine <veronika_irvine> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | Keywords: | usability |
Version: | 3.1 | ||
Target Milestone: | 3.1 M7 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Benjamin Pasero
2005-03-22 04:34:07 EST
Just noticed that the Tree is scrolling, but not with a reasonable speed. In Firefox the Tree scrolls as if the Scrollbars where used. In SWT only the next Item is selected and brought into View. Ben Try dragging a folder in the Windows File Explorer. I think it behaves in the same way that SWT behaves. The next item is scrolled into view - it is not the same as using the scrollbars. What I can do is decrease the amount of time we wait before scrolling. Ideally, I would like to get this value from the operating system because some users do not want their system to react too fast. Right now it is hardcoded at 500 ms between items. See TreeDragUnderEffect. I compared Eclipse with Windows Explorer. Eclipse: I am dragging a class from one package to another one that is not visible. When dragging to the end of the Tree, 50% of the next TreeItem becomes selected and then after a short amount of time, the selection moves forward, thereby scrolling the Tree. I think the "short amount of time" is too long, if possible maybe reduce that value (if that is those 500ms?). Windows: I am dragging a folder from one to another one, not visible. First difference is that Windows is not selecting the next Folder on bottom, it just scrolls with a greater speed than Eclipse. Maybe this difference is just because of the "slow" 500ms and the selection that occurs in SWT, but not in Windows. Basically the selection is not that bad, but the scrolling speed is kind of slow. Ben Another thought: Maybe leave the initial delay hardcoded to 500ms, but as soon as the scrolling has began, decrease the delay, since it is now obvious that the user wants to scroll. Ben I have changed the delay between scrolls to 150 milliseconds. I will continue to investigate getting the delay time from the OS and/or using an accelerated scroll time only after scrolling has started. However, closing this bug for now. Please reopen if 150 ms is still too slow. Looks pretty good now, thanks! Ben |