To clarify: the OP is asking for an option to have left drag always perform the Move operation. When the option is enabled, the user can get the Move/Copy/Link menu by dragging with the right mouse button.

I agree that this is a terrific usability idea.

*** Bug 224573 has been marked as a duplicate of this bug. ***

*** Bug 287762 has been marked as a duplicate of this bug. ***

Robert, feel free to create a patch, and put it on reviewboard. Make sure you develop it against master branch.

I haven't forgotten about this bug (wishlist) report, and today it finally made its way to the top of my list of things to look into.
I'm still fairly new to Qt, and I'm not acquainted with the KDE extensions thereto, so forgive my ineptitude - I'm still learning.
So far, I've got my head around QDrag, QDrageEnterEvent, QDragMoveEvent and QDropEvent, and I see that dropping files is handled in KItemListController::dropEvent(). At first this seems like the obvious place to implement the default behaviour, but at the moment, this function handles a couple of member variables and then emits an itemDropEvent. That's connected to DolphinView::slotItemDropEvent(), which repackages the same event and passes it off to DragAndDropHelper::dropUrls(). Perhaps implement the new behaviour here instead? But here, once again, not an awful lot happens, and it's then passed on to KonqOperations::doDrop() - which isn't even part of Dolphin anymore, but rather KDE/Konqueror library code.
KonqOperations::doDrop() is a wrapper for an overloaded version of itself, which sets the member struct DropInfo, then uses QMetaObject::invokeMethod() to call KonqOperations::asyncDrop().
asyncDrop() can (potentially, depending on many factors) call doDropFileCopy(), where we finally find the code that generates the popup menu.

As you can see, I have spent some time investigating the matter.
I see you use LibKonq code for the drag and drop. This (I assume) means if I change the behaviour at the source, it will affect much of the rest of KDE as well.
I'm not sure how these things work, but I doubt I have the authority to make that call. Should I implement the behaviour in one of the Dolphin classes, to contain the changes? Or bite the bullet and change the library code?
Then, assuming I've found a place to ammend the code, I would ideally have some way of querying the containing partition of the source and the destination (I'm assuming other file managers implement their fuctionality by comparing the two). Does anyone know of a way to do this? Does KDE provide an API?

Also, could you link me to reviewboard? I've never submitted new code for KDE before.

Thank you very much for any help you can provide - I'm very to keen to get actively involved in coding for KDE.

@Rob: First thanks for digging into the sources, your help is very welcome!

> ... I see that dropping files is handled in KItemListController::dropEvent().
> At first this seems like the obvious place to implement the default behaviour,
> but at the moment, this function handles a couple of member variables and then
> emits an itemDropEvent.

This is done on purpose: KItemListController is not (and should not be) aware of "files". It just is responsible to inform about a drop-event done on a generic item with a given index.

[...]
> I see you use LibKonq code for the drag and drop. This (I assume) means if
> I change the behaviour at the source, it will affect much of the rest of KDE
> as well.

I don't think it would be a good idea making this a Dolphin-only option. So if this feature with the option should be implemented, it should be applied on all applications that use libkonq for filemanagement and this is fine.

> I'm not sure how these things work, but I doubt I have the authority to make
> that call. Should I implement the behaviour in one of the Dolphin classes, to 
> contain the changes? Or bite the bullet and change the library code?

Please bite the bulled ;-) The maintainer of the libkonq is David Faure, so before starting with a huge patch please ask David first whether he agrees in general having such an option at all and implementing it in libkonq. I'd suggest to post a question to kfm-devel@kde.org where Dolphin, Konqueror-filemanagement-topics and libkonq-code gets discussed (David is subscribed there too). David is very busy, so probably it takes a few days until you'll get an answer.

> Also, could you link me to reviewboard? I've never submitted new
> code for KDE before.

The reviewboard is at git.reviewboard.kde.org but as said above I think it is preferable to discuss at kfm-devel@kde.org first whether it is OK to implement this and probably discuss some details then. The patch at the reviewboard is only the last step before getting the feature committed :-)

If you get the OK from David to implement this (from my point of view this would be fine), I will of course help to create a configuration option that will be integrated then in Dolphin + Konqueror.

Robert, have you brought the topic for discussion to the kfm-devel mailing list?

*** Bug 277446 has been marked as a duplicate of this bug. ***

Christoph (and others),

I emailed the mailing list quite a while back (18th March), but the message has been awaiting moderator approval ever since.
I re-sent it today, having joined the mailing list to try to ensure its acceptance.

Let's hope for a response...

Hi all,

It turns out the matter has been discussed and they don't really feel like implementing the feature because they think it could lead to accidental unexpected behaviour. Also, they haven't registered much demand, so the more people who email the kfm-devel@kde.org list requesting the feature, the more likely it would be that they change their mind. It may also be worth pointing other similar requests here, so they can see the matter has been discussed, but also that they should make their opinion known if they wish to instigate change.

(In reply to comment #10)

It would be nice if you did not use inaccurate and incomplete information to encourage others to not only waste their own time, but also the time of everyone who reads the mailing list. According to the discussion you started on the mailing list some time ago,

http://lists.kde.org/?t=133207879300004&r=1&w=2

you did not propose to implement the feature which has been requested in this report, but something else, namely making drag and drop context-sensitive. From my point of view, the discussion on the mailing list contains some convincing arguments why we should not implement this.

It has been made clear here and in the mailing list discussion that a prerequisite for considering the feauture which has been proposed here is that David Faure agrees that it makes sense. To be honest, I'm not much in favor of it because every option makes the application more complex, potentially more confusing for the user and harder to maintain for us, and I think that the user group that would benefit from such an option is quite small.

Frank,

Terribly sorry I've posted this on the wrong bug. It should have been posted on bug 287762.

Unfortunately I was not informed at the time that my email had been posted to the mailing list, so I was unable to participate in the discussion at that point. I agree that some good arguments were put forward as to why it should not be implemented. In fact, they seemed to be the only arguments put forward, so there wasn't a huge amount of discussion.
The post here was to try to get some of the supporters of the idea to speak up, as although I provided a list of links to people with a similar opinion in bug 287762, those people's voices are not heard in the mailing list.
It seems unlikely to me that the general consensus is as one-sided as it seems from the mailing list, especially as context sensitivity was deemed to be desirable by both Windows and OSX (which is unix-like), which together make up a phenomenal majority of desktop operating systems.
I'm not saying that context sensitivity is undeniably right, but that given huge research budgets, it has been chosen for many major operating systems.

I apologise for the confusion on this front. This bug is not in fact a duplicate of my original post, and further discussion of the matter would seem better suited on bug 287762.

I apologise once again - I had no intention of wasting time, but rather encouraging sensible and meaningful debate.

Actually, for what I want, I don't really care about this anymore. Somehow over the years I got used to the behaviour of dolphin in this case and wouldn't press on changing it anymore.

So if there aren't other people voting for this change, you could close it as won't fix.

I still do think that this feature is important.

I help people move from Windows to Kubuntu, and I've helped many tens (probably well over one hundred) people to learn Dolphin and other KDE apps. I have a nice list of common gotchas and this one ranks high. In fact, the reason that I found this bug in the first place was to file it myself exactly for this reason.

_I_ personally don't mind the behaviour. However users used to more user-friendly environments don't expect and don't appreciate the "annoying popup that gets in the way of their work".

I can second that. One of the really annoyances in KDE is the complicatedness. And this is another sad part of it. I got "used" to it as well, but people get used to everything, which does not imply that it is good.

(In reply to comment #14)
> I help people move from Windows to Kubuntu, and I've helped many tens
> (probably well over one hundred) people to learn Dolphin and other KDE apps.
> I have a nice list of common gotchas

You might want to discuss these issues with the usability team then. It's quite likely that some small changes in certain places will not only make the Windows -> KDE transition easier, but impvove the usability for everyone.

However, this does probably not apply to every single issue. If people got used to a certain behavior of an application because it's what Windows does, this does not necessarily mean that the Windows way is correct, and everything else is wrong.

> _I_ personally don't mind the behaviour. However users used to more
> user-friendly environments don't expect and don't appreciate the "annoying
> popup that gets in the way of their work".

I strongly object the idea that everything that Windows does is "more user-friendly". Whenever I use Windows, I am extremely annoyed by the fact that there is no drag&drop dialog, and Windows decides for me if the file is moved or copied (the decision it takes is very often not what I want). I consider KDE much more user-friendly in this regard. (But I'm not saying that I am "right" - neither you nor I are usability experts. This should better be discussed with the usability team, rather than here at bugs.kde.org.)

Now the users whom you  were in contact with obviously have the opposite opinion, but this is just because they have been trained to expect that there is no dialog by using Windows for many years. IMHO, it does definitely not mean that the Windows way of handling drag&drop is more user-friendly.

(In reply to comment #15)
> I can second that. One of the really annoyances in KDE is the
> complicatedness. And this is another sad part of it.

As I said above, I consider the Windows way to handle drag&drop by guessing what the user wants complicated and sad.

> I got "used" to it as
> well, but people get used to everything, which does not imply that it is
> good.

Many people got used to Windows guessing if they want to copy or move a dropped file, but people get used to everything, which does not imply that it is good.

In any case, I am closing this Dolphin report now because:

(a) Nothing can be done in Dolphin to change the drag&drop behavior. Everything that happens when a file is dropped is handled by the lib/konq library, which is not part of Dolphin. It does not have its own 'product' at bugs.kde.org, but reassigning this report would not make much sense anyway IMHO because...

(b) bugs.kde.org is good for tracking bugs, but it is pretty useless for discussing feature requests and usability issues. The number of people who read and comment on bug reports is quite limited and does not include usability experts.

I encourage anyone who has strong feelings about this issue to start a discussion with the usability team.

>> user-friendly environments don't expect and don't appreciate the "annoying
>> popup that gets in the way of their work".

> I strongly object the idea that everything that Windows does is "more user-friendly".

I strongly object the idea of reinterpreting my sentences to mean what they don't! :)

I do feel that Windows is more user friendly for reasons that are beyond the scope of this bug report. Likewise, I do feel that OS-X is more user friendly. Independent of those assertions, which you may or may not agree with, I note that users don't expect and don't appreciate the "annoying popup that gets in the way of their work". That is indisputable based on empirical evidence.



> In any case, I am closing this Dolphin report now because [..] bugs.kde.org is good for tracking bugs.

Would you argue that unexpected behaviour is _not_ a bug? I thought that is the very definition of a bug.

Also, why is this marked as RESOLVED _UPSTREAM_? What is UPSTREAM in this sense?

(In reply to comment #17)
> > In any case, I am closing this Dolphin report now because [..] bugs.kde.org is good for tracking bugs.
> 
> Would you argue that unexpected behaviour is _not_ a bug? I thought that is
> the very definition of a bug.

The problem is that "unexpected behavior" is not a well-defined an unambiguous term. For me, the lack of a dialog on Windows is unexpected, but I am not sure if I would call the Windows behavior a bug. The Windows usability people made a choice that some users are happy with, and some others are not. One can argue about whch behavior is better (but not at bugs.kde.org please. A bug tracker is not suited to this kind of discussion IMHO), but this does not necessarily mean that either behavior can be considered a bug.

> Also, why is this marked as RESOLVED _UPSTREAM_? What is UPSTREAM in this
> sense?

As I said, lib/konq (which is part of the KDE SC, but has no product here at bugs.kde.org) is UPSTREAM from Dolphin's point of view.

If you prefer, we can reassign the report to the generic "kde" product and reopen it, but this will not have any effect on whether this feature will be implemented or not. As I said earlier, I strongly encourage you to start a discussion with the usability team. Adding further comments here is just a waste of time.

This is my last comment in this report. I will not respond to any further replies because, as I have said repeatedly, nothing can be done in Dolphin to achieve the behavior you want, so my opinion does not actually matter much in the context of this report. Thanks for your understanding.

(In reply to comment #16)
> I strongly object the idea that everything that Windows does is "more
> user-friendly". Whenever I use Windows, I am extremely annoyed by the fact
> that there is no drag&drop dialog, and Windows decides for me if the file is
> moved or copied (the decision it takes is very often not what I want).
Actually, that really is a point, since the behaviour on Windows is not really consistent. I.e. for a D&D within a drive/partition, it moves the file, whereas for a D&D into another drive/partition, it will copy.

I guess, that this is inspired by internal processes, since that's where both differ, but still it's inconsistent and therefore not really user-friendly.

On linux, this wouldn't be a problem, since home is usually on a single volume and therefore you would either always copy or always move.

(In reply to comment #19)
> the behaviour on Windows is not
> really consistent. I.e. for a D&D within a drive/partition, it moves the
> file, whereas for a D&D into another drive/partition, it will copy.

Windows behavior is likely derived from the ancient M$/IBM synergy. What follows is an explanation for the OS/2 WPS behavior from ISBN 0-13-842147-1 "Getting to Know OS/2 Warp 4", pp 85-6:
[quote]
4.2.4 Dragging and Dropping Objects
When you use the Workplace Shell, you will often perform tasks on objects by selecting an icon with your left mouse button, then pressing and holding down the right mouse button while you "drag" the icon over another icon. You will then release the right mouse button to "drop" the first icon on the second. For obvious reasons, this is known as the drag and drop interface.

Dragging and dropping objects can have one of several effects:

* Moving an object: dragging an icon from one location to another will cause the object to be relocated to the target location. In this way, you can move an object from one place to another.

In most cases, this is the default action performed when you drag and drop an icon. For some objects however, you might find that moving an object is not the default operation when you drag the icon to a new location. In such cases, you should press and hold down the Shift key while dragging the icon in order to move the object to its new location.

* Copy: pressing and holding down the Ctrl key while dragging an icon from one location to another will copy an object, rather than moving it. The original object will remain unchanged.

In most cases, the default action when dragging and dropping an object between locations is to move the object. However, OS/2 Warp will always copy an object when you drag and drop an icon to a networked location such as a LAN-attached drive object....

During a copy operation, the object's icon and the mouse pointer will be shaded, to give you a visual indication that a copy operation is being performed....
[/quote]

I used OS/2 as my primary OS from 1997 to 2011 (before that, DesqView on DOS,  never Windows), with Linux/KDE as secondary after around 2002. I could never assimilate the OS/2 D&D instructions, so I avoided DND as much as possible. With the different set in KDE, the problem got worse. The main way I avoided, and still avoid in KDE, is through use of orthodox file managers, FC/2 on OS/2, and on Linux mostly MC but also FC/L. IOW I never used Konq as a file manager, and don't use Dolphin (mainly because I love using the OFMs and the vttys for such chores, but also to avoid D&D confusion).

The point of my lengthy comment here is that D&D isn't intuitive for everybody. It needs maximum flexibility to accommodate differences among users. I don't see how there can possibly be only one correct configuration/behavior paradigm, particularly on account of users migrating to KDE from other environments.

"The Windows usability people made a choice that some users are happy with, and some others are not."

That's why the dialogue showing up could still be the default, but at least give an option to change it in the preferences for those who are more comfortable without it. And it isn't even just windows, gnome2 had the same behavior of not having a dialogue and relying on shift or ctrl modifiers..

> Actually, that really is a point, since the behaviour on Windows is not really consistent. I.e. for
> a D&D within a drive/partition, it moves the file, whereas for a D&D into another drive/partition, it
> will copy. 

Who cares? Nobody is asking to implement the Windows behaviour. This bug is for implementing an option to have D&D using the left mouse button to always perform Move. See the OP.

*** Bug 392531 has been marked as a duplicate of this bug. ***

*** Bug 224257 has been marked as a duplicate of this bug. ***

*** Bug 406122 has been marked as a duplicate of this bug. ***

*** Bug 423356 has been marked as a duplicate of this bug. ***

Re-opening due to user demand (see Bug 392531).

There are some old patches that implement this behavior:
- https://phabricator.kde.org/D27951 (KIO)
- https://phabricator.kde.org/D27998 (plasma-workspace/systemsettings)

This feature is importat! Please add this feature!

*** Bug 432912 has been marked as a duplicate of this bug. ***

Increasing priority as the number of duplicates rises. There appears to be significant user desire for this.

We definitely need this. I was looking how to do this for years and came to this discussion. KDE is all about flexibility, number of options, power of configuration. I just want an option for Drag and Drop to perform Move operation as default action. Maybe someone has an idea how can I get this done in some config files???

Making move by default be an optional behaviour would be very welcome. I'm not a power user & in my ~20 years of using linux I don't think I've ever selected any option other than the Move one from the menu.

I just came across this when helping a new user move from windows. The popup was immediately annoying to them as they expected it to be obvious to move with dragging. The human intuition seems to be dragging == moving. The person I was working with demonstrated to me by grabbing an object on the table and "dragging" it to another location. The object is physically moved and not cloned and by intuition a new user expects similar inside the virtual world of the computer desktop system.

I'm not a KDE user myself, but felt it's the best option for this user, and when they complained about the popup on drag-drop files I figured there must be an option to change the behavior and was surprised to discover there isn't.

I have read through the bug threads and the comments in the patch development, and I agree that the Windows "magic" and inconstant behavior is not optimal. I would rather see a defined and consistent behavior like always assume Move. Even the ex-Windows user complained that when dragging from one device to another Windows made a copy instead of moving as expected.

>The person I was working with demonstrated to me by grabbing an object on the table and "dragging" it to another location. 

That's not a very relevant point, you can't copy or shortcuts in the physical world. You can in the virtual world hence the need to prompt.

Just for the record, we have had copy machines (or carbon copy) for quite some time, not mentioning physical pointers or any number of indexing devices. I don't have any stake in whether this should be default, but an option would be a blessing. I have been on KDE for two weeks now and have not got used to it yet.

This has 7 duplicates which is a measure of significant user desire, so it can't be low priority. Returning to HI priority.

I have gotten used to this over time but it still has to be one of the most stubborn UX quirks I’ve seen in a while.  Providing an option just persists the choice from the prompt, allowing the user to save a default for themselves rather than having to endure the prompt every time when likely one option is always going to be more common. To steadfastly refuse that is taking more of a principled hard line over actually improving the UX.

Removing subscriber per abuse reports we received.

(In reply to David Edmundson from comment #34)
> >The person I was working with demonstrated to me by grabbing an object on the table and "dragging" it to another location. 
> 
> That's not a very relevant point, you can't copy or shortcuts in the
> physical world. You can in the virtual world hence the need to prompt.

I think it is relevant when talking about UX, intuition and expected behavior. We refer to computer concepts using real world objects all the time - Files, Folders, Desktops. Expecting to interact with those concepts in the same way as in the physical world seems reasonable to me. I'm a command line user myself, so never paid much attention to such GUI behaviors, but when confronted by new user frustrations, I totally get their point.

Of course on a computer system there are other options than "moving" and we should have ways to access those options via key modifiers or using alternate mouse buttons. I don't think we can come up with defaults that everyone is happy with. I just hope we can make the behavior configurable.

Someone submitted patches that implemented the requested change, but ultimately abandoned them because we couldn't figure out a way to always copy by default instead of moving when dragging across devices (for safety). The work is still there for someone else to pick up:

- https://phabricator.kde.org/D27951 (KIO)
- https://phabricator.kde.org/D27998 (plasma-workspace/systemsettings)

Hello, I have a question apart from making this configurable.
The behavior upon dropping can be chosen up until the very last moment on X11, by holding down Shift, for example, to turn it into a Move operation.
On Wayland however, the key modified must be pressed before starting the drag and drop operation, which is less intuitive and inconsistent with X11 (and Windows, for what it matters).

Is this the good place to discuss this, or is there a separate bug to track that?

Just tested with:

Operating System: openSUSE Tumbleweed 20220520
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.2
Kernel Version: 5.17.7-1-default (64-bit)
Graphics Platform: Wayland
Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz
Memory: 15,4 GiB of RAM
Graphics Processor: Mesa Intel® Xe Graphics


Thanks

>Is this the good place to discuss this, or is there a separate bug to track that?
Separate. I'm pretty sure one exists already somewhere.

(In reply to Bernd Steinhauser from comment #0)
+1 please. I personally want the left always move, right context.

Big +1 here. I don't see any reason to not at least include an option to have the Windows-like behavior here.

*** Bug 467220 has been marked as a duplicate of this bug. ***

(In reply to sbahling from comment #39)
> Of course on a computer system there are other options than "moving" and we
> should have ways to access those options via key modifiers or using
> alternate mouse buttons. I don't think we can come up with defaults that
> everyone is happy with. I just hope we can make the behavior configurable.
Key modifiers and even alternate mouse buttons are for power users only.
Except for a few really known ones (like CTRL+c and CTRL+v), you really can't expect an ordinary user to remember any shortcut.
The typical user doesn't even know key combinations like Meta+e or Meta+l.
Heck, I consider myself a well-knowing PC user and even I really don't see the point in the about million key combinations that KDE defines by default.
Actually it's so many, that I really avoid them (to some degree), because chances are high you hit a wrong key and something awful happens.
In my opinion (and this is only my personal opinion), about 80% of them should default to "None", but have a "suggested key combination" instead, a concept that doesn't exist currently (and also might not be wanted by others, don't know).

Anyway … you really can't expect people to know that left mouse button will move and e.g. Ctrl+LMB will copy.
RMB drag, as I described in the first post, maybe, but even that is a concept that most users wouldn't incorporate into their workflow.

The current way is actually a pretty smart way to give a typical user a way to decide between copy and move without needing to remember key combinations. Hence it should be the default.

(In reply to Nate Graham from comment #41)
> Someone submitted patches that implemented the requested change, but
> ultimately abandoned them because we couldn't figure out a way to always
> copy by default instead of moving when dragging across devices (for safety).

But why change the behavior in that case? IMO it's an inconsistency that shouldn't exist.
If I would still want it to move by default, I would also want it to do that when I move files from one filesystem to another.
(I think it's filesystems that matter here, not devices.)

(In reply to Bernd Steinhauser from comment #48)
> (In reply to sbahling from comment #39)
> > Of course on a computer system there are other options than "moving" and we
> > should have ways to access those options via key modifiers or using
> > alternate mouse buttons. I don't think we can come up with defaults that
> > everyone is happy with. I just hope we can make the behavior configurable.
> Key modifiers and even alternate mouse buttons are for power users only.
> Except for a few really known ones (like CTRL+c and CTRL+v), you really
> can't expect an ordinary user to remember any shortcut.
> The typical user doesn't even know key combinations like Meta+e or Meta+l.
> Heck, I consider myself a well-knowing PC user and even I really don't see
> the point in the about million key combinations that KDE defines by default.
> Actually it's so many, that I really avoid them (to some degree), because
> chances are high you hit a wrong key and something awful happens.
> In my opinion (and this is only my personal opinion), about 80% of them
> should default to "None", but have a "suggested key combination" instead, a
> concept that doesn't exist currently (and also might not be wanted by
> others, don't know).
> 
> Anyway … you really can't expect people to know that left mouse button will
> move and e.g. Ctrl+LMB will copy.
> RMB drag, as I described in the first post, maybe, but even that is a
> concept that most users wouldn't incorporate into their workflow.
> 
> The current way is actually a pretty smart way to give a typical user a way
> to decide between copy and move without needing to remember key
> combinations. Hence it should be the default.
> 
> (In reply to Nate Graham from comment #41)
> > Someone submitted patches that implemented the requested change, but
> > ultimately abandoned them because we couldn't figure out a way to always
> > copy by default instead of moving when dragging across devices (for safety).
> 
> But why change the behavior in that case? IMO it's an inconsistency that
> shouldn't exist.
> If I would still want it to move by default, I would also want it to do that
> when I move files from one filesystem to another.
> (I think it's filesystems that matter here, not devices.)

I don't think the idea is to change the default, but to make it configurable so that you don't HAVE to do the prompt or a hotkey every time. Move is the default action on both widely used operating systems (Windows & MacOS), so I wouldn't say "you really can't expect people to know that left mouse button will move and e.g. Ctrl+LMB will copy." when that is the expected behavior in the vast majority of the consumer market.
The simple fact is that for adoptability, at very least, to be able to configure that as your Dolphin's behavior would help, this isn't an argument to change the default, but for the OPTION to CONFIGURE, which is generally speaking, a core feature in many of KDE's applications.

(In reply to Christopher from comment #49)
> Move is the
> default action on both widely used operating systems (Windows & MacOS), so I
> wouldn't say "you really can't expect people to know that left mouse button
> will move and e.g. Ctrl+LMB will copy." when that is the expected behavior
> in the vast majority of the consumer market.

We're not just talking about other operating systems, but also afaik all other mainstream Linux file managers: Drag&drop = Move, for everyone but Dolphin users. I used Nemo, Thunar and Nautilus and was never bothered by a context menu asking if I really wanted to move that file. So yes, please add at least an option to do that.

Akemi, every comment you post that expresses your opinion on this matter gets emailed to all 31 people on the CC list. Your opinion has now been registered, so I would ask you to please refrain from doing it any more. Message received.

(In reply to Nate Graham from comment #54)
> Akemi, every comment you post that expresses your opinion on this matter
> gets emailed to all 31 people on the CC list. Your opinion has now been
> registered, so I would ask you to please refrain from doing it any more.
> Message received.

Sorry, I would understand if you said that in the first comment. I apologize but it truly shocked me to see that something like this had been reported way before (message received as you said).

I apologize if this caused any discomfort and would like to know if there is any other way to help with this or how I can track the progress of this change (just coming back here?).

What *was* my first comment to you in this bug report's comment thread. :) Anyway, now that you're CCd, any messages posted to this bug report will be sent to you too--including notifications of ongoing work on it or when it's resolved. So you'll know once that happens.

Every big software project will have multi-generational issues, especially those that are predominately made by volunteers. It's just the nature of the beast. Helping out with technical contributions is always hugely appreciated. See https://community.kde.org/Get_Involved.

I had actually put this bug report on my "maybe work on it tonight" list. Reviving those patches doesn't look too hard (famous last words!), and maybe we can figure out a satisfactory solution to the concerns brought up in the first rounds of code review.

"Key modifiers and even alternate mouse buttons are for power users only."

Is that why windows, the OS  famous for catering to "power users", uses modifier keys?
And if there's one thing kde historically always shies away from, it is choice and power!

but seriously, there are better options out there than kde now, ones in which put user friendly design first rather than last.

*** Bug 468702 has been marked as a duplicate of this bug. ***

*** Bug 454356 has been marked as a duplicate of this bug. ***

I agree with this as well, this one is so important to me.
KDE Plasma is amazing, this is literally one of the only things I can find that I do not care for, makes it very difficult to use.
I am aware that you can use modifier keys to avoid them but for such a standard action should not really have to use a keyboard modifier to  perform a simple drag & drop action like moving a file.

Nothing wrong with having these context menus be the default for those who like them, but seems odd that KDE, a group known for endless customization / settings, does not have an option to be able to turn these off / allow users to choose how drag & drops perform.  I have never seen any other file managers use this approach with LMB D&D so with something that is far away from a standard, again seems odd not to be able to have a setting for something like this.
I have however seen in Windows as well as some FM in Linux the use of the RMB D&D for these context menus which I would prefer.  RMB makes more sense because a single click brings up context menu so D&D with RMB to bring up these CM would fit in better here.

I made a more in depth post about how this could possibly be handled here as well to hopefully get some more users to vote for this.
https://discuss.kde.org/t/plasma-dolphin-drag-drop-context-menus/1809

Do votes really mean anything? How many does an issue have to have in order to be worked on?
To me personally this is a pretty big deal, hopefully this could finally be addressed.

I've been planning to work on finishing up the earlier patches, but as with so many things, it's just so hard to carve out time with the 500,000 other things I have to do. I imagine most other people are in a similar situation, especially since this is really a nice-to-have, not even a bug.

It seems pretty intuitive that dragging and dropping is by default a move operation. It's nice to have the option to prompt beginners as to what they want to do, but it soon becomes a nuisance.

Ctrl+C and Ctrl+V are not 'poweruser' shortcuts, they are as commonly used as Ctrl+Z and Esc. If users want to copy a file then Ctrl+C and Ctrl+V are most likely used, not via the context menu. If you can copy/paste text, then the same applies to files. Initially you might learn to click the file, select copy, navigate to a different folder and select paste. However copy/pasting is used so often (throughout all programs) that it's one of the first shortcut keys you learn, same applies to undo (no one goes through the context menu for it once they learn the shortcut). 

Windows allows the user to alter the outcome of the drag and drop during the operation. If you want to copy or create a link then there are modifier keys that can be held down. Using the modifier keys, there is visual feedback like a '+' sign or 'arrow' added to the mouse cursor, but if no modifier key is pressed then it defaults to move.

I like the idea of having an option for this. IMHO that should behave the way Windows and many other file managers do that. Defaulting to copy is great. I would't like a different behavior for each mouse button

*** Bug 474704 has been marked as a duplicate of this bug. ***

I hope that they will do this in the near future. I really miss the ability to navigate without a context menu.

This bug has been open since 2007 and its still being discussed?  This bug is old enough to get married and buy beer and cigarettes in some countries.  The dialog behavior is  literally the most Gnome like thing about KDE: you can't change it, you can't configure it, it and its weird when compared to every other desktop system out there and it limits functionality. That pretty much sums up my experience with Gnome, and why I use KDE!  (Not to knock Gnome, it's a fine DE for some people).  The most basic thing, that every single user interacts with every single day is, in my opinion and the opinion of many of the people above and in all the duplicate bugs, is broke.  Plasma 6 is coming soon, wouldn't be nice to finally offer a choice to make file copy/move on a par with every other desktop system. Further, you already have the shortcut keys labeled in the dialog, you just ignore the user's input and open the dialog anyway. At this point given the non-operational keyboard shortcuts, in my opinion this has gone from a feature request to a bug. Shortcuts don't work - this is a bug! Please prioritize and close this bug before it can buy liquor in America. :-)

+1 for prioritize it :D

So, the relevant bits are in:
KItemListController::dropEvent https://invent.kde.org/system/dolphin/-/tree/master/src/kitemviews?ref_type=heads#L846
which on line 866 invokes 
Q_EMIT itemDropEvent(receivingWidget->index(), event);
handled in DolphinView::slotItemDropEvent https://invent.kde.org/system/dolphin/-/blob/master/src/views/dolphinview.cpp?ref_type=heads#L1321
which calls DolphinView::dropUrls https://invent.kde.org/system/dolphin/-/blob/master/src/views/dolphinview.cpp?ref_type=heads#L1341
which calls DragAndDropHelper::dropUrls https://invent.kde.org/system/dolphin/-/blob/master/src/views/draganddrophelper.cpp?ref_type=heads#L37
which calls KIO::drop https://invent.kde.org/frameworks/kio/-/blob/master/src/widgets/dropjob.cpp#L641
which ends up calling DropJobPrivate::slotStart() https://invent.kde.org/frameworks/kio/-/blob/master/src/widgets/dropjob.cpp#L240
which then calls DropJobPrivate::handleCopyToDirectory() https://invent.kde.org/frameworks/kio/-/blob/master/src/widgets/dropjob.cpp#L414
for the actual work.
Thanks @Rob D for the old analysis.

Don't know how to implement the thing, totally lost in the code, if someone wants to take a look, please do! I'm all for prioritizing it and make it into Plasma 6!
@Nate this should help a bit, hopefully.

Sidenote: also please note that the DBus call to pass the zip extraction to Ark is done in both DragAndDropHelper::dropUrls and in DropJobPrivate::slotStart(), I think that's duplicate code

My proposal is for something like this, but again hard for me to implement 
https://bugs.kde.org/show_bug.cgi?id=474704
Basically two drop zones, one for copy marked "Copy" and one for paste maked "Paste", instead of the menu. Then of course a config option to avoid all this and just copy the files, without further notice.

Thank you for the deep dive svlmrc. You have inspired me to sync the code and look at it; but, I probably can't provide much value add (python programmer). I will continue to advocate for this bug and appreciate you looking at it. How can I help? I certainly could test any alpha code if needed.

*** Bug 480269 has been marked as a duplicate of this bug. ***

Guys, i don't know if it is just me but it looks like the bug is solved on FreeBSD.

I'm really wondering. Why are we even discussing it after so many years? Is it so hard to offer a configuration choice? Is this not the KDE way? It is VERY impressive that of all things in KDE, this is the most prominently unconfigurable. Just give users a choice, and be done with it. I'm not a coder, but I can't believe it is that hard to implement.

PS: Ι love you david.scott.brown@gmail.com :)

Ive been following this bug report for almost 4 years now, in fact I made an account just for this comment. This usability feature is the one thing that has kept me on gnome this whole time. I am not advocating for changing the default, but if this option gets added I would switch to using KDE. Maybe if I voice my opinion after all this time, there will be enough “user demand” for it.

(In reply to Christian from comment #73)
> Ive been following this bug report for almost 4 years now, in fact I made an
> account just for this comment. This usability feature is the one thing that
> has kept me on gnome this whole time. I am not advocating for changing the
> default, but if this option gets added I would switch to using KDE. Maybe if
> I voice my opinion after all this time, there will be enough “user demand”
> for it.

I venture to say it's probably a good time to bring this back up, as well, since the blocker seemed to primarily exist in the previous framework, and now having Kirigami as standard as far as I understand should help simplify matters.

My 2c: I would prefer to have no drag functionality at all. I only use this feature accidentally, and the context menu is a saving grace. That may have something to do with my physical dexterity.

So if this is changed, we really need the option to configure it. I'd appreciate a "disable dragging" option.