wyle@uunet.uu.net (Mitchell Wyle) (02/03/89)
Is it just me, or are system-software developers trying to make our lives harder? Visualizing and browsing a file tree is difficult. In unix, using cd and ls is plain silly. Xtree on DOS is ok for 2-3 directory levels, but we're using Sun OS :-). Finder on MacOS is a joke; it is the mouse equivilant of cd - ls, as only one "folder" is current, and the screen is so small, only one folder's contents are shown. Sun UK released a finder-like program called browser which was distributed through STB. Additionally, there is a PD program called "finder" which mimicks the macintosh "file" dialog box on a sun. These programs still show only one directory level at a time. Smalltalk shows two directory levels, but I want five plus or minus two [1]! Even the file browser in NeXt has only two directory levels. When I saw the 386i demo'd, there was a file-tree display program which showed many levels of directories, but the system was slow, and you still had to cd to the directory to do any useful work. There is also a PD program called dtree (not vtree!) which displays a directory listing graphically. This program is also slow, and again just *displays* a directory tree. What we want is a mouse-based system which displays a file-tree at many levels. The system should allow one to point at a file and "shoot" (double-click) to start a default application associated with that type of file, or point and "select" a menu of possible commands associated with that file. For example, a C-program text file should have many actions associated with it (make, lint, diff) but one default (vi or emacs). I have written two scripts which use Chuck Musciano's tooltool package (thanks Chuck!) which sort of do what I want. The first one called msh for menu-shell displays a directory tree hierarchy via WALKING MENUS in suntools; at the moment msh can start a new shell in the sub-directory, edit text files, or start meta-tool. Meta-tool examines all the files in the current directory, and generates another "tool" with menu choices associated for each file. There is some special support for troff documents and modula-2 source files, but both applications are really just skeletons. I am looking for information, comments, and software. I shall send wnl shar's of msh and mtt to include in his sunspots archives. Thag you bery buch. [1] Schneiderman, B., Association of Computing Machines Special Interest Group for Computer Human Interaction (ACM SIGCHI) Winter 1987 -- -Mitchell F. Wyle wyle@ethz.uucp Institut fuer Informationsysteme wyle@inf.ethz.ch ETH Zentrum / 8092 Zurich, Switzerland +41 1 256 5237
phil@Rice.edu (William LeFebvre) (02/03/89)
> Is it just me, or are system-software developers trying to make our lives > harder? Visualizing and browsing a file tree is difficult. In unix, It's not just you. I agree! I haven't seen a decent directory browsing system on Unix yet. However, I do have a suggestive pointer. A guy by the name of Peter da Silva wrote a program called "browser" for the Amiga Workbench (I haven't seen the UK browser system, so I don't know if it is related). It displays one window per directory, with a scrollbar on the right to scroll through the filenames. Double click on a directory (any directory from any window) and it opens up another overlapping window for that directory. The new window is usually placed so that you can see all the title tabs for all the windows---a window's title is it's pathname. Windows don't go away unless you explicitly close them. Browser has menu selections for renaming, duplicating, deleting, etc. You can move and copy files around within the system just by dragging their names. It also has the ability to set up programs as "Tools". A tool's name is added to one of the menus. For example: add "more" as a tool, select a file by clicking on it, then choose "more" from the menu and browser starts up "more" with that file as an argument. Multiple selection (with shift click) works in the obvious way. I really like this paradigm: it's the best system I've seen yet for perusing a directory tree. Obviously, some things would be different under Unix, and I think that serious perusing on a filesystem as large as Unix systems can get might prove to be a little cumbersome with all those windows. One thing it doesn't have which I wish it did was the ability to close all windows assoiated with a given directory and all its desendents (kind of a "recursive close"). If anyone wants more details, drop me a line and I will send you the doc file or answer questions as I can. William LeFebvre Sun-Spots moderator Department of Computer Science Rice University <phil@Rice.edu> ("My home computer is an Amiga")
hess@iuvax.cs.indiana.edu (Caleb Hess) (02/09/89)
In article <511@solaris.UUCP> mcvax!cernvax!solaris!wyle@uunet.uu.net (Mitchell Wyle) writes: >Even the file browser in NeXt has only two directory levels. When I saw >the 386i demo'd, there was a file-tree display program which showed many >levels of directories, but the system was slow, and you still had to cd to ^^^^^^^^^^^^^^^^^^^ >the directory to do any useful work. ... I don't know about the 386i demo you saw, but on my 386i the organizer with map option allows me to view a directory subtree and double-click on any file I can see. If the file is executable, double-clicking invokes it; otherwise, double-clicking opens an editor window for it. Yes, it is slow; I usually find the keyboard/command window to be faster than using the mouse. But the visualization is available, and it is nice at times. I have also recently had occasion to play with a NeXT box, and I find the NeXT browser to be less intuitive than the 386i organizer, as well as less flexible (limited to three columns, while the 386i window can be resized to spread a tree clear across the screen).