|Home » Learning Curve
On File Management (7)
Part seven. File operations with Xfile.
Most everything you want to do with Xfile is 'drag-drop'. You can copy and move files with file system I/O sheets - and that feature remains - but why? You just drag things where you want them to be and let go.
And drags always work the same, whether source and destination are on the same volume or not. (How Finder screwed that up is a mystery. Many people would like to solve that mystery.)
√ Everything by default is a copy on Xfile. It doesn't matter if it's over volume boundaries or not. This doesn't change if you stay on the same volume. It's always a copy by default.
√ You hold down '⌘' (a cmd key) to move. This is always the case as well. It doesn't matter if you're dragging to somewhere on the same volume or somewhere on another volume - hold down a cmd key to get a move. (Otherwise it's a always copy.)
√ Hold down '⇧' (a shift key - and even when using the file I/O sheets) to follow along on the operation: to make your destination your new CWD. If you're in ~/Desktop and want to copy or move something to ~/Documents and also want to end up in ~/Documents afterwards, then you hold down a shift key. And that's where you'll be - in your destination ~/Documents - when your operation completes. (Don't use the shift key and you stay where you are.)
You don't have 'copy' and 'paste' file operations because they simply don't apply and work poorly if at all. The user can never see what's being pasted in. 'Copy' and 'paste' - implemented by Apple, Microsoft and others - is simply a Bad Idea™.
√ You always drag from the right pane (the directory listing) to the left pane. You never use the left pane save for one operation: removing directories. Something you can always do from the right pane as well.
The above is for a very prudent reason: the right pane is not a 'drag client' - you can't accidentally drop something and get your file system all screwed up. A lot of times you're going to be dragging things down to the dock to open them; but a slight slip (or mechanical glitch) and your 'drop' can end up somewhere else. And not easy to find and fix. But not with Xfile. (This is another reason to disable Finder - no folder on the desktop to screw you up on drag operations.)
The left pane is a drag client - but then you drag straight across and don't go outside the Xfile window. The right pane, as stated, is a drag server only. You'll have none of the accidental mishaps you victimised by with other 'file managers' and similar programs.
√ All basic NeXTSTEP/OS X file operations are supported: copying, deleting, duplicating, moving, renaming. (Yes duplicating is a basic NeXTSTEP op - it's always been that way. This works for entire hierarchies of files as well. And the algorithm, it must be said, is a lot better than it is on Windows or other 'Unix' platforms.)
The completion of any file operation always results in a refresh of all Xfile windows. A notification is sent simultaneously to all Xfile windows. All Xfile windows get a refresh at once (which is of course very handy).
Xfile refreshes offer more than any other comparable program (and some are rather pathetic in this regard). Apple's 'table views' aren't allowed to store attributes for entries (rows) as with other platforms - attributes such as 'selected' and 'focused'. This would be easy to implement (and outrageously helpful) but the OO purists don't like it. Meaning applications have to jump through hoops to effect a sensible refresh. Something no other comparable applications do - only Xfile.
The essence of any workable refresh - ask any admin anywhere - is keeping the scroll bar thumb position constant, and the row selections and the focused row the same, with the focused row always remaining in view. But Apple's 'table view' won't do that (and some developers really embarrass themselves in their misunderstanding of this subtlety). So what to do?
- As the table view won't retain focus and selection per object (only per row - and the row can change as entries are added and removed) Xfile must make a note of all selected rows and the focused row. (Cocoa/OS X does not allow for unselected but focused rows as other platforms and offers absolutely no visual feedback in this regard either. Ouch.)
- Go to disk and see again what's there.
- Populate the table view again in the chosen column and sort order.
- Compare the new data source with the temporarily recorded row objects and select and focus as needed. (The focus row must be the last selected row.)
So you always get the above with Xfile and all ACP apps. You won't find close to it anywhere else. So spoil yourself. But remember: you won't get this anywhere else, so don't lose patience with the system because other apps don't work that way.
The left panes are also rewritten on refreshes to point to the CWD in use in each Xfile window. The CWDs are never left at the bottom of their panes. Similar controls on other platforms ensure this continually; Apple's does not; so Xfile does it on its own.
Part of an expansion of /System/Library/PrivateFrameworks. Apple's Finder and 'Finder replacements' can't do this. See the links below.
Xfile and the applications of the Xfile System use an internal protocol for drag-drop. (They also use a universal system-wide protocol for drops on other apps and on the dock.)
But the only protocol recognised for client file operations is a proprietary internal one.
This is also for security purposes: other applications that Xfile cannot control are not given the opportunity to wreak havoc on your system.
The Xfile toolbar is constructed for maximum efficiency. And yes, it can be reconfigured, but the idea is the user tries the default configuration for a while to see what subtle 'goodies' are there.
The default Xfile toolbar is bigger than what Apple's toolbar configuration sheet will allow, so the configuration is stored in the application's Info.plist and extracted by special functionality in the ACP Framework (applies to all ACP applications).
All 'goto' functions are grouped on the left in alphabetical order per directory per volume. The 'Volumes' function comes first, then Root, Applications, Utilities, and so forth.
'Preferences' (for the user) has a button of its own as this directory is accessed regularly.
These 'paths' are standardised by Apple. Some are under root, some are in the user area. Using '⌥' (the option key) switches the target from root to user or the other way around.
The 'Terminal' button follows. Rather than reinvent the wheel with yet another Terminal app further entangled by being embedded inside another existing app (with concomitant bugs, other expected maladies) the Xfile function works together with Apple's own Terminal.app. Xfile always deposits you in Terminal in the same directory you're at in Xfile. Can't be easier.
The delete button (which deletes whatever you have selected and in focus, depending on what pane you're currently using) is placed far on the right to avoid any undue mishaps. And you're always given an 'are you sure' sheet before you delete. There's no way to configure this away (and there shouldn't be). The default 'delete' moves your selections to the 'trash'; the alternative removes them forever.
You create directories and rename files with a simple sheet. You don't create something first and then try to figure out a good name; hit 'cancel' in either case and nothing happens to your system.
Apple 'user experience engineers' seem to find 'goto' toolbar buttons bewildering - most of them haven't seen more than a half dozen OS X directories in their life. That's too bad for them and they're too bad for Apple users.
Learning Curve: On File Management (1)
Learning Curve: On File Management (2)
Learning Curve: On File Management (3)
Learning Curve: On File Management (4)
Learning Curve: On File Management (5)
Learning Curve: On File Management (6)
Developers Workshop: It Wasn't Good Then, It's No Better Now