This is 3--ReleaseNotes.rtf in view mode; [Download] [Up]
Release Notes Release 1.2, June 7th, 1994 ©1994 by H. Scott Roy This document contains three important pieces of information: what's new in the latest IconKit release, known problems, and instructions for reporting bugs in the most helpful way possible. What's New, v. 1.2 This release brings a quantum improvement to the underlying user interface elements: · Correct handling of long names in browser and icon cells. · Ghosting of cells during dragging. · Garbage collection of objects in unused cells. · Support for an inspector synchronized with the browser selection. · Improved performance. Following is a brief description of each of these with pointers to the full documentation. Long Names Previous versions of IconKit were rather dismal in dealing with titles that overflowed their containing cells. The latest release fixes this problem, allowing one to either indicate long titles with an elipses, like Workspace, or wrap titles to multiple lines, like Librarian. Selecting a shortened title for editing always displays the complete text. The IKCell inspector in InterfaceBuilder contains a new option that lets one set the formatting for long titles. More detail can be found in the introductory parts of the IKCell and IKBrowserCell documentation. Ghosting Items are now ghosted as they are dragged over cells. The IKCell documentation describes the isGhosting: and setGhosting: methods used to control this behavior. Garbage Collection Garbage collection was suboptimal in previous versions of IconKit, since browsers and matrices would often leave objects lying around in unused cells. The latest version of IconKit fixes this problem by introducing two new browser delegate methods, browser:emptyMatrix:inColumn: and browser:removeColumnIcon:for:, that are sent out whenever browser columns are deleted. IKBrowserManager responds to these methods by removing objects from the unused browser columns so that they can be garbage collected. Inspector Support IKBrowser provides a third new delegate method, browserDidChange:, that it sends out after stabilizing on a new selection. Subclasses of IKBrowserManager can use this method to coordinate inspectors that should be synchronized with the browser display. The documentation for IKBrowser and IKBrowserManager details all the new browser delegate methods. Improved Performance Drawing performance has been tuned in several places, most notably when setting up long paths in a browser, and when obliterating large numbers of objects. Numerous other minor problems have been corrected under the hood. There's one notable addition: · IconKit now looks for an ªIKDebugº default to set the initial debugging behavior. You can turn on debugging output by invoking your program from the command line and including this option. For example, FileViewer -IKDebug Debugging output traces objects as they add and delete users and free themselves. It is a highly useful tool for tracking down memory management problems. It's recommended that you run FileViewer in debugging mode at least once to get a feel for the garbage collection and updating that goes on in IconKit. What's New, v. 1.1 This release fixes a few minor problems from v. 1.0, the most serious being a bug that prevented the icon path from redrawing properly when selecting objects to the left of the current selection. There's only one addition of new functionality: · A new method, sort:count:for:, has been added to IKBrowserManager to sort the elements in a column. The default implementation does nothing, but subclasses can override it to provide whatever sorting behavior they desire. The FileViewer application shows how to sort objects by name. How to Report Bugs Send a complete description to the author using either e-mail or the postal service: H. Scott Roy 2573 Stowe Ct. Northbrook, IL 60062-8103 iconkit@cs.stanford.edu As usual, the more detail the better. If you make extensive changes to fix any bugs, a diff file showing the difference would be helpful. This code has been developed on a NeXTstation Turbo Color running NEXTSTEP 3.2. It has been verified to work on both Intel hardware and earlier versions of the operating system, but I would appreciate a bug report if you encounter any problems. Known Problems, v. 1.2 The first four of these are things I'm pretty sure I can't do anything about. With luck, they'll disappear when NeXT fixes a few of the bugs in their software. · Resizing an IKBrowser within InterfaceBuilder resets its attributes to stupid default values. Make sure you use the inspector to change them after resizing the browser. If anyone figures out a simple way to fix this problem I would appreciate learning. The values are already munged before placeView: gets called, and I'm not quite sure where else to look. · The scrolling behavior of an IKBrowser (or an NXBrowser) slows down perceptibly unless the entire browser is visible. If you compare the viewer in FileViewer with the one in Workspace, you'll notice a one pixel width difference along the bottom edge. Try changing the nib to match the one in Workspace and notice the speed difference. The bug is sort-of-not-a-bug, just a bad implementation on NeXT's part. · It's impossible to select the IKIconPath within a ScrollView in InterfaceBuilder. You can select the cells, but not the matrix itself. The bug is NeXT's, since you can't select any other kind of matrix inside a ScrollView either. · Garbage collection is turned off when running under InterfaceBuilder. Bad things happen when the IconKit and InterfaceBuilder both think they're responsible for freeing an object. · Obliterating an IKfolder in IB test mode will crash InterfaceBuilder if that folder exists in the nib file. If anyone knows how to figure out which objects InterfaceBuilder claims responsibility for, I'ld really, really like to know. · Doing a selectAll: that selects nothing (possible when a column contains only branch nodes), or shift clicking to deselect the last selected object in a column, incorrectly leaves an empty column in the browser. · An IKList should send out notifications that its name has changed when objects get added or deleted. · If an object appears at more than one place in a browser's icon path and adds or removes children, then only the first column in which the object appears is automatically reloaded. Things to Do, v. 1.3 None of these are promised, but they do comprise my list of additional improvements for future versions of IconKit. · Find a way to correctly set a path for a multiple selection. · Set paths by object rather than strings. · Allow one to set whether a cell is ghosted or not within IntefaceBuilder. · Add userRespondsTo: in IKAnnouncer. · Get rid of hardwired NX_LTGRAY cell backgrounds. · Get rid of the hard wired '/' path separator in IKBrowserManager. · Don't allow a folder to add itself as one of its own children (this can happen now when dragging a multiple selection onto a folder). · Make double clicks in the browser do the right thing when the first click adds a new column. · Allow control-dragging to reorder cells in a browser column (?). · Allow an icon view in the browser cells (?). · Allow editing in directly in the browser cells (?). Cool Programs You Might Write Anything that has a natural hierarchical structureÐparticularly one that can be adjusted by the userÐis a natural candidate for an IKBrowser. Anything that needs to be used frequently is appropriate for an IKShelf. Here are a few ideas I've had that I'm sure I'll never get around to, but that someone else might like to pick up. Fonts and Rulers Until we get a real word processor that can keep track of styles, wouldn't it be nice to put commonly used fonts and rulers on a shelf where we could get at them quick? I think someone's already done such a thing, but it should be snap to implement using IconKit. A Better Mail.app You should be able to organize mailboxes and mail messages just like files. Of course, an even better idea is to build Mail.app on top of a true database system, but NeXT is still working on getting such a thing for their own file system. A Better Newsgrazer.app Here would be a truly cool application. The user can put commonly used newsgroups (and threadsÐsuch a program should really be built on top of trn), onto a shelf, as well as constructing his own hierarchy of newsgroups. That is, I can organize the groups I normally read into my own obvious hierarchical structure: sports go here, politics go there, clari goes here, and so forth. Remote Browser It should be easy enough to extend FileViewer to browse remote locations. File retrieval would work, of course, via ftp. Remote directories that you seem to access all the time (cs.orst.edu? prep.ai.mit.edu? Where do you always go?) can be kept on the shelf. Really, of course, the idea is just to turn the entire world into a giant file graph. And naturally, both the Newgrazer idea and this one are leading up to¼ Mosaic The web is truly the right place to show off something like a browser. XMosaic lets one create new documents with pointers to interesting stuff, but why not have a browser and shelf as well? When you see something you like, just drag it onto a shelf (or into another html document) for convenient access. Moreover, the browser would do a fine job a giving the user some context of where he's at. It's very, very easy to get lost in webland. Just don't forget to send the royalty checks when the dollars start rolling in. :-)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.