Bugzilla – Full Text Bug Listing
| Summary: | [DND] Consider making URLTransfer public | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Benjamin Pasero <bpasero> | ||||||||
| Component: | SWT | Assignee: | Duong Nguyen <duongn> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | critical | ||||||||||
| Priority: | P3 | CC: | ekuleshov, hudsonr, Michal.Tkacz, mik.kersten, nicolas.richeton, rdowdall, robert.elves, snorthov, veronika_irvine | ||||||||
| Version: | 3.1 | ||||||||||
| Target Milestone: | 3.4 M4 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Benjamin Pasero
Any comment about the chance of getting URLTransfer for Windows? Ben Mylar (http://eclipse.org/mylar) needs this as well, to facilitate linking tasks to URLs (bug 114401). What platforms does it currently fail on? Why does swt need to be responsible for URL transfer? Can't that be implemented at the application layer? Where do you draw the line for Transfer types and what browsers you support? Would be nice to have snippets on how to do some of this standard stuff, but doesn't seem necessary to put it ALL in the swt library. Eric, maybe not, but since browser widget is also part of SWT it is sort of related. Also note that there are few other transfer implementations, and URLTransfer is not "any" but very common transfer type required when integrating SWT-based application with other GUI apps on given platform. I think in order to support URLTransfer on the application side, you need to use platform dependant code. I played around once for supporting DND for the Internet Explorer, and I think I only managed it to get right, using internal API. That is not what I want for an application that supports various OS. Ben Ben, isn't it another reason to make SWT/JFace to provide this functionality? There is at least one thing I need to resolve before getting this supported on all platforms. On Windows the type UniformResourceLocator provides a title and a url. Other platforms do not provide the title. I could just ignore the title field for all platforms. There are also a number of data types that could map to URL on other platforms and I need to decide for each platform what is appropriate. Unfortunately I am swamped right now and there is an API freeze so I do not think this is going to happen in 3.2. If you would like to contribute a Mac or GTK implementation as a patch I will find time to look at it. Veronika the title thing is not reliable even on Windows. For example if you drag url fom the location title will be taken from page title, but if you drag it from an anchor tag <a> title will have text from the anchor tag. Our current work-around for this with Mylar is to always ignore the title on Windows and just fetch it via HTTP after we get the drop, due to the inconsistency Eugene mentions when dragging a link on the page and not from the address bar. Veronica: from what I understand it seems right to just ignore that title on all platforms, and it would definitely be nice to have this in 3.2 (it's an API addition, which is allowed from what I understand?). All: we work around this by using text transfers. Works fine on Mozilla across the platforms we've tested, bug annoyingly with IE on Windows requires Ctrl to be pressed to create a DND.DROP_COPY, since DND.DROP_MOVE does not seem to get sent as a text transfer (only URL). Eugene: Exactly. My comment aimed to emphasize how important an implementation on the SWT side is. Ben Created attachment 39097 [details]
GTK Implementation of URLTransfer
Beatriz has implemented URLTransfer for GTK, Motif and Carbon. I am attaching the patches for them here. Because 3.2 is API frozen, URLTransfer support can not be added in 3.2 However, it will be added for the next release of eclipse (3.3?).
Created attachment 39098 [details]
Carbon implementation of URLTransfer
Created attachment 39099 [details]
Motif implementation of URLTransfer
(In reply to comment #11) > Because 3.2 is API frozen, URLTransfer support can > not be added in 3.2 However, it will be added for the next release > of eclipse (3.3?). This is an important feature and it would make sense to have this for 3.2. Can you please request PMC for this to be added? Great to hear that! I would give my +1 for 3.2 as well =). Ben BTW, it is not API change, but new addition to the API. So, we can't really wait another year for that. You can always put bugfixes on later Eclipse versions if there is anything wrong with the current implementation. Planned for 3.3? Ben *** Bug 163251 has been marked as a duplicate of this bug. *** I'd like to see this become API too. We're currently testing the protected Transfer via java reflection, and it works perfectly. We can drag URLs from firefox or sametime and drop them into SWT applications. The title is not interesting. It seems like the code exists for 4 different windowing systems. Is there anything holding this bug up? Veronika, are the patches posted here almost ready to go? If so, we should get this code out for 3.3. Duong, we are currently missing a WPF and Photon implementation. You will need to code the WPF one and get Rodney to code one for Photon. Is this being considered for 3.4? I'm marking this as critical since "enhancement" doesn't capture the importance, and since the work is done for the most part. We need to allow users to drag from a browser to an SWT control. For example, the user uses Google to search for an Image, and then wants to drag that image to a control, capturing the URL or downloading the image, etc. Fyi, the following Mylyn item on the Tips and Tricks is the caveat that results from this limitation, due to MSIE sending URLTransfers: "Task List View When dragging URLs to the Task List: in Mozilla/Firefox just drag, in Internet Explorer Ctrl+drag" http://www.eclipse.org/mylyn/tips/ Fixed > 071115 URLTransfer is now public and is available on all platforms. Photon has a fake implementation. The current implementation does not include the title. Excellent, great to see. Fyi, Mylyn already retrieves titles via an httpclient connection, so while they would be nice we do not have a strong driver for that. Thanks Mik for the update regarding the titles. Due to unrelated build issues, this feature did not make it into this week's build but it is available from HEAD. |