Community
Participate
Working Groups
Antix MEPIS Linux 7.0 Kernel 2.6.22.1-mepis-smp.i686 KDE 3.5.8 Eclipse 3.4 I20080324-1300 Sun 1.5.0_09-b03 Cannot drag a file or folder from Konqueror into p2 installer, despite this being demoed at EclipseCON as feasible in Windows. Doesn't work with folders or files. Steps to reproduce: 0. Run this (or equivalent) for a clean workspace w/ I20080324-1300: #!/bin/bash workspace=/tmp/workspace-clean-34 pushd ~/eclipse/34clean >/dev/null if [[ $# -eq 0 ]]; then rm -fr eclipse $workspace #eclipse=eclipse-SDK-3.4M5-linux-gtk.tar.gz eclipse=eclipse-SDK-I20080324-1300-linux-gtk.tar.gz echo "Unpack $eclipse..."; tar xzf $eclipse fi vm=/opt/sun-java2-5.0/bin/java #vm=/opt/ibm-java2-5.0/bin/java echo "Using vm=$vm and workspace=$workspace"; ./eclipse/eclipse -vm $vm \ -data $workspace -consolelog & popd >/dev/null 1. Help > Software Updates... > Available Features 2. Try to drag a zip file or unpacked zip folder anywhere into the "Software Updates and Add-ons" view. Nothing happens. 3. Click Manage sites..., then repeat step 2. Nothing happens. 4. Click Add..., then repeat step 2. Nothing happens. I don't even get console errors. :( How is DND supposed to work? Where do I drag & drop the file/folder? Or is this a Windows-only feature?
We use the SWT drag mechanisms for FileTransfer and URLTransfer to implement this. The intention is to be platform independent, but it depends on the underlying platform transfer mechanism used by SWT and whether a particular drag source program supports it. In general, if the package explorer/navigator supports a file drop from that source, then so should the p2 UI. If the navigator supports it and we don't, we have a bug. If it doesn't, then we won't either. I work on Windows and did all the testing there. I'm not sure which programs on various platforms can act as a drag source those for those d&d data transfers. As for how it works: Dragging a file or folder will map that file/folder to a repo URL and attempt to add that URL (which may generate an extension location repo at that URL). Supported drag targets include the "Available Features Tab", the "Manage Sites" dialog, the "Add Site" dialog. Dragging a URL from a browser will add that URL as a repo URL, targets are the same. We need to see what sources are supported on what platforms and make sure this is documented.
(In reply to comment #1) > Dragging a URL from a browser will add that URL as a repo URL, targets are the > same. > We need to see what sources are supported on what platforms and make sure this > is documented. Can't drag an update site URL such as http://download.eclipse.org/modeling/emf/updates/site.xml from Iceweasel 2.0.0.12 or Flock 1.0.3, either (both are Moz-based browsers). Seems like there's an underlying problem here that the Eclipse widgets aren't getting the data correctly, regardless of originating clipboard data source. I wonder if this works on Mac?
Grant, can you comment on URLTransfer support on Mac and Linux? Should this work?
Bug #100095 implies that URLTransfer should be working on GTK and Mac as of 3.4 M4. Of course, it still depends on the source browser supporting it also. Duong - do you know if Iceweasel 2.0.0.12 or Flock 1.0.3 should be working with URLTransfer? If not, which browsers work on GTK. We'll want to document in the p2 stuff which platforms/browsers we support for URL drag of repo locations. Not to self: bug #100095 discusses some workarounds with respect to using text transfer from browsers. We could consider these if need be.
(In reply to comment #4) > Duong - do you know if Iceweasel 2.0.0.12 or Flock 1.0.3 should be working with > URLTransfer? If not, which browsers work on GTK? In case you're unfamiliar with them, Flock 1.0/1.1 appears to be based on, or at least mostly compatible with Firefox 2. Iceweasel is Firefox, rebranded by the folks at Debian for licensing reasons. So in other words, if you support Firefox 2, you should support Flock and Iceweasel implicitly as well. (Konqueror, though it shares Firefox extensions/plugins for content-types and media, is another animal altogether, and I wouldn't be suprised (or upset) if it's not supported by SWT.) See also: http://en.wikipedia.org/wiki/Flock_browser http://developer.flock.com/wiki/Main_Page http://en.wikipedia.org/wiki/Iceweasel#Rebranding
thanks for the details...I'll let Duong comment on what should be supported from an SWT perspective.
On Linux, I've only tested using Firefox and I'm not sure whether URLTransfer will work with other flavours of Mozilla browsers. The current implementation only looks at one flavor (text/unicode) which appears to work in most cases. I believe we also need to include "text/x-moz-url". I will investigate this flavor.
I entered Bug#224198 against SWT to track URLTransfer problem.
Thanks, Duong. marking this bug dependent on that one (which is already fixed, cool). I cc'ed myself and Nick on that bug, hoping that Nick can verify that the browsers in question are working on the next M6 build.
*** Bug 227692 has been marked as a duplicate of this bug. ***
per duplicate bug 227692 - not working on Mac
This is still not working for me on I20080429-0100 with Firefox 2.0.0.14 and gtk 2.12.5.
Does the drag-and-drop work for you if you press the Ctrl button when you drop?
(In reply to comment #13) > Does the drag-and-drop work for you if you press the Ctrl button when you drop? Yes. Is this necessary/expected? I was under the impression it would just be regular drag and drop. FWIW, I get errors using the test update site: http://download.eclipse.org/eclipse/testUpdates/ http://download.eclipse.org/eclipse/testUpdates/ is not recognized as a valid software site location. Error reading update site http://download.eclipse.org/eclipse/testUpdates/ http://download.eclipse.org/eclipse/testUpdates/. but the Mylyn update site works fine.
It should just work but obviously there's a bug somewhere. From what I can see on the SWT side, the event.detail is changed from DROP_MOVE to DROP_NONE after the dragEnter event was sent. It gets changed to DROP_COPY when the Ctrl key is pressed and then set to DROP_MOVE when the Ctrl key is released. Can someone from Equinox look into this from their side to see if the URLDropAdapter code is doing the right thing? In my test when I drag a jar from the file system, the matching transfer type is the FileTransfer. The dropTargetValidate code attempts to prefetch the data to get the file name but it failed. Prefetch is not available on all platforms. It only works on Windows. The drag worked when you press the Ctrl key because the dropTargetValidate code is only called in the dragEnter code. As for the exception that you see, the Equinox team will have to investigate that. At this point, I'm pretty confident that the problem is not SWT related.
Hm, I wonder if this check in URLDropAdapter in p2 is causing the problem: URLTransfer.getInstance().nativeToJava(event.currentDataType) != null This happens on dragEnter, so perhaps because pre-fetch doesn't work on Linux this is causing the drag enter to say the drop target is not valid.
>The dropTargetValidate code attempts to prefetch the data to get the file name >but it failed. Prefetch is not available on all platforms. It only works >on Windows. I would suspect this is the cause of the problem. We could special case the drop adapter to not check the event data on platforms where it's not available. Duong, is there a bug open on SWT regarding prefetch? If we do special case the code, I'd like to be able to know when/if it changed to work elsewhere...
I don't believe there's a bug entered against SWT for pre-fetch. We do have this documented in DropTargetListener.dragOver. * <p>NOTE: At this point the <code>data</code> field is null. On some platforms, it is possible * to obtain the data being transferred before the transfer occurs but in most platforms this is * not possible. On those platforms where the data is available, the application can access the * data as follows:</p> I'm not sure, if it's possible to implement it on all platforms.
investigate for RC2
removing 3.4 milestone. Good idea, but we have bigger problems to fix for RC2.
I just downloaded Ganymede on Ubuntu Hardy. I have FF3, I am unable to DND urls into the installer list.
*** Bug 261418 has been marked as a duplicate of this bug. ***
I can't seem to drag a URL or a folder (from Nautilus) to anywhere in Fedora 10 with I20090309-0800 (or updated to I20090310-0100).
*** Bug 267849 has been marked as a duplicate of this bug. ***
Ian has an experimental patch and additional info in the dup bug. We need to adapt the drop target for platform differences.
I have filed bug 272740 with SWT. I created a snippet that behaves different on Windows vs. Linux.
I think this is the difference Duong mentioned in comment #18 (documented in DropTargetListener...once you know where to look). So I'm not sure that SWT can do anything about it. I followed the coding pattern in that comment originally, but what needs to be done is allow the null data on platforms that don't support it. On windows, we want to keep the check.
Created attachment 132494 [details] o.e.e.p2.ui patch This checks the platform (for win32, sorry I don't know if Mac supports this) to see if we can use the target data. I should point out that this opens up some more platform specific problems. For example, on linux if you drag the address bar (not the text, but the actual bar by selecting the icon), you get something like: http://www.example.com\n name of the location If you drag the text you get http://www.example.com So we may have to do some string processing. But this makes drag and drop work under linux.
Fixed in HEAD >20090420. Thanks for the patch, Ian! I changed the Platform/win32 check to use the JFace Util.isWindows() method. Based on other bug reports, I am making two assumptions about drag prefetch - it doesn't work on Mac (based on a comment by Pascal in the dup bug) - I am assuming that if data prefetch works on win32 it will work on vista. We can verify this during the test pass. I'll update to test plan to ensure that we check on win32, vista, linux, mac (cocoa and/or carbon)
build i0428-0100, linux-gtk - dnd from Firefox doesn't work for me, I am seeing url\nurl rather than just the url. (with Ctrl and without Ctrl) - dnd from the filesystem window manager to the Available Software page only works when I hold down Ctrl and drag and drag it to the list. If I try and drag it to the "Work with" text field it doesn't work.
