Bug 164188 - The Cut menu item is available on files or file groups that have been cut already
Summary: The Cut menu item is available on files or file groups that have been cut alr...
Status: RESOLVED INTENTIONAL
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 2.1
Platform: Chakra Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-15 23:04 UTC by Maciej Pilichowski
Modified: 2012-11-29 21:27 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Pilichowski 2008-06-15 23:04:37 UTC
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.
Comment 1 FiNeX 2008-06-16 09:39:40 UTC
Do you see "cut" more than one time? could you reproduce even in dolphin or only in konqueror?
Comment 2 A. Spehr 2008-06-16 11:58:48 UTC
Under Konq, r821020, I can't use RMB--->"cut" to delete a folder or a file.
Oh nice... OR in dolphin.
Comment 3 Peter Penz 2008-06-16 12:03:07 UTC
> 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.
Comment 4 A. Spehr 2008-06-16 12:09:54 UTC
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...)
Comment 5 Frank Reininghaus 2009-06-10 17:31:49 UTC
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.
Comment 6 Maciej Pilichowski 2009-06-10 18:00:38 UTC
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).
Comment 7 Frank Reininghaus 2009-06-10 18:13:33 UTC
(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.
Comment 8 Maciej Pilichowski 2009-06-10 20:57:48 UTC
> > 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.
Comment 9 Frank Reininghaus 2009-06-11 14:45:20 UTC
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.
Comment 10 Maciej Pilichowski 2009-06-11 19:08:11 UTC
> 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.
Comment 11 Peter Penz 2009-06-11 22:36:25 UTC
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.
Comment 12 Frank Reininghaus 2009-06-11 23:42:15 UTC
(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.
Comment 13 Maciej Pilichowski 2009-06-12 08:17:19 UTC
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.
Comment 14 FiNeX 2009-12-05 17:40:15 UTC
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 :-)
Comment 15 Mark 2010-09-19 03:06:28 UTC
Hi,

Please confirm that this issue is still present in that latest stable KDE version.

Thanx,
Mark
Comment 16 Peter Penz 2010-09-23 10:32:21 UTC
@Mark: The issue is still valid. What should be fixed at least is explained in comment #11.
Comment 17 Jeroen van Meeuwen (Kolab Systems) 2012-08-24 16:21:37 UTC
Resetting assignee to default as per bug #305719
Comment 18 Frank Reininghaus 2012-11-29 21:27:41 UTC
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.