drag a file from an FTP to a folder where I do not have write permissions. Result: shows a green +. Does not do anything on drop. Should not show the + or it should indicate that it cannot act. Reproducible: Always
Hello, thanks for the bug report! I can't reproduce it in Dolphin 4.10.95 Can you please give us some infos about your Dolphin settings (View Mode, ...) and maybe provide a screenshot if possible? - That would be great :)
I can reproduce on today's master. Trying to drop anything to / (root) as a user, does not show the "forbidden" drop cursor. Both for dropping into a visible view, as well as dropping on the Root place in the places panel.
Thanks for your feedback. > does not show the "forbidden" drop cursor Hmm okay, but that is another bug I think, because this bug report is about a green +. > I can reproduce on today's master. I can't see a green selection toggle (+) when I drag/drop items onto non-writable items, can you?
I drag from an FTP-server to a local disk, maybe that is the difference.
The green "+" (selection toggle) appears when you drag to another Dolphin window. From void KItemListWidget::setHovered(bool hovered): if (m_enabledSelectionToggle && !(QApplication::mouseButtons() & Qt::LeftButton)) { initializeSelectionToggle(); } So it seems that QApplication::mouseButtons() returns an incorrect value in the application that something is dragged to. A Qt bug in my opinion. We had the very same problem some time ago with the keyboard modifiers (bug 178679), fixed by dfaure in Qt. About the "no drop forbidden cursor": to my knowledge, Dolphin has never shown "drop forbidden" cursors anywhere. There was even a good reason for that, I think, but I'm not quite sure at the moment. I'm not entirely sure if there is some report about that already.
> drag to another Dolphin window. Ok when I drag it to another Dolphin window I can reproduce it too, but it works in split view mode.
Oh, I use a non-standard cursor theme, and had the impression the default copy cursor included a green + (mine has a black +) Sorry for the confusion :)
Another symptom of the incorrect value returned by QApplication::mouseButtons() is bug 271325. We should write a simple test case and submit a Qt bug report.
Reported to Qt: https://bugreports.qt-project.org/browse/QTBUG-33161
Apparently the behavior of QApplication::mouseButtons() is intentional. Therefore, we could only fix this by using something different to find the current state of the mouse buttons. I am not planning to do this (I don't even know if there is a good cross-platform way to do that), so the correct resolution is WONTFIX. Sorry about that.