Since Dan challenged my assertion that having a separate Action for “Rename” would be more user friendly, or easier, I’ll present my case for why I think it is:
Having a separate Action for Rename is better, more user-friendly, because:
Removes Initial Confusion
When I see an Action with “Move or Rename”, my first thought is “how do I specify “rename”, when I do NOT want to move the file/folder?”
So this slows me down immediately, as I have to stop and examine the Action options to make sure I’ve got the right settings
.
A separate Action for “Rename” is more intuitive and consistent with the Finder UI
There is a “rename” item in the context menu
There is NO Finder menu item for “move”
.
There is less opportunity for user error
Since I would not have to repeat the path in the new name block, I don’t have to worry about typos or other errors causing a move when I only want to rename
It is less work to just provide the new name, whether by typing, or by using KM variables, since if I have to provide the full path, then I have to type, or use a KM variable, for the parent path, and then a separate Variable (or text) for the new name
I don’t have a good argument against, other than it just doesn’t feel right. I’ve learned to listen when I feel this way. However, I don’t expect you to agree with me if I can’t state a good response to your argument, and your argument is well presented.
(Of course, it only really matters what Peter thinks, right?)
But I'm sure that Peter wants what is best for his users. That, of course, is subject to debate.
FWIW, this does not matter to me personally, since I have never used the "Move or Rename" action, and don't see any use for it in the near future. I'm only trying to present what, IMO, would be best for the average, non-programmer, Keyboard Maestro user.
IMO, there are much larger fish to fry in the KM wish list.
Thanks I figured it was something less apparent on the surface.
Very nice post I agree with all your points and to me is a reminder and dilemma I deal with often which is why in the music industry we have producers to help the band step out of themselves and how cool that time signature change was or something that has some deeper meaning but on the surface just doesn't bode well.
That's because you program and get down to that level more often, so I guess it boils down to what is the person you are trying to serve and would making things more clear with less worry to those that don't know what it is in the terminal mess up those that do. You can never argue with feelings they just are and don't have to be explained, it's complicated being a human ;).
Thanks for that info, Peter. It is helpful.
Unfortunately, this info is not in the Wiki. I will try to update the Wiki in the next few days with something like this:
Although the Mac Finder presents it as separate actions, Keyboard Maestro views "Move" and "Rename" as the same action, so the KM Action "Move or Rename" can do all of the following:
Rename a file, leaving it in the same folder
• In this case, you can enter either in the "to" field:
• ONLY the new file name without the parent path
OR
• The new file name with full parent path
Move a file to a different folder, but keeping the same name
Move a file to a different folder, AND change the name
Note: The source path must be an absolute path (or a path relative to home ~). The destination path must either be a simple single path component (no ~ or /) or an absolute path. If it is a simple path component, then it is relative to the parent directory of the source path. This is particularly useful in the Move or Rename action, as you can, for example, rename from ~/Folder/Old Name to New Name.
And it applies equally to Copy, which can copy to a new location with the same name, the same location with a different name, or a new location with a new name.
Great update, still seems wise to me to make them separate even if they are the same under the hood. I think JmichaelTX had some pretty sound logic.
Thank you both for constantly making the Wiki so much better, Michael I have read so many posts that have helped me where you have updated it to help clarify the verbiage a bit more with pictures to boot. Thanks for being so conscientious of that and always referencing it, it is very helpful. As clueless as I may seem at times I have been able to work through many things thanks to you (and Peter’s approval and clarifications of course)!
I agree with having separate commands with less clinical path requirements to make building this more logical. I’m just trying to do a simple “move” to another dir on another drive. No Joy.
In the earlier version of KBM it was easy to do things, that’s why updated. I wasn’t expecting this. If I wanted to have to learn programming, I’d have not bought KBM. The earlier versions were far more useful. I don’t do much more that I really need anymore.
Thanks for your reply. I don't remember which version, but I was with you since the very early days and I became addicted to KBM due to its logical ease of use. I quit using KBM when it went so "codingly". Only upgraded because there were a couple control commands that I needed that were somewhat easy, although they would not transfer form a previous version and had to be recreated, you had to troubleshoot with me and we discovered the OS has also "evolved" to be more complicated. Anyway . . . .
I want to do is move a selected file to a predesignated location. One that is proving to be problematic and that is paths. I use the paths that the app put in when I selected the destination. Also why have a origin? Please see screen grab.
That’s the problem, it’s no specific file until after it or they are selected. The action needs to act on whatever file(s) happens to be selected. The origin is not the Desktop, that’s just something I put in there to trouble shoot when I took the shot. Logically I would leave that empty. Although the origin will mostly be a “file” on the"Desktop" to be moved to a specific folder.
