Community
Participate
Working Groups
Hello, I would suggest the following feature . It is impossible up to now to select a text in an editor and to change its place without cut and paste it. It could be very useful to have the same behavior than in windows by dragging and dropping it in another place in the same view. Regards Xavier
not for 2.0
Reopening for 2.1 consideration
*** Bug 12835 has been marked as a duplicate of this bug. ***
*** Bug 2945 has been marked as a duplicate of this bug. ***
just put my vote on this this is the most missing feature from the editor component for me. I'm so much used to that from many other editors - windows and linux
*** Bug 32941 has been marked as a duplicate of this bug. ***
*** Bug 38233 has been marked as a duplicate of this bug. ***
*** Bug 34883 has been marked as a duplicate of this bug. ***
*** Bug 33193 has been marked as a duplicate of this bug. ***
*** Bug 28697 has been marked as a duplicate of this bug. ***
*** Bug 19334 has been marked as a duplicate of this bug. ***
This feature is dangerous and should be made optional if at all. If the user does not want to drag text, but instead wants to make a new selection (that happens to start inside an existing text block), then the behavior is astonishing and possibly destructive. IMHO, when a user intends to select, there should be no chance of changing things. And even if you like the drag-text feature, you must admit that there are people who do not, so make it optional.
I don't object to making it optional. However, I do thing that it can be implemented in a non-dangerous way. On Mac OS X, almost any text is draggable. However, the operation is only considered a drag if you click and hold for a very short while before you start moving. So if you click and immediately move the pointer, it is a new selection, even when it is inside the old selection. I estimate the delay to be about 100 to 200 ms. The user-interface feedback is that the mouse pointer is a text pointer when you select; when you click and hold it changes to the normal mouse pointer again after the abovementioned delay has passed. I have to say that I think it works excellently on Mac OS X; I don't see why it couldn't work the same way in Eclipse.
Dragging text has been a standard in editors and IDEs and word processors for many years now. Even the web page into which I am typing this comment allows it. Other than Eclipse, can anyone name a serious IDE that does NOT have it? There is a very good reason for this - dragging text is extremely convenient, and is a huge advance over the tedium of cut-and-paste. The claim that it is dangerous mystifies me. Is it any more dangerous thn allowing the user to delete text, for example? Especially bearing in mind that you can always ~undo~. By all means make it an option, but do it. ASAP please.
*** Bug 32348 has been marked as a duplicate of this bug. ***
*** Bug 40649 has been marked as a duplicate of this bug. ***
My two cents is that this feature is a dangerous feature to have enabled by default. It is very easy to accidentally drag text whilst coding, and in most cases I wish that it /wasn't/ in tools like Word and the like. Granted, there may be some cases when it is desirable, but I feel that in most cases it probably isn't (or that it can't be achieved with cut'n'paste anyway). If this feature is added, please make it disableable, and I strongly suggest that disabling it by default is the right action.
PLEASE, add drag-and-drop to Eclipse! This is not dangerous at all. Nobody ever got hurt by using D&D in Word (there may be other reasons, though ;-) ), Mozilla or any other text editor on any operating system. I do not mind making it optional and even turning it off by default, but DO make it an option. D&D saves so much time while editing, because it does not override the clipboard contents like cut/copy/paste does. Make sure that double-click selection correctly selects words (taking symbols as ".", ",", ")", etc. properly into account). Triple selecting a line would also be a good idea in combination with D&D.
I love eclipse, but this is the only really useful feature I miss, which I can find in pretty much any other IDE.
Drag and drop not only makes sense between editors of all kinds but also views. It would be nice to be able to create code templates by selecting text in the editor and dragging the selection into a template view. I am already working on the template view but without the drag and drop support its missing the point.
*** Bug 49535 has been marked as a duplicate of this bug. ***
*** Bug 49943 has been marked as a duplicate of this bug. ***
*** Bug 51454 has been marked as a duplicate of this bug. ***
Although there's controversy over drag, could we at least implement simple text *drop* behavior for the default text and Java editors?
strongly disagree with coments #12 and #17: Is a knife dangerous and should be prohibited? Depends on how you use it ... Now, D&D is a feature that I'm used to use in nearly any application I'm working with - be it windows apps or gnome/linux apps. Using eclipse for several months now I still try to d&d pieces of code througout the day and painfully realize that this does not work every time :( Make it optional feature if you want but put it in as soon as possible. IMHO, no d&d could realy draw people away from using eclipse.
I really don't buy the argument that it's "dangerous." If you make a mistake and drop something in the wrong place, just hit CTRL+Z for crying out loud. I've used editors with D&D for years (TextPad mainly) and have never had any significant problem with accidentally horking my source with D&D.
re: 'dangerousness' I think that most developers EXPECT drag'n'drop support, so it should be on by default, but that there could be a checkbox to turn it off. I also agree with the idea that to invoke d'n'd you should click-hold for ~150ms otherwise a new selection starts :)
I'd appreciate the feature. I don't need another preference. >>click-hold for ~150ms Something along this line should be enough.
Created attachment 10382 [details] Patches against HEAD to add drop support I'm attaching a set of patches to add support for dropping text into the Text and Java editors. It includes a drop target adapter supporting an extension point that allows contributing Transfer types and drop event handling to editors. It also provides drag over feedback for ITextViewers. The patches add a new interface, ITextDropEditor, and a new public method, getEditorPart, to the AbstractTextEditor class. The new method is required to return the editor's input so that the document provider can be used to access the IDocument for modification. The patches also provide simple implementations for handling TextTransfer and FileTransfer operations and registers both types on the Default Text and Java editors. I'd like this to be considered for inclusion in 3.0.
We will review the patches post 3.0 since today is the transition to fixing and polishing mode.
PLEASE consider doing this for 3.0! This is by far the most missing feature (at least in the JDT editor)!!
No action for 3.0
Is this improvement in the pipeline at all? This is a feature I could really do with.
It's an investigation item on the 3.1 plan.
Surely, people don't need protection against Drag N Drop?!!! As the number of duplicate bugs indicate, this is a much needed enhancement. As has been said before, what other Editor does NOT have it? When I try and "evangelize" others to Eclipse, their biggest reluctance is the lack of Drag and Drop. PLEASE add it!!
I so much miss the drag an drop of text withing a page. Really is so useful when coding and frustrates me when I have to discard clipboard data to copy a small peice of code. It was the first thing that I noticed eclipse was "missing" and still miss it.
Include me in the group that hates text drag and drop. If this feature is included, PLEASE make it an option that can be turned completely off. Text drag and drop is the first thing I turn off in other IDEs and applications.
A requirement for all modern editors. I like the OSX implementation. Go ahead and add option for those afraid of the feature.
(In reply to comment #34) > It's an investigation item on the 3.1 plan. Is it still being considered for 3.1?
Not for 3.1 since 3.1 is already in fix & polish mode.
Please, please, please can this be considered high importance for the next release then?
I'm marking it for 3.2. No promise yet since the 3.2 plan is not here and the themes aren't given yet.
I hate text D&D. Adding this feature will actually *reduce* the usability of Eclipse, for me at least, if it behaves like it does in other apps that implement it -- I never use the feature on purpose, and my motor skills are such that it just randomly moves my text when I don't want it to.
You can make it optional and turn it off by default, but I needed it as I use it all the time. I know accidents happen, but we have undo for that. Cars do not even have "undo", but we use them, right?
> You can make it optional and turn it off by default I'm convinced the correct default would be the same behaviour as other applications, which is to turn it on. I sympathise with those who dislike the functionality, so making it configurable sounds like a good idea. But the default setting should be a consistent one from the average user's point of view.
This is really getting absurd! Even the most simple text editors support drag & drop, why not eclipse? This is not dangerous in any way! I don't mind if you turn it off by default, but please provide the functionality. Working with D&D is so much more productive. Please, let developers using eclipse benefit from this if they want.
*** Bug 50411 has been marked as a duplicate of this bug. ***
#30 from 2004-05-07 04:48 >We will review the patches post 3.0 since today is the transition to fixing and >polishing mode. and, a *year* later: #40 from 2005-05-18 03:36 >Not for 3.1 since 3.1 is already in fix & polish mode. Do you leave fix & polish mode every now and then or how long does it take to include a patch into the release? Sorry but even if you consider this feature a non-priority, you should still listen to the /people/ that use and love Eclipse. I for one use D&D when I need Copy/Cut&Paste but don't want to *overwrite* the clipboard's contents, as Windows *still* has no clipboard-history outside Office, which is embarrassing on its own.
I also really miss text drag & drop in Eclipse, this is a feature any editor has nowadays. Since it seems to take rather long to implement it in Eclipse, does anyone know a plugin which offers this functionality?
*** Bug 105174 has been marked as a duplicate of this bug. ***
*** Bug 106336 has been marked as a duplicate of this bug. ***
The eclipse 3.2 draft plan has been published and I beleive that adding this feature would definately fit well with the themes for the 3.2 release. Text Drag and Drop fits both with making eclipse simple to use and this will help eclipse appeal to a broader community. It is early in the development phase of 3.2 and now is the time to commit to this feature. It has been open for a very long time and given all of the duplicate bugs and the size of the CC list there is obviously community interest in having this feature in eclipse. Please work to get a commitment for this feature in 3.2 and do not over look it for another relase.
Amen! Please get this feature into Eclipse ASAP! It is sorely missed. If it can be configured with a checkbox to turn it on and off, and a field to specify the activation delay, I think it will satisfy everyone who's commented on this bug in the past 3+ years.
OK, 3.2 Milestone 3 has been released, with no mention of drag and drop (that I could find), is there any chance it will make it into the final version of 3.2?
We're still waiting for bug 106372.
I suggest we all go vote for that bug fix then!!
PLEASE, go vote for bug 106372 and get this fixed! The real reason Eclipse doesn't have this feature is that SWT doesn't have it. Get that fixed, and Eclipse will get it, too. Text drag and drop is a direct manipulation paradigm that appeared well over a decade ago and quickly spread to all major word processors. It is now a feature of all major browsers (in their editable text fields) because it is such a common way to edit text. That means hundreds of millions of users (perhaps over a billion now) have been editing text with apps that have this capability for years. Any reasonable estimate of the percentage of users who actually use it leads to a huge number who take it for granted and are annoyed when it doesn't work. Only a tiny fraction of drag and drop users are aware of Eclipse, and only a tiny fraction of those who are will figure out how (and take the steps necessary to) sign up for Eclipse Bugzilla and complain. But they'll be the users of our apps, and the lack of this simple, elegant feature (standard now on all major platforms), will annoy them as much as it annoys us. Those who bother to complain will complain to *US* (developers who use Eclipse/SWT) for *our shortcomings* as app designers. The rest will complain *about* us to other potential customers and have one more reason to consider our competitors. The SWT text widget needs this capability. It should have an on/off parameter and a timer delay (that can be set to zero). Once SWT has it, Eclipse will get it almost automatically and can expose those parameters in the Preferences--and I don't give a hoot what the defaults are. We can then use it ourselves in Eclipse and provide this capability to our own users. It may not happen unless you go vote for bug 106372.
Come on guys, this thing has been requested in multiple bug reports, by huge amounts of people and still nothing?! From 2002?! I mean, you even received a patch for goodness sakes! Why do we even have to beg like this? Is this not software that WE are supporting by using it? Does that mean that our voice means nothing here?
Maybe I should not stick my nose in here, but in my experience that this kind of attitude does not get the bug fixed any sooner... I have no insight in this project, but generally it's all a matter of priorities; more important things get fixed sooner. (In reply to comment #58) > Come on guys, this thing has been requested in multiple bug reports, by huge > amounts of people and still nothing?! From 2002?! > > I mean, you even received a patch for goodness sakes! > > Why do we even have to beg like this? Is this not software that WE are > supporting by using it? Does that mean that our voice means nothing here? >
*** Bug 117777 has been marked as a duplicate of this bug. ***
(In reply to comment #59) Yes, but as I said, the bug has been open since 2002, and people have been begging for a resolution since then. I think this should push the priority a little higher, don't you? Plus the fact that there is a patch included on this bug report..? > Maybe I should not stick my nose in here, but in my experience that this kind > of attitude does not get the bug fixed any sooner... I have no insight in this > project, but generally it's all a matter of priorities; more important things > get fixed sooner.
I also can't help but weigh in. As was mentioned earlier, this bug depends on another bug, bug 106372. That means that this functionality WILL NOT be delivered before the bug on which it depends has been marked as fixed. I haven't gone through the code in the patch, but at first glance it looks as though this bug is in the Text component, and the patches are against the jdt.ui, ui.editors, and ui.workbench.texteditor packages. Bug 106372 is against the SWT Component, which means that drag+drop capability will be added on every operating system, for any plug-in, JDT and otherwise. This to me seems like the better choice, and I don't mind waiting for that. Because this is an open-source project that many developers are heavily invested in (non-monetarily speaking), changes made to public APIs come few and far between and are carefully weighed before made. We've made our opinions clear with our vote- I notice that both you and I have voted for both bugs, and that's the most say that we can have in the code. After that, let's hold off and let the developers do their jobs.
*** Bug 117851 has been marked as a duplicate of this bug. ***
*** Bug 118760 has been marked as a duplicate of this bug. ***
Im new to eclipse and this was something i noticed immedietly was missing and thought i must have missed an option to turn it on somewhere. Please implement this function.
*** Bug 122328 has been marked as a duplicate of this bug. ***
*** Bug 19955 has been marked as a duplicate of this bug. ***
My 2 cents: Drag and drop is of absolutely no use in coding, and I only wish it could be universally disabled in text editors (most usefully in word processors). The number of times I accidentally drag and drop text/objects exceeds intentionally moving things by orders of magnitude. In applications without undo support (Nautilus), the results can be extremely annoying. I can understand why those who use it might miss it, but please do not make draggable text the default behaviour.
Even though I appreciate Todd's (and others') sentiment, I strongly believe being consistent with the rest of the operating system is far more important than any one's personal preferences. Therefore the default should always be as it is in the rest of the system: enabled. Although I think there are already way too many preferences in Eclipse, I wouldn't really mind adding another one for this to make everybody happy. But again: the default must always be consistent with the rest of the system. (In reply to comment #68) > My 2 cents: > > Drag and drop is of absolutely no use in coding, and I only wish it could be > universally disabled in text editors (most usefully in word processors). The > number of times I accidentally drag and drop text/objects exceeds intentionally > moving things by orders of magnitude. In applications without undo support > (Nautilus), the results can be extremely annoying. > > I can understand why those who use it might miss it, but please do not make > draggable text the default behaviour. >
I second that! The default should be as in the rest of the system. And this means that DND should also be available in field of SWT forms (i.e. PDE editor). In addition, a mechanism could be added to identify frequent use of DND and pop-up a "tip" that explains that DND can be disabled.
Re comment#69. Neither Windows nor Linux supports drag'n'drop text editing in "the operating system", to my knowledge.
To be honest, I don't know about Linux. It could potentially depend on the window manager you're using, I don't know about that. I do know, however, that both Windows (XP, checked WordPad and Visual Studio) and Mac OS X support and use text DND. (In reply to comment #71) > Re comment#69. Neither Windows nor Linux supports drag'n'drop text editing in > "the operating system", to my knowledge. >
Wordpad supports it in Win 2000 too
My last comment on this: Visual Studio is not the operating system. Wordpad may, but Notepad doesn't. (Notepad is nothing more than oversized editbox). Any support you see, is NOT the operating system.
It is irrelevant if it is supported on the OS or application level (at least from a user's point of view.) There are applications under Windows, Linux, and OS/X supporting text drag'n'drop. It is a matter of expectations and telling people about the new feature. Most developers I know just use Eclipse to get their coding done and do not read the "What's New Section" or go through the preference dialog to get to know what Eclipse can do for them. They install the new version and are suprised if something works which hasn't worked before or if there's an additional command/option in a known dialog/menu. Text DND is an invisible feature -- there's just a preference somewhere which enables/disables it. So if the default is off chances are high that a lot of people will not use or still complain about Eclipse not having this feature. If the default is on chances are that there are some people who don't like it from other applications or after a few "bad" experiences inside Eclipse like to turn it off. @@@@ I'd vote for default on (Eclipse) and off (RCP and SWT level). I think the "WTF how do I turn this thing off" crowd will be small and would go automatically to the preferences dialog.
I absolutely agree with David. I should be enabled by default.
*** Bug 126302 has been marked as a duplicate of this bug. ***
I also agree that the default should be on. Whether it is "in the operating system" or not, it is the default in many applications and is therefore expected by many to be the default in Eclipse. If you don't like it turn it off - I'm sure it will be an option. However, having said that - I could also care less if it is turned on or off by default, as long as the feature is there and I know it is available it is fine by me. I don't mind the extra 12 microseconds it takes me to turn it on (or off as the case may be). Whatever makes people happy... Personally I *used* to use it all the time in my previous editor and found it *very* useful - especially for things like reordering XML attributes, or words in sentences. But I have also become used to *not* using it in Eclipse because it isn't there. No big deal. Most of our customers have also complained it isn't there, but they are also living without it. No biggie. You get used to it and move on, enjoying the rest of the Eclipse experience. And we have filed an enhancement request in our bug system as well to keep an eye on this issue. The *proper* way to do this is exactly what the Eclipse team is doing - adding it to SWT, not to each text editor separately. I'd love to submit a patch, but I am not a SWT developer so I am content to wait for the proper fix. Oh - BTW. I just noticed the Bugzilla comment box in my Firefox browser supports it... :-p
Before an editor can make itself a drop target (for text or any other type), the UI team needs to resolve the interaction between editor drop transfers and the editor area drop transfers. See Bug 125957.
Veronika, if I parse bug 125957 comment 31 correctly, this means we can't resolve this PR for 3.2, because the suggested 3.2 solution from bug 125957 will prevent drag under feedback from appearing. Is that correct?
In order to resolve this we first need to put the grounds for DnD contributions to editors, otherwise clients contributing some sort of DnD will get broken. This is covered in bug 125957 and won't make it into 3.2. Having said that, I plan to offer a patched TextViewer off the Platform Text component page which will allow to get DnD with all its known limitations, especially disabling all other registered DnD drop targets. Please ping me, if I haven't done this until end of May.
Seriously how much time do you plan on going against the current, based only on the list of answer and duplicates of this bug reported it seems clear that being able to drag & drop text selection is a needed feature, and you event got a patch. I also miss this feature and i finally came here after another failed attempt to drag a text selection in my source code, whether it is enabled by default or not is not problem for me since everytime I start using a new application i go through all the options (at least the major ones) and set them the way I want, I rarely use defaults. I consider that if a developer (aren't we considered to be power users ?) can't even go into the options and set them the way he wants then it should really reconsider the way he calls himself. At worst you will change the option the first unwanted time it happens to you, is it that horrible ? I don't like the default for the code reformater and the fact it is enabled by default but i never whinned about it in a bug report comment and this line is and will be the last time you will hear about it. That said I hope we get dnd text before windows 2510 is out...
(Regarding comment #82) Did you bother to read through the comments in this bug? The developers are not refusing to implement this, they are refusing to implement it in a hacked manner. Most developers will agree that it should be implemented *properly* rather than improperly, and in a non-breaking, backwards-compatible manner. Don't you agree? The way I see it they are just waiting for some final cleanup at the SWT layer and the feature will be introduced. I for one am happy to wait for it to be implemented properly so I can take advantage of it in *my* particular editor, as well as my SWT code - not just in a platform editor.
Yes it may not be obvious while reading my comment but i read all the comments before posting, but the first thing i saw when i start reading was that this feature request was posting in 2002. I have no doubt this is not at the top of the todo list and it may takes time to properly implement it, but 4 years...
OK, I've opened bug 142845 to see if we can at least get started on a proper fix for this... If it can't be done on the SWT side then it becomes more complicated since the platform shouldn't be implementing its own complete Dnd handling.
*** Bug 156529 has been marked as a duplicate of this bug. ***
*** Bug 156484 has been marked as a duplicate of this bug. ***
(In reply to comment #83) > The developers are > not refusing to implement this, they are refusing to implement it in a hacked > manner. [snip] > I for one am happy to > wait for it to be implemented properly so I can take advantage of it in *my* > particular editor, as well as my SWT code - not just in a platform editor. It's admirable that you are speaking only for yourself. I however can not resist the urge to speak on behalf of who I imagine are a large number of Eclipse users who have encountered this embarrasing limitation. We don't care about dragging files into editors or dragging text into file browsers or dragging cartons of 11mm hex bolts into vats of purple meringue. We don't care about dragging $EVERY_POSSIBLE_DATA_TYPE into $EVERY_POSSILBE_VIEWER/EDITOR. We just want the ability to highlight a chunk of text and drag it to another location within the same editor (even just within the same document would be eagerly welcomed). If SWT has been fixed enough to allow this functionality then there is no valid reason to put off implementing it. If the only reason this feature hasn't been added is because a few people are wringing their hands over not yet being able to drag a $FOO into a $BAR then perhaps a shake up is in order at whatever organization is running the show here. With bug 106372 resolved, what are you waiting for? For those of us who ONLY care about moving text around in the same document, is there any patch or plug-in that provides this basic functionality?
I hate to get involved in what amounts to a flame, but as someone who voted for this bug and put myself on the CC list so that I can remain aware of meaningful updates (NOT rants about how this needs to be fixed yesterday), I feel that something needs to be said. You need to realize that (a) this is open-source software, (b) it has a large user base, and (c) it has a large base of people who extend it. They WILL NOT make a temporary fix, no matter how much you complain, because as soon as they do, that public API is set in stone, and they can't go back and make it better, they're stuck with it. The author of comment #83 may speak for himself, but his comments also resonate in the developer community that builds on top of this. I've been developing on top of Eclipse for a few years now, and I can tell you that no matter how much you want it now, how embarrassing you think it might be not to have drag+drop capability, it won't get done until it fits into the design in a uniform manner. Furthermore- drag+drop is eye candy. At best, it improves development flow for a percentage of the user population. Eclipse is finally at the point where these kinds of bugs can be taken seriously (notice it was opened in early 2002). It's close to being done. There's been more recent activity on this bug, it seems, than there was in the years leading up to now. Everybody who's a CC on this bug is so because they want to see it taken care of. Please don't make it any more frustrating for asking for improvements to your user experience, especially when those improvements are made by people for free, and they would be made at the cost of others' experience. I understand if you want to gripe, but the comments for the bug are not the place to do it. I also understand that you might not understand the cost of not waiting to implement this, but trust me, there is one. Public APIs really are a "write once" kind of thing, so the more time developers spend designing/developing and less time reading comments that aren't anything more than complaints, the better.
Thanks Liam, for a description of the underlying issue to this check out bug 142845. Right now if the text editors were to allow dragging text all of the existing editor area drop behaviour (i.e. dropping files/markers) would be busted. I see this as an architectural deficiency in that it is preventing -anybody- (text editor, Form editor, diagram...) from implementing drop behaviour appropriate to their editor; preventing the use of a standard (and powerful) GUI operation. I'll talk to Steve Northover to get his take on what, if anything, SWT can do.
Created attachment 51090 [details] Editor Drop Target API / impl Proposed API and implementation supporting the ability for editors to 'safely' define drop targets onto editor controls (i.e. maintaining the editor area's default behaviour).
Boris, can you look over the proposed API and comment? Thanks.
I added my vote, and would like to point out some additional functionality that is available in the editors I've used. If you hold a modifier key (usually <ctrl>) before you drop, the text is copied to the new location rather than moved. As far as DnD text being dangerous? Which IDEs DON'T have this this feature?
Created attachment 51137 [details] Replacement patch making the service less specific and the method more. Service = "IDragAndDropService" method = "addEditorDropTarget" Boris, should I just make this a workbench-level service or leave it in the PartSite?
I have an app that "broke" after Bug 106372 was resolved (Provide DND support for the StyledText widget) but it brings up a larger issue which i think would be helpful to take note of for this bug. My app allowed the dragging of a "text processor" object from an RCP view onto a selection of text in the editor (StyledText widget). This allowed my users to process a specific selection of text using a drag/drop operation. I lost this functionality after the above bug was "fixed" due to the following. The semantics of my drag and drop operation were not one of "insert" but one of "process/transform". 99% of the time with a text editor, i think the semantics will be one of "insert". But there should be some flexibility in the API to override the default behavior (or only allow it for certain DataTransfer types/subtypes) so a developer can assign whatever semantics to the drag and drop operation which make sense for their users.
David, the proposed API extension contained in the preceding patch should allow this. It relies on the editor -author- (i.e. you...;-) to determine the mechanics of the feedback through its DropTargetListener impl and makes no presumption as to the control being used and/or any desired feedback.
committed in >20061002. Now have a new site-specific service IDragAndDropService that can be used to merge any drop handling desired by the editor author with the behaviour existing in the part's site (in this case the EditorSite). See 'org.eclipse.ui.examples.readmetool.ReadmeEditor' for a useage example. Daniel, try this and let me know if you have any problems...
Hi Eric, I gave it a try (see attached patch to play with it) and it almost works, but of course only for editors. For decent support in text viewers we need bug 142845 to get fixed. Now back to the editor problem: as soon as I install/merge the drop target for the text transfer we always get the textual (caret) feedback even if the drag source isn't text. This means dropping a file shows and moves the caret around which a) looks bad i.e. we should not see the caret/text feedback b) caret is probably moved to another position when drop is completed which is not what the user wants
Created attachment 51768 [details] First cut of text DnD in editors
Thanks Daniel, I've just checked and it seems that there are a number of glitches in the current SWT 'StyledText' widget. Beyond showing the caret it also seems to lose the current text selection (so a drop to -replace- text won't work). I'd prefer that you open the SWT-related defects (CC me if you think I can help) since the PlatformUI is not a part of the defect scenario(s) except for allowing the action.
(In reply to comment #100) You may want to re-open bug 106372 in particular as this was the one which added 'basic' DnD support to the StyledText widget. Insert works, but a replace attempt nukes the current selection.
>since the PlatformUI is not a part of the defect scenario(s) except for >allowing the action. It is: allowing alone is not good enough, it must also make sure to give correct drag over feedback depending on the source's transfer type: if I don't install text DnD then the feedback is correct. If I use "your" API to install text DnD then it is always the text DnD feedback no matter what the target is (i.e. if I try to drop a file). Your API must ensure that the correct drag over feedback is used. >it seems that there are a number of glitches in the current SWT 'StyledText' >widget. I could see the replace problem and filed bug 160630. Please file the bugs for the other "number of glitches" that you found and cc me please. There's an additional request: I need API to unregister the drop target again since we need to offer a preference to enable and disable text DnD.
Daniel, good point about needing the ability to 'turn off' the behaviour. I'll go over this with Boris to scope out what it should look like. For now you might just change the drop target to not accept Text based on the state of the preference rather than attempting to remove it. Stay tuned...;-) As far as I know the feedback handling is contained in the SWT listener code. I'll take a look using the readmetool implementation and report back.
>For now you might just change the drop target to not accept Text based This is not an option because we would get the text drag over feedback (even after the current feedback problem would have been solved).
Why? If you set event.feedback to DND.FEEDBACK_NONE you shouldn't get any feedback in the control (anything else is a defect).
You're right, I can suppress it by not accepting the text drop AND not allowing the drag start.
Eric, any update on this one? It would be bad to loose the momentum on this again. I cannot handle the DnD feedback on my side because my target is never called if a file is dragged over the editor - only if I drag text I get notified. Either Platform UI must ensure that or all merged drop targets must be notify to set the correct feedback.
Sorry folks, I've been 'heads down' trying to finish the min/max for M3... Daniel, what's happening in your current implementation that needs to be addressed? I'll coordinate with SteveN to see what can be done.
Committed in >20061024. The EditorAreaDropAdapter was not handling the 'dragOver' event and disabling the feedback. My readmetool example now works 'correctly'; no effect when dragging a file over the editor and cursor tracking when dragging text. Three is a secondary effect when dragging text in that any current selection in the widget is lost, this is an SWT issue and I'm not sure what can be done. Daniel, let me know if this fixes things up from your end...
I tested the changes and it works for me. >Three is a secondary effect when dragging text in that any current selection in >the widget is lost, I filed bug 162198 and marked it as blocking this one. I filed bug 162192 regarding the API for removing a drop target, but this is not a blocking bug. Eric, I think we can lift the dependency to bug 125957 and bug 142845 (I am not saying we don't need those but at least not to fix this bug) i.e. the only blocker at this point would now be bug 162198.
Fixed in HEAD. Available in builds > N20070104-0010.
Hi, I start experimenting with N20070105-0010 and dragging on java editor and I found some issues, e.g. on the following snippet: public class Teste { } Select the "class Teste" string and drag it into some part of the same string. There are some weird results depending on where you drop it, e.g. if you drop it between "c" and "l" from "class", you get "elass Teste". Another weird thing is the undo support: on the above example, I have to hit Ctrl+Z 2 times to restore the initial text. Hitting Ctrl+Z just one time gives me the text on some kind of "intermediate" state: "public cclass Testelass Teste {". Sorry if some of the previously dependency bugs are about this, but I don't recognize them because their descriptions are so low level. Is bug#169534 about this?
Yes, that one bug is the reason for the undo problem. Please file separate bug reports if you find trouble with the new support. This bug is closed.
MANY, MANY THANKS X 1000 TO YOU FOR THIS!!! ;-)
