Bug 36297 - KDE4: dragging not XDND compliant -- host name not included
Summary: KDE4: dragging not XDND compliant -- host name not included
Status: RESOLVED MOVED
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Other
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-12-19 04:48 UTC by John Lindal
Modified: 2015-04-28 19:20 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Lindal 2001-12-19 04:39:35 UTC
(*** This bug was imported into bugs.kde.org ***)

Package: konqueror

Overview Description:

Your use of XDND for dragging files is not compliant with the XDND
protocol. You are not prepending the hostname to the file name as specified
in http://www.newplanetsoftware.com/xdnd/dragging_files.html

Steps to Reproduce:

Download
ftp://ftp.newplanetsoftware.com/pub/xdnd/xdnd-v4-binary-Linux-Intel.tgz
unpack it and run test_xdnd from a terminal window.  Then drag a file from
konqueror to test_xdnd.  test_xdnd will print an error because the host
name is not included in the URL.

Actual Results:

Target window is not highlighted with a blue border.  This means that the
target is not accepting the drop at all.

Expected Results:

The target window should be hilighted with a blue border while the mouse is
over it.  After the drop the file should be listed in "File/directory
names" section of console output.
Comment 1 Braden MacDonald 2002-08-27 00:28:16 UTC
The DND works if you drag from the small icon in the konqueror title bar next 
to the current location/file name but if you drag a file from any main 
konqueror view to another app it doesn't work.

PLEASE FIX THIS!!!

Linux needs things like this to work or it will never be accepted as a 
desktop.
-- 
-Braden
Mandrake Linux 8.2
www.mandrake.com
Comment 2 Lubos Lunak 2002-10-16 14:24:12 UTC
 It works with icon in url bar but not with icons from the view because the test app accepts    
only Copy DND operation, which is what the url bar does, but the default for icons is Move DND    
(can be changed by holding Ctrl). (The binary requires libstdc++ for gcc-2.96 BTW). The  
problem is only not including the hostname in the URL. 
 
Comment 3 Lubos Lunak 2002-11-07 18:03:16 UTC
 The code responsible for receiving file drops (and KIO?) should also check isLocalFile() for file:/ 
URLs before working with them. 
 
Comment 4 oliv 2003-04-03 10:55:19 UTC
I have opened the following bug which happens to be a duplicate from this one:
http://bugs.kde.org/show_bug.cgi?id=56709
(KDE 3.1)
I'd like to have a DnD working between KDE and Gnome/Gtk2 apps (eps. th dev.
branch of Gimp)
Comment 5 Rex Dieter 2003-04-03 16:03:36 UTC
*** Bug 56709 has been marked as a duplicate of this bug. ***
Comment 6 Waldo Bastian 2003-04-28 21:49:24 UTC
Problems with DnD between Qt and Gtk2 are due to a bug in Gtk2, fix confirmed by 
Owen Taylor. 
 
Including hostname in drags is problematic since many applications don't properly 
handle that. KDE does need to properly handle hostnames when present though, 
and possibly check them in that case. 
 
Comment 7 oliv 2003-04-29 09:39:57 UTC
I was to actually confirm this today, as I have managed to use the test_xdnd
program yesterday, and it seems the DnD from KDE works.

So it seems at least my bug reports and rants have somehow had an effect.

Thanks Waldo, Owen and Lubos for having take care of this issue.

Should this bug be closed? (I'm not the reporter anyway so cannot close it)
Comment 8 Lubos Lunak 2003-04-29 15:20:51 UTC
I've committed change that adds hostnames in file:/ URLs in drags, and immediately disabled it 
because of the above-mentioned problems. Maybe later. When receiving the drops, there are 
still no checks for the hostname being the current hostname, and that should be probably 
added. IMHO not that critical though. 
 
 
 
Comment 9 Jesper Juhl 2003-05-03 00:34:25 UTC
hmm, disabling a correct fix becourse it breaks apps... While I can see some sense in 
that, wouldn't it make as much (or more) sense to include the fix (since it does the 
correct thing) and then fix the broken apps (since that's what they are - broken)..? 
 
Comment 10 Sashmit Bhaduri 2003-09-15 03:48:33 UTC
Would you rather have more D&D breakage?
Comment 11 Stephan Kulow 2003-10-16 19:40:51 UTC
not before I guess
Comment 12 George Staikos 2003-12-17 10:32:40 UTC
People are reporting in the duplicates of this bug that it is now fixed.  Closing.  Please reopen if this is not the case with KDE 3.2 and recent GTK+.
Comment 13 oliv 2003-12-17 10:47:24 UTC
There is no reason to close this bug!

The duplicate (56709) you are referring to is not an actual duplicate. See the comment number 5 by Lubos Lunak:

"This bugreport was marked as a duplicate of 36297 by mistake, it wasn't a duplicate. I believe I just fixed the KDE problem that caused this specific problems. That doesn't mean it will actually work though. Gtk2 needs a fix too."

So bug 56709 must be closed as it is fixed, but not as a duplicate, and this bug should be reopened.
Comment 14 George Staikos 2003-12-17 10:52:21 UTC
Should have repaired the other bug then.
Comment 15 Jesper Juhl 2004-01-01 21:49:56 UTC
> ------- Additional Comment #11 From Stephan Kulow 2003-10-16 19:40 ------- 
> not before I guess 

I assume this is in reply to my comment about fixing broken apps in #9.

I'd say that implementing the correct behaviour, and thereby break the broken apps, would be a strong incentive for those apps to be fixed by their authors.
Otherwhise KDE could be waiting forever for those apps to be fixed...


Comment 17 George Goldberg 2008-05-04 04:42:51 UTC
Can anyone comment on the status of this bug? I can't get the test application running, but its been very quiet for a long time? Is it still present in KDE 4?
Comment 18 Viesturs Zarins 2008-05-06 22:02:50 UTC
The binary depends on quite old stuff. I'm afraid it may prove quite tricky to run it alongside KDE4.

Im now trying to compile it from source...
Comment 19 Viesturs Zarins 2008-05-07 00:15:47 UTC
Too bad, the source provided on the server is not for the test app, but some reference implementation classes.
Comment 20 shamousi 2008-12-23 13:02:07 UTC
A "severe" bug, because some apps relay on the proper way. For example: All wine application doesn't work with the Drag&Drop feature anymore (KDE 4.x)

KDE 3.5.10 wine notepad.exe trace of xDND reveals:
trace:xdnd:X11DRV_XDND_SendDropFiles Sending WM_DROPFILES: hWnd(0x0x1002a) 0x1e524c(Z:\home\gizmo\test.txt)

BUT in KDE 4.1:
trace:xdnd:X11DRV_XDND_SendDropFiles Sending WM_DROPFILES: hWnd(0x0x1002a) 0x2454354()

So you see, the target is missing. No wine applications will work any longer with xDND. Maybe this could be fixed?

Thx :-)
Comment 21 shamousi 2009-06-06 13:46:30 UTC
Any news on this?

Using KDE 4.2.2 (Kubuntu Jaunty) still not working... No more drag&drop support to wine apps!
Comment 22 FiNeX 2009-09-09 00:49:36 UTC
Any news?
Comment 23 David Faure 2015-04-28 19:20:39 UTC
This was fixed in Wine: https://bugs.winehq.org/show_bug.cgi?id=16306