Version: (using KDE KDE 3.1.4) Installed from: Compiled From Sources The `move to' and `copy to' options on the right-click menu of a file have similar submenus. I suggest the merger of both into a `move or copy to' option, with the same submenu system, that would then present the three options "move here", "copy here" and "cancel" at the top of each further submenu. The move or copy here option should then be shaded if inappropriate. This change would have three advantages: fewer menu items in the right-click file menu it would be possible for a user to change plan about move/copy at any time, without going through a possibly long set of directories all over again; this need happens to me sometimes, and perhaps other users are similarly prone to changed ideas... the final stage is very similar to the options given in konqueror and kmail when using drag and drop on files/emails, so this system makes kde very self-consistent
I push this point again: continued use makes me see how much it would improve the interface. This additional comment is to suggest that a symlink option should also be provided in the final copy/move/link stage. Please, anyone, comment on possible problems with the suggested merger! Are you worried that the necessary wording in the right-click menu would be too long? ( "Copy/Move/Link to ... " ).
Good thought! The advantage of 3-in-1 submenu is sure too many. "Copy, Move, or Link to ->" is not too long, doesn't look bad.
the right-click menu of a directory has the submenu <Actions> with the Encrypt folder item. Why not make such an actions submenu for files too and put the copy, move, encrypt file, ... together. I think encrypt is not a daily action and for move, copy it dosen't mater if you have to go through an additional submenu.
Created attachment 24168 [details] Screenshot of the merged move/copy (partial) There are three point to solve: 1) find a good way to call the merged menu. 2) find a good way to select the move/copy/link action on the "recent" destination folder 3) find a good way to select the move/copy/link action from the "browse" action. I don't like the idea to have a merged menu without a solution for this three points.
Re:#3, I suppose this is where our different use habits show up; for me, it would be preferable to have the Copy/Move/Link option in the first level of the right-click menu; it's used often as a shortcut, often to a "recent" place, so reducing the number of clicks is desirable. Re:#4, 1) as above, I would certainly claim an item in the right-click menu to be the way to call 2) I don't think I'd considered this problem, of how to select the right action on the (very useful) "recent" list. i] Perhaps include the "recent" entries as now, but with a parenthesised action after the directory name, e.g. /tmp/d (copy) /home/aa (move) /tmp/d (move) ii] Or, as suggested in the attachment to #4, have a submenu for each "recent" destination. Of these, my use would find i] preferable, since it preserves the useful small number of clicks for frequent actions. I do this a lot more than choosing new directories. 3) The only easy way I see to get round the browse problem is that after selecting the directory there should either be "Copy" "Move" "Link" buttons instead of just "OK", or that there should be a following pop-up that gives these options, just as the "are you sure you want to overwrite this file" box comes up now. When I look again, 4 years later, at the initial wish, I don't feel /as/ strongly the importance of combined Move|Copy (though it does seem rather neater) but I would find a Link option good too (and perhaps that would then be too many separate right-click-menu items). Point 3) about the "Browse" option seems the most troublesome, but I don't think either of the solutions (extra buttons, pop-up) is really bad. What do you all think? FiNeX: thanks for the work; do you actually support the idea as a potential improvement, or are you just helping to see what could be done about this wish?
Well, about the point 2, I'd like to remember only the recent path, not even the recent action associated to that path. About the third point ("browse" option) I've to say I've never used it, so it is a minor point. I'm only trying to analyze the problem. I'm sure that adding a "link to" submenu which works as the actual copy/move is not a great idea. Too much similar actions/menus are not very usable. Rather than adding a new submenu or the tre actions for each destination, I'd like to have only an action ("Copy/move/link to"). On each destination it could be added a small "toolbar" with the three actions instead of another submenu. Another option is to remove the actions from the destination submenu and use a dialog box for asking to the user what action use. What do you think about?
Yes, that sounds neat: a single menu item copy/move/link, then a choice of action when at the destination. The only disadvantage of not remembering actions as well as recent destinations is the increased number of clicks needed. I initially prefer the 'toolbar' rather than dialog box, as being less disturbing, but the main question then would be how the options should be arranged. Currently (3.5.8) there is a single entry at the top of each directory list, showing the "Copy" or "Move", greyed out if not possible; should it become three such lines for the three actions, or three side-by-side icons, or ...
@Peter: I've added you on CC because you could be interested on this bug report. Could this report be valid for dolphin too?
@FiNEX: I'm not using the Copy To/Move To submenus myself, so it is difficult for me to judge whether the requested behavior is better than the current behavior. I'd leave it up to David to decide (the copy to/move to code is maintained in the konq-libs, not in Dolphin). For me it is questionable how such a merged menu should be called (as you mentioned already in comment #4), which makes me doubt whether the new approach is more clear than the current approach.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!