Version: (using KDE Devel) Installed from: Compiled sources It is no longer possible to move bookmarks around in the bookmark editor, this leaves it practically useless.
Yep, I'm working on it. The code currently isn't in a pretty state. But well I have time this week to fix the most pressing bugs.
Should this be set to RESOLVED? There is still an issue left (Bug 160679), but moving and copying to anywhere but the end of the list is possible now.
I've been peeking around in bookmarkmodel.cpp, and was wondering: why not add if(data->hasFormat("application/x-keditbookmarks")) action = Qt::MoveAction; to the beginning of dropMimeData so dragging and dropping from inside keditbookmarks moves bookmarks instead of copying them? As a user, this confuses me a lot, I don't think there are that many times when I want to copy bookmarks, normally I'm just moving them inside subdirectories.
I agree with Ivo: the default action should be "move" not "copy".
*** Bug 163591 has been marked as a duplicate of this bug. ***
*** Bug 185327 has been marked as a duplicate of this bug. ***
Nice that this report already exists. Yes, it should definately *move* items, not copy.
*** Bug 186917 has been marked as a duplicate of this bug. ***
*** Bug 192042 has been marked as a duplicate of this bug. ***
It really is more likely to sort one's bookmarks (move) than to duplicate them. So the most likely situation should be the easiest to accomplish. As I already said in Bug 192042: Please bear in mind that some people need one-hand moving (and copying) of entries/files - so wouldn't it be the most practicable solution to use the standard KDE file handling behaviour and ask the user on dropping the file/entry what to do, copy or move? So only one hand would be needed and the behaviour would be consistent.
*** Bug 198593 has been marked as a duplicate of this bug. ***
Created attachment 36897 [details] Reverse the copy/ drag behaviour (Note: I wrote this patch before I saw Ivo's proposal) Having seen Ivo's proposal, I'm not really sure where best to fix this problem: Ivo's attacks it right at the core but hard-codes move instead of copy; my approach works only for target views that inherit from BookmarkView (which probably covers all cases) but allows one to still copy (by holding Shift). What do people think? What do people think of Janet's proposal to have the Copy/ Move menu show up? Would that be irritating after a while?
Created attachment 36898 [details] Use Ctrl instead of Shift Kevin requested Ctrl instead of Shift here: https://bugs.kde.org/show_bug.cgi?id=160679#c42
Simon: your patch from comment #13 makes Move the default indeed, but the "+" sign still appears, which is confusing. This needs a better fix :)
I think the best solution is to add a QAbstractItemView::setDefaultDropAction. I needed that already in a commercial project (for the exact same purpose). I'm making a Qt merge request with that.
Merge request for Qt created: http://qt.gitorious.org/qt/qt/merge_requests/1668
I just tested KDE 4.3.2 on Kubuntu 9.04. Now even Ctrl+Drag does not move but copy the bookmark entries. What a big mess...
Ctrl has always meant "Copy", it's Shift which means "Move" -- see dolphin and konqueror for example. But yeah not all bugfixes made it to 4.3.2. 4.3.3 and later will work much better for moving and copying bookmarks.
in kde 4.3.2 it is impossible to * move a bookmark on top of the list * move a folder between 2 other folders kbookmarkeditor is unusable as of 4.3.2, hence konqueror is useless too. :-(
Alain: you're confusing bugs. You're talking about 160679, which is fixed in KDE 4.3.3. This report here is only about the default action being move instead of copy.
oops, sorry for confusion :-) Related to the current bug ? * cannot move bookmarks or folders on top of the bookmark list
SVN commit 1050461 by dfaure: Use the API I requested for Qt-4.6: set the default drop action to "move", one has to hold Ctrl for copying. Fixed for: 4.4.0 BUG: 153172 M +1 -0 bookmarklistview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1050461
Comment #21 is bug 213009.
*** Bug 224774 has been marked as a duplicate of this bug. ***
*** Bug 226934 has been marked as a duplicate of this bug. ***