burchard@math.utah.edu (Paul Burchard) (06/03/91)
I think NeXT has done a great job of putting a User Interface on UNIX. As has been discussed here, though, there's still one significant gap to filled: in the UI it's hard to work on Documents using different tools---especially UNIX tools. This gap probably arose from the current Application-oriented (rather than Document-oriented) slant of NeXTstep. I think it's possible create this ``multiple tool'' functionality with a minimum of disruption to NeXTstep, by basing it on the drag-and-drop mechanism which already exists in the Workspace. Just as folder icons can now accept file icons, icons of executables and Applications would then be able to accept Document icons. To give this basic idea some substance, I have given some thought to how it could be successfully implemented---in the letter below. I'd like to send it to some key people at NeXT so that we might be able to see these features in 3.0. Before I sent it off, though, I thought I should get some help and advice from the good folks (and sharp-tongued gurus :-) of comp.sys.next. Would you suggest some improvements to this scheme? Do you have any advice on whom to write at NeXT? Thanks...and here's the draft letter: ------------------------------ draft --------------------------------- 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 strengthened---I'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 (yeah!). Still, I (and others) continue to keep a Terminal within easy reach. The biggest reasons are that with Workspace * it's hard to run different programs on the same file * it's even harder to run UNIX programs on a file. The Tools Inspector is fairly awkward for this even within its limited scope. But I think there is a pretty nice intuitive way to do most of this that fits well into NeXTstep, and adds no clutter to the Workspace! The basic idea would be to allow drag-and-drop of file icons into the icons of executables sitting in the Shelf, Icon Path, or Dock. Just as folder icons there can accept files, so too would executable icons. But instead of showing an open folder, they would respond with an ``acceptance'' gesture (if the file was acceptable). The simplest gesture would be for the icon to highlight as if it were about to launch. A nicer UI gesture, though, would be for the icon to change to a special ``acceptance icon''. NeXTstep would supply a generic one (open hands?), but App designers should be able to specify their own in IB if they liked. For apps, this would pretty much be the whole story. But doing this for UNIX commands requires knowing how to construct the proper command line. This can of course get hairy, but remember that the goal is not to perform arbitrary UNIX command lines, just to call programs that can be thought of as performing an action on a single file. So, generically, the command line "$cmd $file" could be used (with the obvious meanings of the variables). But to cover other usages, command templates would be stored in the defaults database, where they could hopefully be set using the ``UNIX Expert'' panel in the Preferences app. NeXT would stock a user's initial defaults database with some useful templates. The exact format and level of generality of these templates I leave to your collective imagninations. But the template should probably be allowed to depend on at least the filename extension as well as the command name, and you should be able to choose between background and interactive operation. For example, you'd want to be able to do something like this (simulated output for "dread -o NextTemplate"): NextTemplate tar/ $cmd cf $file & NextTemplate tar/tar $cmd xf $file & NextTemplate latex/tex $cmd -v $file Notice, in this example, how a UNIX command could become selective about which files it accepted from the Workspace. 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 (assuming you haven't thought of them already)? Paul Burchard burchard@horizon.math.utah.edu ------------------------------ end draft --------------------------------- ----------------------------------------------------------------------------- Paul Burchard <burchard@math.utah.edu> ``I'm still learning how to count backwards from infinity...'' -----------------------------------------------------------------------------
barry@pico.math.ucla.edu (Barry Merriman) (06/03/91)
In article <1991Jun2.203311.19795@fcom.cc.utah.edu> burchard@math.utah.edu (Paul Burchard) writes: >there's still one significant gap to filled: in >the UI it's hard to work on Documents using different tools---especially > UNIX tools. > I agree this point needs to be resolved before UNIX folks can shed their shells forever, on their NeXTs. There used to be a partial fix for this, at least for unix commands that always act on files with special suffixes (.tar, .tex, .Z, etc) and produce an output file named via some convention: the ``Unknown'' App. ``Unknown'' seems to no longer work under 2.0, though. Does anyone know if a 2.0 Unkown app is available? (Even if NeXT works on this point, we still need an interim fix for these things, and that must come in the form of some public domain App like Unknown). >I think it's possible create this ``multiple tool'' functionality with a >minimum of disruption to NeXTstep, by basing it on the drag-and-drop >mechanism which already exists in the Workspace. >Just as folder icons can now accept >file icons, icons of executables and Applications would then be able to >accept Document icons. NeXT is not going to take lightly any amendments to the drag-and-drop paradigm, since user interface consistency is a major issue for them. I'm sure getting permission to extend drag-and-drop from a graphical alias for cp/mv/ln to a graphical alias for an arbitrary command with file input would require lots of internal debate at NeXT. >doing this for UNIX commands requires knowing how to construct the >proper command line. This can of course get hairy, but remember >that the goal is not to perform >arbitrary UNIX command lines, just to call programs that can be thought >of as performing an action on a single file. [suggests using the defaults database/dwrite to create default command line options conditioned on the filename suffix] This is really similar to how the ``Unkown'' app worked, although, If I recall, it kept its own database of command lines, rather than using the defaults database. I suggest Unkown is sufficient, and nearly optimal for this sort of thing---it worked pretty well for tar/untar, compress/uncompress, tex-ing, etc. You might want to just get ahold of the 1.0 Unkown, and see if it can be modified to work under 2.0---probably no big deal. it lives at nova.cc.purdue.edu in /pub/next/1.0-release/source (I don't a version in the 2.0-release directory, and the 1.0 version I had doesn't seem to work under 2.0). >Do you have any advice on whom to write at NeXT? I suggest that, since you are in higher ed, that you go through the NeXT Director of Higher Ed, Dr. Ron Weissman; his addrss is ronald_weissman@next.com. He should be able to forward your mail to the appropriate internal group at NeXT. -- Barry Merriman UCLA Dept. of Math UCLA Inst. for Fusion and Plasma Research barry@math.ucla.edu (Internet) barry@arnold.math.ucla.edu (NeXTMail)
barry@pico.math.ucla.edu (Barry Merriman) (06/03/91)
In article <1991Jun2.203311.19795@fcom.cc.utah.edu> burchard@math.utah.edu (Paul Burchard) writes: >there's still one significant gap to filled: in >the UI it's hard to work on Documents using different tools--- >especially UNIX tools. >I think it's possible create this ``multiple tool'' functionality with a >minimum of disruption to NeXTstep, by basing it on the drag-and-drop >mechanism which already exists in the Workspace. >The basic idea would be to allow drag-and-drop of file icons into >the icons of executables sitting in the Shelf, Icon Path, or Dock. >Just as folder icons there can accept files, so too would executable icons. >For apps, this would pretty much be the whole story. But doing this for >UNIX commands requires knowing how to construct the proper command line. > This can of course get hairy, but remember that the goal is not to perform ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >arbitrary UNIX command lines, just to call programs that can be thought ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >of as performing an action on a single file. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [suggests using defaults database to store default command lines for various unix commands] As I mentioned in another reply, this is a lot like ``Unkown'' App (which doesn't work in 2.0) Since an Unknown-ish App is able to meet your limited goal (and nearly exists), and since the limited goal is often not enough (even unix commands that act on a single file may need a standard output and standard error to send messages (e.g. wc), and common commands like "grep" are not within your goal) I think we should consider the greater goal to being able to do arbitrary UNIX command lines conveniently without opening a Terminal. The coolest route would be to give each unix command a little App panel, with a field for command line, standard error, standard output, and to be able to take file input from a a little browser, and to allow piping and redirecting graphically, by linking the little app panels by various plumbing fixtures, or sticking little bricks next to eachother. Most of this could be done without NeXT's help, just using the IB; only the graphical piping/redirection would be tricky. That would be pretty neat and fancy, but in reality we could get by with much less. The thing that annoys me most about the current situation is that (1) I need to start up/open a new Terminal (1.5) I often need to su to root first (2) I need to cd to <horribly-long-directory-name> (3) I need to enter <horribly-long-filename> on the command line (yes, my shell has filename completion, but its still a pain, and for safety reasons I don't use these conveniences when I am root) (4) Its not the "NeXT way" to do things (i.e.,its totally un-elegant) A suffient fix would be a single ``UNIXCommand" App, which would just be a sort of special purpose Terminal for executing unix commands. What makes this better than using a terminal is that you could eliminate pains (2),(3),(4) by allowing it to get its file inputs/outputs from an associated browser. The UNIXCommand App could also absorb the functionality of "Unkown", by having default coomands/command lines for various file types/command inputs. (Maybe it could even be set up so that one could easily su to root prior to do the commands, thus eliminating another common reason for keeping a Terminal open!) I think a UNIXCommand app is a better fix than trying to get NeXT to ammend the Workspace, because: (1) Someone skilled with IB could probably whip it out in a day, as opposed to years waiting for NeXT to act (not to mention that they wont tell us what they are doing :-) (2) I think NeXT is most concerned with making it unnecessary for the average user to ever need UNIX commands, rather than making UNIX commands easier to apply. (For example, their Installer App (is supposed to) eliminate the need for tar, compress, cat, to install software.) Thus they probably wont go to great lengths to accomodate the ever decreasing number of users who need the raw UNIX commands. So, we few remaining UNIX users need to help ourselves; is anyone planning to make a UNIXCommand App? A related beef: is it/will it ever be possibe to use the GUI/IB to make graphical shell scripts? A graphical front end to a shell script would be the easiest way to make a UNIXCommand App. -- Barry Merriman UCLA Dept. of Math UCLA Inst. for Fusion and Plasma Research barry@math.ucla.edu (Internet) barry@arnold.math.ucla.edu (NeXTMail)
youki@neptune.ics.osaka-u.ac.jp (Youki Kadobayashi) (06/03/91)
In article <1991Jun2.203311.19795@fcom.cc.utah.edu> burchard@math.utah.edu (Paul Burchard) writes: >From: burchard@math.utah.edu (Paul Burchard) >Newsgroups: comp.sys.next >Keywords: drag-and-drop, tools, documents vs. applications >Date: 2 Jun 91 20:33:11 GMT >Sender: news@fcom.cc.utah.edu >Organization: University of Utah Computer Center >Lines: 93 > >I think NeXT has done a great job of putting a User Interface on UNIX. As has >been discussed here, though, there's still one significant gap to filled: in >the UI it's hard to work on Documents using different tools---especially UNIX >tools. This gap probably arose from the current Application-oriented (rather >than Document-oriented) slant of NeXTstep. > >I think it's possible create this ``multiple tool'' functionality with a >minimum of disruption to NeXTstep, by basing it on the drag-and-drop mechanism >which already exists in the Workspace. Just as folder icons can now accept >file icons, icons of executables and Applications would then be able to accept >Document icons. > Try "SystemWorks". It's simple and programmable NeXTstep-to-UNIX interface. I just put the latest version (1.1 beta) on cs.orst.edu:~ftp/pub/next/submissions. Recompilation is needed to run SystemWorks on 2.[01]. It contains 2.0J-compiled binary. Let me hear your comments, NeXTlanders. Enjoy. -- Youki Kadobayashi Information Network Architecture Lab. Dept. of Info. and Comp. Sci, Osaka University, Japan
eps@toaster.SFSU.EDU (Eric P. Scott) (06/03/91)
I believe that any attempt to eliminate CLIs is barking up the wrong tree. Often, a shell *is* the best tool for the job, and there's a lot to be said for the UNIX "tools" philosophy--build small modules that do one thing (or a few things) well, rather than construct behemoth "integrated applications" with slick GUI interfaces but limited capability. It's this idea that leads to the concept of "reusable code" as exemplified by the NextStep Application Kit. What you're proposing is a throwback to the dark ages. (Dark BLUE ages.) We should be looking for ways to make the machine more functional, not less. If the NeXT ends up as crippled as the Macintoy, I'm going to look for another platform... -- "Some people like working with a mouse, and some people think they're vermin" --a particularly well-known Apple Tech Writer
barry@pico.math.ucla.edu (Barry Merriman) (06/04/91)
In article <1643@toaster.SFSU.EDU> eps@cs.SFSU.EDU (Eric P. Scott) writes: >I believe that any attempt to eliminate CLIs is barking up the >wrong tree. I agree totally---I don't want to eliminate the Command-Line-Interface; what I want is a *NeXTStep-based* CLI. This means it would make full use of NeXTStep amenities: * browsers for navigating the directory tree and file specification, * mouse-based editing of command-lines & command history, * icons/drag-and-drop for applying tools to files * ability to ``su'' to another users Workspace, * shell script/CLI 2-way interaction with NeXTStep display >Often, a shell *is* the best tool for the job, and No---a shell is a hole punched *through* the NeXTStep interface, and it doesn't interact properly with the Workspace: *When I su to root in my shell, my Workspace---not even a part of it---su's root; so you suddenly lose all the GUI. *I can't write a shell script based NeXTStep App, take mouse input into a shell script (e.g put up a button box, slider, etc), or do any real communication between CLI and the GUI (all you can do is Launch an App from the CLI). * I can't use all the great GUI file maneuvering methods in my CLI, so I have to do much more typing than I should. I don't see how you can say a shell is the best tool, when it is so decoupled from the primary user interface. >there's a lot to be said for the UNIX "tools" philosophy--build >small modules that do one thing (or a few things) well, I agree---but now the user interface is no longer simply 24 lines of ASCII. It is that and much,much more. The ``tools'' that we build must evolve along with the interface---so they should be allowed to have a graphical as well as ASCII CLI component. What needs to be addressed is how to extend the UNIX type of tools (the analog of a shell scripts) to the NeXTStep environment. As it stand now, you just scrap the GUI whenever you want to do some UNIX stuff. That can't be optimal! -- Barry Merriman UCLA Dept. of Math UCLA Inst. for Fusion and Plasma Research barry@math.ucla.edu (Internet) barry@arnold.math.ucla.edu (NeXTMail)
mitroo@magnus.acs.ohio-state.edu (Varun Mitroo) (06/04/91)
Seems like there are a couple of ways of making the unix shell more integrated with the Workspace. The first way would be to have the shell become part of the Workspace app and have a shell associated with every file viewer. Something similar to how Improv hides all the rules for a worksheet would be a nice way to do it. The second way would be to make a new version of the Terminal app that has a mini browser associated with every shell window (maybe attached to the top of the shell). You could either type "cd <directory>" in the shell or do it from the browser. Maybe this could also have a definable set of buttons along the top margin of the window (similar to the shelf on File Viewers) that contained frequently used unix commands. One could drag and drop files from the mini browser onto these buttons and the commands would be typed out for you on the command line. Of course, this would have problems for commands which need parameters, but it wouldn't be too bad if you could just edit the command using the cursor keys and just type in the changes. With either of these methods, If you "su"ed to another user, the browser or file viewer associated should change to the new user - maybe display the current directory and username in the title bar of the window. I hope NeXT has something like this in mind for a future release. Varun -- You are young, they are old Control is all they've got to give Just live how you want to live Tiny things that make you slave Like a chain, an anchor to the bed of the sea
barry@pico.math.ucla.edu (Barry Merriman) (06/04/91)
In article <1991Jun4.035408.6986@magnus.acs.ohio-state.edu> mitroo@magnus.acs.ohio-state.edu (Varun Mitroo) writes: >Seems like there are a couple of ways of making the unix shell more integrated >with the Workspace. The first way would be to have the shell become part of >the Workspace app and have a shell associated with every file viewer. > >The second way would be to make a new version of the Terminal app that has a >mini browser associated with every shell window Both good ideas that would be good enough to make me happy. >I hope NeXT has something like this in mind for a future release. But don't look to NeXT for these things---they didn't really even make the Terminal App (its an adapaptation of Scott Hess' Stuart VT100 emulator). And I doubt NeXT's highest priority is making life a bit easier for folks who know what "grep -i -v" does. No, the person to target is clear: Scott Hess, get on it and make Stuart 3.0 with the above features! :-) I've got $30 waiting here for you when you get done. -- Barry Merriman UCLA Dept. of Math UCLA Inst. for Fusion and Plasma Research barry@math.ucla.edu (Internet) barry@arnold.math.ucla.edu (NeXTMail)
eps@toaster.SFSU.EDU (Eric P. Scott) (06/04/91)
I want to see how one does multiple "glob" expansions in a GUI.
Or stuff like
find / -name .nfs\* -mtime +7 -exec rm -f {} \; -o -fstype nfs -prune
I can use Command-arrows to cycle through windows but I have to
take my hand off the keyboard to select a window. Mice are great
for drawing pictures, but they just don't cut it for real work...
Most of what I do is text entry. I'm *very* happy that Edit
(and Mail) support emacs-style keyboard commands.
-=EPS=-
--
In the latter half of the decade, mice will probably account for
more occupational injuries than keyboards.
Try using a "wrist rest" with a mouse sometime.youki@neptune.ics.osaka-u.ac.jp (Youki Kadobayashi) (06/05/91)
In article <1652@toaster.SFSU.EDU> eps@toaster.SFSU.EDU (Eric P. Scott) writes: > From: eps@toaster.SFSU.EDU (Eric P. Scott) > Newsgroups: comp.sys.next > Date: 4 Jun 91 08:24:08 GMT > References: <1991Jun3.035743.28221@math.ucla.edu> <1643@toaster.SFSU.EDU> <1991Jun3.210917.1157@math.ucla.edu> > Reply-To: eps@cs.SFSU.EDU (Eric P. Scott) > Organization: San Francisco State University > Lines: 16 > > I want to see how one does multiple "glob" expansions in a GUI. > > Or stuff like > find / -name .nfs\* -mtime +7 -exec rm -f {} \; -o -fstype nfs -prune Every tool has its own limitation; full-featured tools are likely to become complex and hard-to-use for average users. Suppose one created ambitious visual-oriented-shell which can replace /bin/tcsh or /bin/bash, performing administrative tasks with it would be much harder than doing same job with /bin/*sh. In some cases it's best to "ignore" or "don't deal with" such needs, e.g. globbing. Struggle to be complete will make the ambitious v-o-sh one of useless beasts. Resulting beast will require complex setting for even simple tasks. You can say default will help to eliminate complex setting. $_ and "guesses" in PERL might be good example. However, it won't apply to v-o-sh, since UNIX tools are usually dynamically combined and different options may be given each time it's invoked (or else, such commands can be reduced to a shell script). I'll choose to type commandlines in Terminal rather than reconnecting graphical command units. However, frequently-used simple commands can often be performed more easily by graphical user interface. Navigating over UNIX filesystem with File Viewer is much easier than repetition of "cd", "ls" and "more". The problem of File Viewer is that it doesn't support basic UNIX commands other than "cd", "ls", "open", "mv", "ln -s", "cp", "rm", while there are many commands which is as simple as those enumerated above. > I can use Command-arrows to cycle through windows but I have to > take my hand off the keyboard to select a window. Mice are great > for drawing pictures, but they just don't cut it for real work... > Most of what I do is text entry. I'm *very* happy that Edit > (and Mail) support emacs-style keyboard commands. When I'm using keyboard I don't want to use mouse, if possible. When I'm using mouse I don't want to use keyboard, if possible. That's why I wanted to write app like SystemWorks. When I'm using File Viewer, and if I wanted to print the document, I don't want to launch Terminal just to invoke "lpr VeryLongPathName". In such case I can drag the document onto "printer" icon, which is an "iconified script" provided by SystemWorks. -- Youki Kadobayashi Information Network Architecture Lab. Dept. of Info. and Comp. Sci, Osaka University, Japan
scott@mcs-server.gac.edu (Scott Hess) (06/05/91)
In article <1991Jun4.054438.2840@math.ucla.edu> barry@pico.math.ucla.edu (Barry Merriman) writes: In article <1991Jun4.035408.6986@magnus.acs.ohio-state.edu> mitroo@magnus.acs.ohio-state.edu (Varun Mitroo) writes: >Seems like there are a couple of ways of making the unix shell more >integrated with the Workspace. The first way would be to have the >shell become part of the Workspace app and have a shell associated >with every file viewer. > >The second way would be to make a new version of the Terminal app >that has a mini browser associated with every shell window Both good ideas that would be good enough to make me happy. >I hope NeXT has something like this in mind for a future release. But don't look to NeXT for these things---they didn't really even make the Terminal App (its an adapaptation of Scott Hess' Stuart VT100 emulator). And I doubt NeXT's highest priority is making life a bit easier for folks who know what "grep -i -v" does. Technically, Terminal is their's, though - I want to nip complaints in the bud (though many complaints about Terminal apply equally to Stuart, there is a non-empty subset of them that don't :-). I agree that NeXT isn't as concerned with people who know how to use find(1) (I think find's a bit tougher test of Unix knowledge - considering how neat is is, and all :-). On the one hand, it would be nice to be able to do this stuff easily. On the other hand, NeXT's momentum is more concentrated on trying to remove the need for much of that stuff. My opinion is that they eventually will remove that need. Not so much because no one needs it anymore, but because no one knows how. There's nothing like a terminal-level connection to teach someone Unix. NextStep will tend to keep alot of people who would be better off knowing the Unix from ever learning what they need. No, the person to target is clear: Scott Hess, get on it and make Stuart 3.0 with the above features! :-) I've got $30 waiting here for you when you get done. :-). I'm listening. Not Stuart3.0, that's for certain (Stuart3.0 is starting to look like Apple's System 7.0, is it not?). This is still just a limited approach to the problem. What I'd really like would be a "smart" subshell that could work with Stuart to do amazing stuff having to do with help and the like. I could supply hooks to pop up panels and all, the subshell would then send special escape sequences to direct Stuart to do whatever needs to be done. For instance, there could be an escape sequence that would pop up a browser in a panel, browsing a specified. Then Stuart could send back the selected filename(s). I can modify Stuart - anyone out there want to write the shell? Maybe bash would be a good start . . . Now that I think about it, though, maybe there is room for a difference type of shell. For instance, a command-history looks mostly like a single-column browser, right? File selection is obviously a file browser. Running multiple commands would be done in multiple little windows, rather than backgrounded. Hmm, I'm getting too many ideas . . . Later, -- scott hess scott@gac.edu Independent NeXT Developer Graduated GAC Undergrad! <I still speak for nobody> Note: I have moved home for a time. My email address will still be valid. Any SnailMail should be redirected, along with phone calls. At the least, my parents can tell you how to get hold of me, or forward any mail . . . Old: PO 829, GAC, St. Peter, MN 56082 (507) 933-8466 New: RR#4 Box 227 Pipestone, MN 56164 (507) 825-2788
rca@cs.brown.edu (Ronald C.F. Antony) (06/15/91)
In article <676362343.2@egsgate.FidoNet.Org> Varun.Mitroo@f98.n250.z1.FidoNet.Org (Varun Mitroo) writes:
#Seems like there are a couple of ways of making the unix shell more
#integrated
#with the Workspace. The first way would be to have the shell become part of
#the Workspace app and have a shell associated with every file viewer.
#Something similar to how Improv hides all the rules for a worksheet would be
#a nice way to do it.
#
#The second way would be to make a new version of the Terminal app that has a
#mini browser associated with every shell window (maybe attached to the top of
#the shell). You could either type "cd <directory#" in the shell or do it
#from
#the browser. Maybe this could also have a definable set of buttons along the
#top margin of the window (similar to the shelf on File Viewers) that
#contained
How about adding a Service to Stuart/Terminal that cd's to a
selection?
Of course that implies that the Workspace manager has to provide the
path of the currently selected file in form of text. Or maybe a simple
copy/paste of the selected file would be enough.
Ronald
------------------------------------------------------------------------------
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man." G.B. Shaw | rca@cs.brown.edu or antony@browncog.bitnet