FileViewer.rtf

This is FileViewer.rtf in view mode; [Download] [Up]

FileViewer

FileViewer is an IconKit example that recreates the look and feel of the NEXTSTEP Workspace file viewer. It shows off virtually all of IconKit's capabilities. The code required to implement FileViewer is little more than the bare minimum necessary to read directories from the file system.

There's one important point to remember while playing with this example:

It looks like a Workspace viewer, it feels like one, it might even smell like one. But it's not.
Nothing you do in FileViewer will affect your file system in any way.

So feel free to go wild.

Try making lots of viewers and shelves that all show the same parts of the file system, then drag a file to a new location, or edit a file's name, and watch everything automatically update to reflect the change. You can drag files between viewers, and into other applications. You can also drag files from other applications into FileViewer.

Try using the commands in the File menu to edit the file graph, and remember to try command-dragging to drag things off a shelf.

Things to Learn from the Code

FileViewer demonstrates how to adapt the IconKit classes for your own applications. Almost all the functionality of FileViewer is inherited from the standard IconKit classes, so you should be sure to study the IconKit source files in addition to the FileViewer code. Here are the important things to look for:

The browser delegate is implemented by the FileManager class, a subclass of IKBrowserManager. FileManager adds almost no new functionality, merely showing how to write action methods that operate on the current browser selection. The one significant thing it does do is to override sort:count:for: to sort files by name. Here's what to notice in the source code for IKBrowserManager in case you decide to write your own browser delegate:

� The browser:fillMatrix:inColumn and browser:setColumnIcon:for: delegate messages. An IKBrowser sends these messages when it needs to fill columns of the browser or put a new icon at the top of a column.

� The way that an IKBrowserManager stores objects directly in IKBrowserCells and IKCells.

� The code in awake: that initializes the browser's icon path. In particular, notice that you must manually register to accept drags of the appropriate type.

� The way the various editing operations, like delete:, extract the current browser selection and make changes. Notice that the browser delegate doesn't need to worry about redisplaying things, since the objects being changed will send out announcements wherever they are needed.

Files are a subclass of IKFolder. As with the browser delegate, IconKit provides virtually all the functionality for dragging and editing, so that the File class only needs to provide code to extract directories from the file system. Here's what to notice:

� The IKIconObject methods that define how a File should be displayed and respond to mouse events.

� The way in which images and directories are not loaded until requested, saving both time and memory.

� The depth first search algorithm used by IKFolder to find paths. The browser delegate uses this code to set the browser's path when the user clicks on a shelf icon.

� The shelf notification methods, shelf:dragWillEnter: and its siblings. A shelf sends out such notifications to indicate the stages of a dragging operation. The File class uses them to overcome a bug in Workspace that makes it impossible to send Workspace requests during a drag.

� The pasteboard methods. Notice how a File gets copied both as an IKidPboardType and a NXFilenamePboardType. Also notice how the File class provides its own multiple selection class, FileList, so that multiple selections can be properly dragged in and out of FileViewer.

These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.