Bug 153172 - KDE4: Can't move bookmarks in KEditbookmarks (drag is copy, Ctrl+Drag is move)
Summary: KDE4: Can't move bookmarks in KEditbookmarks (drag is copy, Ctrl+Drag is move)
Status: RESOLVED FIXED
Alias: None
Product: keditbookmarks
Classification: Applications
Component: general (show other bugs)
Version: 4.0
Platform: Compiled Sources Linux
: NOR major with 107 votes (vote)
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
: 163591 185327 186917 192042 198593 224774 226934 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-30 13:20 UTC by Allan Sandfeld
Modified: 2010-02-15 14:53 UTC (History)
19 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Reverse the copy/ drag behaviour (906 bytes, patch)
2009-09-12 16:25 UTC, Simon St James
Details
Use Ctrl instead of Shift (908 bytes, patch)
2009-09-12 16:35 UTC, Simon St James
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Allan Sandfeld 2007-11-30 13:20:52 UTC
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.
Comment 1 Daniel Teske 2007-12-02 17:48:00 UTC
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.
Comment 2 Alvin 2008-10-09 14:24:21 UTC
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.
Comment 3 Ivo Anjo 2008-10-18 17:07:14 UTC
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.
Comment 4 FiNeX 2008-11-30 16:41:38 UTC
I agree with Ivo: the default action should be "move" not "copy".
Comment 5 Dario Andres 2009-01-09 14:36:33 UTC
*** Bug 163591 has been marked as a duplicate of this bug. ***
Comment 6 FiNeX 2009-02-23 22:07:00 UTC
*** Bug 185327 has been marked as a duplicate of this bug. ***
Comment 7 Juha Tuomala 2009-02-27 15:43:49 UTC
Nice that this report already exists. Yes, it should definately *move* items, not copy.
Comment 8 FiNeX 2009-03-12 19:56:02 UTC
*** Bug 186917 has been marked as a duplicate of this bug. ***
Comment 9 Janet 2009-05-12 17:42:28 UTC
*** Bug 192042 has been marked as a duplicate of this bug. ***
Comment 10 Janet 2009-05-12 17:49:45 UTC
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.
Comment 11 Dario Andres 2009-08-17 19:29:02 UTC
*** Bug 198593 has been marked as a duplicate of this bug. ***
Comment 12 Simon St James 2009-09-12 16:25:46 UTC
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?
Comment 13 Simon St James 2009-09-12 16:35:04 UTC
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
Comment 14 David Faure 2009-10-01 13:43:00 UTC
Simon: your patch from comment #13 makes Move the default indeed, but the "+" sign still appears, which is confusing. This needs a better fix :)
Comment 15 David Faure 2009-10-01 15:48:38 UTC
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.
Comment 16 David Faure 2009-10-01 18:01:32 UTC
Merge request for Qt created: http://qt.gitorious.org/qt/qt/merge_requests/1668
Comment 17 Ronny Standtke 2009-10-12 10:26:10 UTC
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...
Comment 18 David Faure 2009-10-12 10:49:52 UTC
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.
Comment 19 Alain BAECKEROOT 2009-11-16 22:00:32 UTC
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. :-(
Comment 20 David Faure 2009-11-17 11:36:06 UTC
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.
Comment 21 Alain BAECKEROOT 2009-11-17 11:45:15 UTC
oops, sorry for confusion :-)

Related to the current bug ?
* cannot move bookmarks or folders on top of the bookmark list
Comment 22 David Faure 2009-11-17 11:55:48 UTC
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 23 David Faure 2009-11-17 11:59:24 UTC
Comment #21 is bug 213009.
Comment 24 Dario Andres 2010-01-29 17:58:47 UTC
*** Bug 224774 has been marked as a duplicate of this bug. ***
Comment 25 Dario Andres 2010-02-15 14:53:01 UTC
*** Bug 226934 has been marked as a duplicate of this bug. ***