Version: (using KDE KDE 3.3.0) Installed from: Gentoo Packages OS: Linux When dragging a file out of ark and dropping it somewhere (e.g. copy it), ark stays in dnd mode. So if I move the mouse back to ark, I get an empty item attached to mouse. Klicking e.g. on the desktop afterwards calls a dialog where you can specify a file to save the clipboard contents to (that will create an empty file). Same thing happens when dropping the file back on ark (to cancel the dnd).
still valid with kde 3.4.0
*** Bug 114409 has been marked as a duplicate of this bug. ***
*** Bug 107527 has been marked as a duplicate of this bug. ***
*** Bug 112077 has been marked as a duplicate of this bug. ***
*** Bug 100776 has been marked as a duplicate of this bug. ***
A fix for this would be greatly appreciated. I tried this when I attempted to extract files with ARK for the first time. Because I'm so used to doing it with WinRAR on Windows. Kindof surprised it didn't work as expected.
d'n'd for archive extraction is fundamentally broken in ark, and it seems that this won't change within the near future. some nice examples: try to d'n'd a file from a relatively big archive (e.g. amarok-1.4.1.tar.bz2, 13MB). if you release the mouse faster than it takes to decompress the requested files (ca. 10s, since the whole archive has to be processed in the case of tarballs), d'n'd will fail ('empty clipboard'). and only my CPU monitor shows me that I have to press the mouse button a dozen of seconds longer than usual. try to extract a folder (with files inside) with d'n'd: every file will be extracted twice, once inside the folder and another time within the top level of the hierarchy of the extracted files. and sometimes, extraction of folders completely fails (with a nice error dialog, but if I release the mouse button, the dialog disappears). BTW: by pressing or releasing the left mouse button during the above tests (with KDE 3.5.3), i accidentally modified a couple of tarballs (moving/copying).
Well, if someone shows up to do the work - and takes care of syncing with trunk -, I believe there would be a fairly good chance to get fixes for these problems into the 3.5 branch. The situation as-is could hardly be worse, after all.
Created attachment 17505 [details] Since FileListView handles dragging, KListView shouldn't attempt to handle dragging too. This ought to fix returning to DnD mode.
SVN commit 577395 by henrique: * Fix for drag'n'drop problems. Patch by KDEfanboy <KDE.fanboy@gmail.com>. Thank you! BUG: 91556 M +0 -1 filelistview.cpp --- branches/KDE/3.5/kdeutils/ark/filelistview.cpp #577394:577395 @@ -193,7 +193,6 @@ setMultiSelection( true ); setSelectionModeExt( FileManager ); - setDragEnabled( true ); setItemsMovable( false ); setRootIsDecorated( true ); setShowSortIndicator( true );