Version: 2.0 (using KDE 4.8.0) OS: Linux Dolphin should give better feedback when an attempted file operation is not possible, due to insufficient permissions, a read-only filesystem, etc. Currently it just does nothing at all, without explanation, which is very confusing from a user's point of view and makes the software appear broken. Reproducible: Always Steps to Reproduce: 1. Open Dolphin, navigate to a read-only filesystem or one where the user has no write permissions 2. Attempt the following: a. Create new folder via shortcut key (F10) b. Copy a file or folder by drag & drop Actual Results: For 2a, a New Folder dialog appears, but nothing happens when OK is clicked. For 2b, the mouse cursor shows the copy pointer, but nothing happens when button is released. Expected Results: For 2a, no dialog should appear. For 2b, the mouse cursor should change to a disallowed pointer. Preferably, there should also be a message somewhere indicating why, e.g., lack of permissions.
Now I just realized that Dolphin *does* display a message in the status bar. But I don't think that's visible enough, given that it was some time before I even noticed it. :-)
Thanks for the report, but now there are 3 issues mentioned in one report: 1. Creating a new folder is disabled in 4.8.1 if no write access is possible (2a). 2. Showing a "disallowed pointer" for drag & drop is discussable: The user gets no hint why the dropping is not allowed, so I'd prefer showing a message instead why the dropping has failed (some fixes for 4.8.1 have also been done here). But I'm open for suggestions (probably such a hint could be shown during dragging too). 3. The error not showing in the statusbar is something that originally was planned for 4.8.0 to get improved but it got postponed. Which of point 2. or 3. should be handled in the scope of this report?
You're right; that is a bit of a tricky point. The classic way has been of course to pop up a message dialog upon drop, but I believe recent trends in usability/UI design want to move away from this. That would probably eliminate the disallowed cursor as a good option since I think having a dialog pop up when a drag is released with a disallowed pointer would go against user UI expectations. I definitely agree with showing the reason for the disallowed operation somehow. Frustrating cases where widgets or menu items (in most of today's GUI systems in general) are grayed out when the reason is not always obvious to me come to mind. Displaying the reason in the status bar along with the "disallowed" pointer is an option, though I guess that contradicts what I said in Comment #1. Would it violate UI guidelines to show a tooltip during the grab? That is, show the disallowed pointer, but when hovering over a target for a brief period have the reason appear in a tooltip. This would still give feedback during the drag operation instead of after, which is good, and the reason would be hard to overlook since it would be right next to the mouse pointer.
Instead of showing error-messages in the statusbar I currently plan to use the following widget: http://agateau.wordpress.com/2011/04/21/kde-ux-2011/ In opposite to a message-box it does not block the user and I'd say it is a lot better recognizable than the error in the statusbar. > Would it violate UI guidelines to show a tooltip during the grab? Hm, it is not only the question how to display the information but also how fast this information can be retrieved during the drag-operation. There are cases where showing a "cannot drop" sign are straight forward (e.g. for widgets that simply don't support dropping) but in this case file-permissions must be checked during the dragging. I'd need to check first whether this is doable fast enough... But I'll first try the status-bar replacement and let us check how it feels then before investigating into the "show tooltip/text during drop" case :-)
> Hm, it is not only the question how to display the information but also how > fast this information can be retrieved during the drag-operation. There are > cases where showing a "cannot drop" sign are straight forward (e.g. for widgets > that simply don't support dropping) but in this case file-permissions must be > checked during the dragging. I'd need to check first whether this is doable > fast enough... That's a good point. That could be a major problem if the user is operating on really slow filesystems (network over a slow connection, floppies, some removable drives), or even if a HDD wakes up (that could cause a delay of several seconds!). That makes me think the disallowed pointer isn't such a good idea after all. The widget you mention looks like the solution. Plus this would maybe allow Dolphin to just try the operation and catch errors instead of trying to guess whether the operation is possible ahead of time (which can cause problems like https://bugs.kde.org/show_bug.cgi?id=111807#c4 ).
Resetting assignee to default as per bug #305719
Many things have changed in Dolphin since this bug was last discussed, and it was never quite clear what the exact issue that this bug is tracking is. Does your report still apply to Dolphin 4.11 or later? If yes, please describe what you consider problematic. Thanks!
In 4.11.4, using F10 to create a folder where permissions are lacking now produces a red box near the top of the window that I consider sufficiently visible, so this part is good now. (Though in these conditions, the new folder menu item as well as the menu items and key shortcuts for rename, move to trash, etc. operations are disabled, unlike the F10 shortcut—I'm not sure if this is intended, though it seems inconsistent.) Drag and drop when an error in permissions occurs (e.g., trying to drag around top-level directories in / as a normal user), though, still produces only an error message in the status bar which isn't very obvious. I would suggest using the same red-box-type message to report those.
Thanks for the quick reply! Disabling the "Create Folder..." action if the current URL is not writable is probably quite straightforward. I'll look into it. (In reply to comment #8) > Drag and drop when an error in permissions occurs (e.g., trying to drag > around top-level directories in / as a normal user), though, still produces > only an error message in the status bar which isn't very obvious. I would > suggest using the same red-box-type message to report those. Unfortunately, this solution would cause other problems. Actually, we did show the red box for drag&drop errors at some point, but then we got complaints from quite a few users because it's very easy to trigger such an error accidentally. Clicking a folder to open it, and then moving the mouse slightly between "button press" and "button release" is enough to trigger a "Folder cannot be dropped on itself" error, and many users considered the error message in the red box much too intrusive for such a case.
(In reply to comment #9) > Unfortunately, this solution would cause other problems. Actually, we did > show the red box for drag&drop errors at some point, but then we got > complaints from quite a few users because it's very easy to trigger such an > error accidentally. Clicking a folder to open it, and then moving the mouse > slightly between "button press" and "button release" is enough to trigger a > "Folder cannot be dropped on itself" error, and many users considered the > error message in the red box much too intrusive for such a case. That makes sense for accidentally dropping something on itself. But would it be as likely to accidentally drag something to a different folder due to the greater distance? Strangely, though, it seems that this issue doesn't really bug me anymore as it did when I first filed it, I guess because I have since become familiar with Dolphin's behavior. So I'll leave it up to you. :-)
(In reply to comment #10) > That makes sense for accidentally dropping something on itself. But would it > be as likely to accidentally drag something to a different folder due to the > greater distance? You are right, but the problem is that all error messages that happen after a drag&drop operation currently take the same code path. Changing this, in order to show different drag&drop errors in different ways, is not trivial and will make the code harder to maintain and more bug-prone. Therefore, I'm not sure if this issue is important enough to justify such a change.
> Disabling the "Create Folder..." action if the current URL is not writable > is probably quite straightforward. I'll look into it. A proposed fix is at https://git.reviewboard.kde.org/r/114560/
Git commit 67bb99c5ded73f9f25882a1e0c3035aa3b3a3f24 by Frank Reininghaus. Committed on 29/12/2013 at 08:23. Pushed by freininghaus into branch 'KDE/4.12'. Disable the "Create folder" action in read-only directories The action can be triggered, e.g., by pressing F10. FIXED-IN: 4.12.1 REVIEW: 114560 M +8 -0 dolphin/src/views/dolphinviewactionhandler.cpp M +5 -0 dolphin/src/views/dolphinviewactionhandler.h http://commits.kde.org/kde-baseapps/67bb99c5ded73f9f25882a1e0c3035aa3b3a3f24