AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
TotalFinder 10.10.511/30/2023 In 10.11 they changed it so after you commit the folder name it has a cute animation of the folder moving and it usually scrolls the list view to leave the new folder visible, which also has the effect of messing up quick file/folder renaming. But if you have the status bar visible the folder would always be hidden under that bar so after every new folder I make I have to scroll a little bit to unhide it. I presume this is a result of changing the behavior of how the new folder is displayed after you create it, since before 10.11 when you changed the name and hit enter, the folder would move to its alphabetical place (assuming you are using list view with status bar visible) and attempt to scroll the window to keep the new folder visible. #1 started happening in 10.11, before then it worked like you and I wanted. Go back deep down the folder hierarchy, and the Finder stops reacting / accepting the drop again. What makes me certain it's the deep nesting that caused the Finder to go limp? Just keep going up the folder hierarchy, until magically one of the upper level folders start taking the dragged images (immediate clue is the Finder highlighting the inner boundary of the open folder). In the latter case, it's not a mistake of the user missing the target folder and dropping onto the desktop in the background. There're two potential outcomes: EITHER (in most cases) nothing happens, as in the Finder not even highlighting the inner boundary of the open Finder folder in response to drag-n-drop action like it's supposed to under normal circumstances, OR (sometimes) the dragged images always end up on the Desktop (much to one's surprise) in total disregard to the intent of the drag-n-drop. Try to drag-n-drop web images from a web browser into the deepest nested folder. Whether it's the extra few milliseconds of hitting "Cmd+C" or just the act seems to stop Finder from its stupidity. The workaround, as I've found, is to do a Cmd+C of the "new name" right after finishing typing it. This has happened hundreds of times in my experience, even mostly on my SSD startup volume. How utterly frustrating is that, after a long typing? Even worse, there's no reversal (Cmd+Z) to redo or undo the renaming by the Finder, because the Finder apparently seems too slow to handle the back-to-back action of a human user duplicating a folder and immediately renaming that. "custom name copy", *after* you've finished typing "new name". If you do it fast enough (like me), you will be rudely surprised that Finder automagically renames the duplicate folder *back* to the previous name, i.e. Now immediately try to give this duplicate folder a new name. I have two examples of Finder's royal suckitude fresh on my mind:
0 Comments
Read More
Leave a Reply. |