Summary: | Too easy to create duplicate methods | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Nick Edgar <n.a.edgar> |
Component: | UI | Assignee: | Adam Kiezun <akiezun> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P1 | CC: | dj.houghton, erich_gamma |
Version: | 2.0 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Nick Edgar
2002-04-19 11:05:59 EDT
*** Bug 14256 has been marked as a duplicate of this bug. *** The problem is that you can also drop methods on other methods and we try to be smart to infer the containter. We should not try to be that smart, a drop of a Method (element) should only occur when the user drags over an IType (a legal parent). i disagree. you might want to rearrange your methods by dnd. then you want to paste a method over a method. otherwise - the rearrangement feature is gone. and ctrl+c, ctrl+v creates duplictes nicely., would be not good to lose this function. i think a good solution would be if the platform provided support for saying: 'ignore drop attempts if they happen withing less than x milliseconds from drag start'. this would eliminate the problem without losing any function. I agree that reordering via drag&drop would be desirable. However, there are
several issues:
- reordering methods only makes sense when the view is not sorted (most users
have the sorting turned on)
- when reordering methods what does drop onto an element mean, drop before or
after?
- when reordering methods then we should only do so when the method is dropped
in between methods and in addition we have to show a corresponding drop
acceptance feedback (a line in between two items). Making the drop timer based
does not solve this problem.
Given these issues we should remove the smartness for now.
>ctrl+c, ctrl+v creates duplictes nicely
this is an argument for reviving the duplicate action.
the time based solution seems to work - i do not get any accidental copying now. i think, if copying is indeed your intention, than you usually do it slower a bit (i set the treshold to 150ms) - so this approach should be good. closing - please reopen if it happens again. fixed for 20020423 I concur with all of Erich's issues. Have these been addressed? Time based solutions are risky from an accessibility point of view as well. E.g. if I have motor difficulties, your time limit may be too short for me. the time limit works the other way roung - dnd does _not_ happen if you move too quickly - so i see no accessibility problem here. reordering by dnd will probably not be supported for 2.0 No, it's still a problem. If I have motor difficulties, then I can operate a mouse but the movement may be slow and jiggly. So what I intended as a simple selection could easily cause an unwanted drag. a possible solution i see is to open a dialog. but that'd get on everybody's nerves very soon. suggestions? I agree a dialog would be too much of an interruption. Note that I don't think the feature is a bad idea. I've often wanted to do D&D rearrangement of source (with an outline, not in the text editor). I think as long as the feedback is appropriate, as Erich suggests, then D&D can be made to work. It's just surprising for it to have an effect if there's no feedback. And there's also the issue of what to do if the outline is sorted. Another related feature would be to just sort the methods alphabetically (in the source, not just the presentation in the outline). |