Community
Participate
Working Groups
I would like to be able to drag/drop a method in Outline (Hierarch, Package Exploerer, etc...) and have the corresponding code moved in the file. For example, I would like to be able to drag/drop and group all my public methods together. It wouldn't have to be limited to only methods; inner classes, fields, etc... would also be useful.
This is on our feature list as well ;-)).
Moving back to inbox.
Is this going to be addressed in 3.3?
DND to rearange files is already there, but it doesn't use good visual feedback (it doesn't use the horizontal line). It also asks to save the file. Will look at in 3.4
*** Bug 34071 has been marked as a duplicate of this bug. ***
*** Bug 72807 has been marked as a duplicate of this bug. ***
*** Bug 128782 has been marked as a duplicate of this bug. ***
Following must be done: 1. Enable the line feedback (very easy) 2. Do not ask to save the file, all refactorings should work with dirty editors, it does not because of MoveResourceChange and CopyResourceChange 3. The reorg refactoring must know where to add the code, above or below the target. 4. The reorg refactoring must insert the code above and below the target once it knows that, which is the part which requires the most work to be done.
But, there is one big issue with this, the user has no clue what happens when the view is sorted i.e. where will it be inserted? There are two options then: a) insert the member above/below the target b) insert the member such that it appears above/below the target in the sorted view a) has the problem, that when the member is dropped it will not appear where it was dropped b) is difficult to implement, I must somehow find out where to insert the member, I guess this requires to know the view and its sorter. I think from a user point of view b) would be the right thing to do, what you think?
> b) insert the member such that it appears above/below the target in the sorted > view This could only be achieved by renaming an item, which is certainly not an option. When a view is sorted, we should not offer any position-related drop positions. They make little sense, and the user should not be lead into believing that he really can rearrange items in sorted views. Dropping onto an item should still insert the item at the default position inside the drop target (like in the unsorted case). An alternative could be to allow position-based dropping and to show a dialog in this case, which asks whether sorting should be turned off. But I think disabling the functionality upfront is the better approach.
Yes, stupid me, we have to go with a) of course. The user can rearrange the code even if the view is sorted, it makes sens to be able to select if a member is inserted before or after the drop target. Only the feedback would be a bit confusing. I think disabling would lead to bug reports like 'I can't DnD no more in the outline view' also the PE is always sorted.
Yes, you're right Markus, for the user a drop target between two items can be considered either below the top item or above the bottom item. The UI does not give the required feedback. I think best thing to do is: - Sorted view Do not show above/below feedback, only allow to drop onto if this results in a copy/move into (i.e. drop field on type ok, but not drop field on field) - Unsorted view (Outline and Members view if not sorted) Do as requested in this bug, that is, show above/below feedback and add code above/below, only allow to drop onto if this result in a copy/move into We tried in firefoxs bookmark view, and it is very confusing if you can change the order of items of a model in a sorted view.
*** Bug 17296 has been marked as a duplicate of this bug. ***
Created attachment 74952 [details] fix
Created attachment 74953 [details] fix
Created attachment 75004 [details] fix Released for todays I-Build. Enabled it only for the Outline view. Give it a try...
Works quite good. Having selection feedback when dropping isn't possible is a bit confusing. Filed bug 198408 to track this.
Created attachment 75214 [details] enable for members view
fixed > I20070731-0800
Verified in I20070807-0010.
