burchard@math.utah.edu (Paul Burchard) (06/17/91)
A little while back I posted a draft letter to NeXT about extending the drag-and-drop mechanism now used for folders, to allow Apps (and UNIX programs) to accept files. The response was encouraging, and even better, some tantalizing information came out about programs in development which address other parts of the NeXTstep/UNIX interface problem: SytemWorks (real and free---I'm using it), ScriptWriter (multiple-source rumor, commercial product), NeXT TCL (probably real, but undocumented). Thanks to everyone for their helpful comments. It's amusing that when decks-of-cards are added into the drag-and-drop scheme I suggested, you can even intuitively run UNIX programs like diff(1) from Workspace. For more complex shell-style, programming, though, I agree that you'll want a specialized tool like SystemWorks to take over the job (P.S. this App is in active development, and version 1.2 is supposed to be released within weeks). Here is the revised letter, which I sent off to NeXT this morning (sorry for any lingering RTF!), and the people I sent it to. If you feel strongly enough, why not drop a note to these same folks: Keith_Ohlfs@next.com rumored to be a NeXT GUI guru Bruce_Blumberg@next.com NeXT's first employee---see minibio 4/91 NW mag jmhullot@next.com (<-guessing) one of the authors of Workspace ----------------------------START OF LETTER----------------------------- Dear NeXTfolk, When I first got my NeXTstation I commented on how much I liked the NeXTstep Workspace and its File Viewer. Despite nearly a decade of experience with the UNIX command line, I loved the File Viewer right away for how pleasant it made navigating the file system. Since then, my good impression has only strengthenedPI've continued to notice well-thought out features (for example graceful handling of symbolic links). I've also noticed and appreciated the improvements over 1.0, and heard tantalizing rumors of an FTP-Browser for the future. Still, many of us find ourselves switching back and forth between Workspace and Terminal in ways that feel unnatural, to do things we ``ought to be able to do'' in one setting or the other. Here are some of the bigger roadblocks: 7 It's hard to process a file using multiple Apps, within NeXTstep. 7 It's even harder to run UNIX programs on a file, within NeXTstep. 7 It's really hard to control the operation of NeXTstep from UNIX. But my purpose is not to criticizePinstead I'd like to offer some ideas and encouragement, by myself and others. For the first pointPeasily running multiple ``tools'' on the same filePI think it's possible create this functionality in way which fits well into NeXTstep, and adds no additional clutter to the Workspace. (Although the existing Tools Inspector is meant for this purpose, it is sufficiently awkward and limited in scope that it rarely gets used.) We can even take care of a little of the second point while we're at it. The basic idea would be to allow drag-and-drop of Document icons into not just the icons of folders, but also into the icons of Apps on the Shelf, Icon Path, or Dock. But instead of showing an open folder, App icons would respond with a different ``acceptance'' gesture (if the file was acceptable). Perhaps open hands? NeXTstep would supply this generic ``acceptance icon,'' but App designers should be able to specify their own in IB if they liked. I'm hoping that you'll find this idea sufficiently natural to merit inclusion into NeXTstep. Without some access to UNIX tools, though, this mechanism will still run into some unnatural barriersPwhich brings me to the second point. Here, a balance must be struck between flexibility and simplicity, probably leaning toward simplicity. Currently, Workspace opts for the maximum simplicity, allowing users to ``launch'' UNIX programs with only the simplest possible command linePno args at all. Nevertheless, this is still a useful feature. Similarly, the simplest way to handle UNIX tools in the ``file acceptance'' paradigm would be that dropping a file (or deck of files) into a UNIX executable would cause that program to be called with those filename(s) as the only command arg(s). Again, this would cover a fair number of common UNIX tools without any additional complexity. One slightly more flexible idea I had was to allow a user's defaults database to contain ``command templates'' which would be used to construct the proper command lines for various UNIX tools and file types they might be called to act upon. (The beginner need not even be aware of these templates, as NeXT could stock a new user's defaults database with a useful selection.) For an idea of how this might work, here is some conceptual output from ``dread -o NextTemplate'': NextTemplate tar/ $cmd cf $file & NextTemplate tar/tar $cmd xf $file & NextTemplate latex/tex $cmd -v $file Note that the template varies with file extension (even permitting rejection of files), and allows a choice between interactive and background operation. Of course, when UNIX command lines become sufficiently complicated, the ``acceptance'' paradigm breaks down. To fill this gap, there ought to be additional, more specialized tools geared toward providing intuitive, graphical access to the full power of UNIXPnot necessarily authored by NeXT. In fact, we are fortunate that others have already found some quite successful solutions to this difficult design problem. The best idea I've actually seen in this direction is Youki Kadobayashi's SystemWorks. His App allows the user to drop files into graphically-rendered UNIX pipelines and watch their progress. It will also (in version 1.2) allow easy cut-and-paste, drag-and-drop creation of such pipelines by stringing together the icons of pre-supplied ``filters''. (More knowledgeable users can easily create their own filters from UNIX programs.) It provides an excellent introduction to the philosophy of the UNIX shell, without its infamous ``obscurity''. As GNU-style free software, you might consider it as a candidate for incorporation into the NeXT software bundle, just as has been done with other GNU software. As for the third pointPaccess to NeXTstep from UNIXPthis is, if you like, the topic of the one substantive criticism of NeXTstep made in BYTE magazine's latest GUI splash (which also included many positive comments about NeXT and NeXTstep). They phrased it as a lack of ``macro or task-automation features.'' Now, according to rumor, there is something already in the works called NeXT TCL which directly addresses this concern. So here, I would just like to pass on some encouragement to make this an official product . . . While other barriers do exist in the current NeXTstep GUI (such as lack of full network transparency), the ones I've mentioned are ones that I believe I knowPor know ofPgood solutions for. I make these suggestions because I like my NeXT enough to want it to be even better. How do these ideas sound to you folks? Thank you for your time. Paul Burchard burchard@horizon.math.utah.edu ----------------------------END OF LETTER----------------------------- -------------------------------------------------------------------- Paul Burchard <burchard@math.utah.edu> ``I'm still learning how to count backwards from infinity...'' --------------------------------------------------------------------