Community
Participate
Working Groups
R2.1 Bug 37463 describes a scenario where editor linking gets in the way of dragging a file from the Navigator into the contents of the editor for a different file. While this will be fixed in the Navigator, we should also allow an editor to be activated during a drag. Hovering over an editor tab during a drag should activate the editor.
Reassigning to Nick since he is taking ownership of DND.
*** Bug 54236 has been marked as a duplicate of this bug. ***
I'd like to add my vote to see this happen -- 1) because our RCP app also suffers from the link-view-with-editor feature interfering at times, and 2) because I feel I'm very used to doing this in DND with windows.
Eddie: note that you can actually votes for bugs. See the "Vote for this bug" link above. Should also do this for fast views and perspective buttons/chevron.
I didn't think you guys were using the vote feature in bugzilla :-)
We do actually use and look at the votes. Bugs with more votes do get more attention, it just sometimes takes a while, and the attention given may not always be the attention wanted.
Reassigning bugs in component areas that are changing ownership.
Bug #124363 is another reason why this feature would be useful. The basic desire is to drag an item from one editor to another. This functionality may be important to apply to CTabFolder in general. If the editor in question is a multi-page editor, simpling making the editor active may not be enough. The user may need to hover over one of the pages in the active editor.
Yes, I had a case just yesterday where I wanted to drag something from one view to another, but could not because they were in the same folder. Should also be able to switch perspectives by hovering over a perspective button. The drop-down chervrons for the editor list and view folders should also be sensitive. Having general support for this in CTabFolder may be helpful.
If we do this it has to be part of a larger 'context oriented actviation on hover' (i.e. switch perspectives?, activate different tabs on multi-page editors...).
Hello, There's also the need, in my company to be able to activate the editor when dragging over its tab. The need to have the more general solution (for views, perspectives, ...) is not ours currently. But I certainly understand that a general solution would be more attractive, in a perfect world. Could you tell me how you intend to deal with this bug ? On eclipse.platform newsgroup I was told I could help by submitting a patch. If I could, I would certainly provide it. Alas, I don't know how to solve the specific case, if not the general one. Maybe, if you can give some directions, I could investigate further. Sincerely, -- Laurent Petit
The basic issue is that we use the native platform's DnD mechanisms and most of them 'insulate' the environment from the various events (i.e. the DragSource and DropTarget are the -only- receivers of events on at least some platforms (i.e. the 'normal' MouseMove...events are eaten by the DnD subsystem). Note that the auto-expand and scroll are available because the platform has implemented the behavior specifically for DnD. This makes it difficult to implement. We might possibly be able to install a mouse 'hook' (i.e. a listener on the Display itself) on a DragStart to manage this but I haven't investigated this deep enough to actually know if that'll do the trick. We'd then use this mechanism to send specialized events to the Workbench so that it could work its magic (switching tabs...). I've been looking at WoW's DnD and I actually like its way of doing this, the gesture is not Down->Drag->Release to drop...when a drag 'starts' the elements are attached onto the cursor 'permanently'; you can then just use the mouse normally to navigate clicking/dragging scrollbars, tab items...the drop only happens on a mouse up in the valid drop location (or ESC). Unfortunately I don't think we can do this using the platform mechanisms...but I'm considering it for e4's View/Editor DnD (which doesn't use the platform's code because things like the CTabFolder don't implement DragStart...
Remy is now responsible for watching the [ViewMgmt] category.
*** Bug 162765 has been marked as a duplicate of this bug. ***
*** Bug 90807 has been marked as a duplicate of this bug. ***
