In case anyone is interested, here is the altered code, lines 533 to 537 of the local DigitalClock.qml file:
if (main.showDate) {
if (main.tooSmall) {
dateLabelLeft.text = Qt.formatDate(main.currentTime, **"ddd d MMM"**);
} else {
dateLabel.text = Qt.formatDate(main.currentTime, **"ddd d MMM"**);
The important thing concerns pressing the shift key while over the target window. I tried it again, and the first couple of times it didn’t leave a copy, but then it did several times in a row. I pressed F5 to refresh both windows after the first couple of times it worked correctly. It’s failing almost consistently for me, now.
Maybe it’s after the motion of dragging stops, press the shift key and release the mouse. In fact, I think that’s the issue?
It seems so. In one dolphin instance with dual panels it works right, but from one instance to another, if I don’t move the mouse after pressing shift, it copies the file, although not always. I think the times it works is because the mouse indeed move a very bit that might be imperceptible. Or it’s an event timing issue, who knows?
You may want to report a bug on this, thou.
This would be a KDE issue and so a bug report needs to be filed with KDE?
Not sure, but I’d guess openSUSE bugzilla first, if it is an upstream issue they’ll tell you.
By the way, I had a complaint about the digital clock, too. The old one allowed you to scroll the mouse to change the months. Can that be done in one of the qml files, too?
No idea, but it seems like a good side issue to include in your bug report. This functionality, as well as scroll over date to change date info (date or date+location) and different hour and data fonts have been lost somewhere between oS 12.3 and 42.3, apparently.
I could well be wrong, but I thought that the “correct” sequence, (as Shift / Ctrl are being used as modifiers,) was, taking move as an example:
Shift, then instigate drag and drop, release Shift. That certainly was the sequence I used when I tried to replicate the issue.
Normally, you would not press Shift until after clicking the file. Consider if a file is already highlighted in the list and you want to move another. If you press Shift prior to clicking the other file, you will highlight all the files between the two.
But… Should the file be moved or copied based upon the user properly holding the shift in proper sequence prior to finish movement?
Very good point… hadn’t considered that.
But… Should the file be moved or copied based upon the user properly holding the shift in proper sequence prior to finish movement?
Hmmm… :\
Probably time for a bug report?
You could file one against Dolphin:General Log in to KDE Bugtracking System but I think it actually needs to be filed against one of the kio components. No doubt it would get moved to the correct place though.
I filed one at https://bugzilla.opensuse.org/show_bug.cgi?id=1061926
Will that work and be moved to where it needs to or do I need to create a KDE account and post it there?
Some general thoughts on presenting problems.
I find the general idea of how problems don’t seem to be valid, and then they are, doesn’t get lost on anyone. It appeared SJLPHI appeared to be the only one with the issue regarding the Shift+drag. Other people tried “the same steps” and found no problem. It looked like he was the only one with the issue. I had been having the issue and finally searched for it and this was the only instance I found. So now there were two of us, but still others tried the same steps with no issue.
However, “the same steps” were found out to be different. While there are cases of someone posting things like, “My computer isn’t working right. Please help”. one can’t blame SJLPHI for not posting the exact steps. He didn’t really realize what they were. Neither did I, and the issue only appeared some of the time. It was only after I persisted in trying it over and over did I stumble upon the correct steps.
I usually use separate instances of dolphin rather than dual panels. I presume SJLPHI does, too. However, there are others who use dual panels. We each presume and assume.
For me, I am very careful about dragging files as I have accidentally released files into the wrong directory, then have to search for where they went to. This happens when you release the mouse button while still moving the mouse and it happens to slide up or down a directory. So I got in the habit of not release the mouse button, whether directory or not, until making sure I stop moving. It transformed into an easy habit of not pressing the shift until right before releasing the button.
So what I’m saying is, my past experiences causes me to actually do things differently than others without those experiences. (Which, of course, isn’t saying anything dramatic). But we may not realize we do them differently, we say we click and drag the files, but actually are doing it differently. One cannot blame anyone for not saying it explicitly, because we do not realize what we are actually doing. It was only after quite a bit before we find out some are holding the shift to start with, others at the end, and maybe others in the middle.
Not that knowing this makes things easier when there seems to be conflicting reports in the future. But maybe we can consider if everything is as the same, even if it appears to be a simple straightforward step.
For what it is worth just tried both ways her 42.2 hold shift from first click to frag and release also start drag and press shift just before release. Both worked. U usually just drag and drop and answer the question move or copy.