Version: (using KDE 4.0.82) Installed from: KDE4Daily file mode: multiple cuts are allowed RMB on a file -> cut -> cut -> cut -> cut -> cut and so on.
Do you see "cut" more than one time? could you reproduce even in dolphin or only in konqueror?
Under Konq, r821020, I can't use RMB--->"cut" to delete a folder or a file. Oh nice... OR in dolphin.
> Under Konq, r821020, I can't use RMB--->"cut" to delete > a folder or a file. Oh nice... OR in dolphin. Do you have write access for this file? In Dolphin the "Cut" action of the context menu is greyed out if not write access is given. In Konqueror no "Cut" action is shown at all in the context menu if no write access for this file is given.
I do. I even changed it to watch it grey out. :) And I was given the "cut" option in konq. (And obviously I can't delete it when I've set it to -w but I couldn't before anyway...)
The problem in the original report is unclear to me, and I can't reproduce comment 2. Can any of these issues still be reproduced, or can we close this report? Thanks.
Frank, issue is still present. Here we also touch the discussed issue (other report) -- how reusing the same term in various contexts affects UI. Not only file after first cut is still present (unlike other data), but also several cuts are possible (which should not, by definition).
(In reply to comment #6) > Not only file after first cut is still present (unlike other data) But how would you suggest to change that? Should the file be removed or moved to some temporary location after the cut operation? And what should then happen if the "paste" fails? Should the file be gone? I think this would annoy quite a few people (including myself). > several cuts are possible (which should not, by definition). I still fail to understand what you mean. Do you mean that the "Cut" action should be disabled after the first "Cut" and only be re-enabled after doing "paste"? I think this would also annoy many people (including myself): if you realised that you've cut the wrong file, you could not cut another one because the cut action was disabled. I haven't checked other file managers, but I seriously doubt that any FM handles "Cut" in this way.
> > Not only file after first cut is still present (unlike other > > data) > > But how would you suggest to change that? Still my #1 suggestion would be stop reusing terms in various context. In this case dropping terms cut, paste, copy, because in all contexts except files they mean something different and act differently. > Should the file be > removed or moved to some temporary location after the cut > operation? Yes. Not because I like it, but because making it 100% consistent (cut should mean cut). File-clipboard (location). Or making it really, really gray out and dotted out (currently it is so gently touched, that is hard to tell the difference). > And what should then happen if the "paste" fails? What if there is no paste? Nothing. Files remains in the file clipboard. > Should > the file be gone? I think this would annoy quite a few people > (including myself). Me too. I don't like it, I prefer renaming those actions. But if was already rejected, and cut must be used it would be better to provide uniform feeling. "Cut" should _always_ mean the same. Otherwise user will be always surprised -- I cut in A, it worked, I cut now, why this file is still there? The above thoughts are slightly off-topic, so please don't close this report as wontfix jugding on those :-) Back to the problem of this report: ------------------------------------------ > > several cuts are possible (which should not, by definition). > > I still fail to understand what you mean. Do you mean that the > "Cut" action should be disabled after the first "Cut" and only be > re-enabled after doing "paste"? No, not only. Also when cut or copy another file, or copy this file. Another would be moving the file (see above) then the problem is gone by definition (off-topic). > if you realised that you've cut the > wrong file, you could not cut another one because the cut action > was disabled. Cut action for _this_ file of course, not cut in general. The same as with text, or with image. You cannot cut something that is already cut. A: RMB, cut enabled -> cut A: RMB, cut disabled B: RMB, cut enabled -> copy A: RMB, cut enabled Btw. modifying graying out cut files would be great addition of course.
While your suggestions may make sense from a "I want everything 100% consistent" point of view, I don't think they would improve the Dolphin/Konqueror user experience. (In reply to comment #8) > Otherwise user will be always surprised -- I cut in A, it worked, I cut now, > why this file is still there? I haven't seen any other reports about this, so you seem to be the only one who is surprised here. I'm pretty sure that changing either the names of the actions or their behaviour (and thus making file management in KDE inconsistent with any other file manager) would surprise the average user a lot more and would result in lots of bug reports demanding the changes to be reverted. IMHO, "WONTFIX" is indeed the right resolution here, but it's up to the maintainers to decide that. The alternative would be to make this report a wish and change the summary to "Change the names of the Cut/Copy/Paste actions", but I don't really see the point in doing that.
> I haven't seen any other reports about this Blame lazy/intimidated users, not me. > I'm pretty sure that changing > either the names of the actions or their behaviour (and thus making > file management in KDE inconsistent with any other file manager) > would surprise the average user a lot more and would result in lots > of bug reports demanding the changes to be reverted. Did I write "off-topic" or not? I did. So please stick to _this_ report. You asked, I answered -- but those were off-topic. > The alternative would be to make > this report a wish and change the summary to "Change the names of > the Cut/Copy/Paste actions", but I don't really see the point in > doing that. The alternate would be reading _this_ report: a) disabling sequential cuts for the same file (bug) b) providing visual feedback on "cut" (graying out + dotting out icon), like every cut in whole KDE (wish) ad.b) it would be really helpful -- how user can tell anything happened if there is no hint something happened? Keeping cut enabled only assures user that previous cut was unsuccessful.
I agree that the 'cut' action should be disabled if the selected item has already been cut. If more than one item has been selected, the 'cut' action should only be disabled if all selected items have been cut already -> I'll handle this report as bug to fix this usecase.
(In reply to comment #10) > Did I write "off-topic" or not? I did. So please stick to _this_ report. You > asked, I answered -- but those were off-topic. Sorry for missing your point and mixing off-topic and on-topic issues here. > b) providing visual feedback on "cut" (graying out + dotting out icon), like > every cut in whole KDE (wish) For me, icons of cut items are grayed out in KDE 4.2.4 and current trunk.
Peter, thank you. Frank, to keep report:issue ratio 1:1, I opened another report for the icon: https://bugs.kde.org/show_bug.cgi?id=196132 it is grayed out for me too, but it is too subtle.
I want to add only one consideration: actually if the folder is read only, the "cut" action is disabled. How an user could understand if it is disabled because he cannot cut (read only) or it has already been cutted? Having a "strong (look at bug #196132) visual indication could be the only way to inform the user why "cut" is disabled.... well, moreover the status bar message is helpful too :-)
Hi, Please confirm that this issue is still present in that latest stable KDE version. Thanx, Mark
@Mark: The issue is still valid. What should be fixed at least is explained in comment #11.
Resetting assignee to default as per bug #305719
Well, as I said already 3 1/2 years ago, I see no point in "fixing" this. IMHO, people have wasted way too much time reading and trying to understand this report, which isn't ever going to be "fixed" anyway, so I'll close this now. It's up to future maintainers of Dolphin to reconsider this issue.