From owner-freebsd-chat Thu Jul 25 07:02:01 1996 Return-Path: owner-chat Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA00259 for chat-outgoing; Thu, 25 Jul 1996 07:02:01 -0700 (PDT) Received: from Fieber-John.campusview.indiana.edu (Fieber-John.campusview.indiana.edu [149.159.1.34]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA00253 for ; Thu, 25 Jul 1996 07:01:58 -0700 (PDT) Received: from localhost (jfieber@localhost) by Fieber-John.campusview.indiana.edu (8.7.5/8.7.3) with SMTP id JAA04797; Thu, 25 Jul 1996 09:01:55 -0500 (EST) X-Authentication-Warning: Fieber-John.campusview.indiana.edu: jfieber owned process doing -bs Date: Thu, 25 Jul 1996 09:01:54 -0500 (EST) From: John Fieber X-Sender: jfieber@Fieber-John.campusview.indiana.edu Reply-To: John Fieber To: Tim Vanderhoek cc: chat@freebsd.org Subject: Re: FreeBSD keyboard In-Reply-To: <199607190926.FAA07394@james.freenet.hamilton.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-chat@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [oops, left this in my outgoing mailbox for quite some time...] On Fri, 19 Jul 1996, Tim Vanderhoek wrote: > Well yes, that's what the SGML gurus seem to say when they are > waxing philosophical... :) > > I think it could be done, but the sheer complexity caused by > the number of elements and attributes that would be necessary > would make it rather impractical. It wouldn't be astoundingly complex, you just have to ditch the notion of descriptive markup. There is nothing in the ISO8879:1986 that says "SGML documents must use descriptive markup", it is just the philosophical point of view. You could just as easily make a DTD that is strictly procedural markup. In fact, there was a thread in comp.text.sgml some time back about crafting an SGML declaration and DTD that would make RTF documents valid SGML. It could almost be done. You could come up with something that looks very much like troff as well. > The problem, as I see it, is that if you are going to have to > resort to using icons for tools, you could end up with > such a large number of icons (and remember, each of these > icons must be large enough for a few knobs (or does the icon > grow larger when we drop something on it to allow finer control?)) > that the whole system becomes unuseable. This is a problem, and its solution lies in shifting the focus from GUIifying an existing command line tool, to looking at the user tasks and developing what may well be a completely different approach to the same end. Analogy: instead of designing a new screwdriver, look at the task of fastening things and ponder whether a new fastener would be even better. On the Macintosh, there is no parallel to the ls command; they have taken a different approach to the task locating files. > Or, maybe in practice it's not necessary to have more than a single > row of icons. Good question. I quick head count on /sbin /usr/sbin /bin and /usr/bin shows 611 commands. How many are used and of those, how many are commonly used? [I was going to do an analysis of a heavily used box here, but my little command pipeline ran for 40 minutes and was sucking over 100 megabytes of physical ram before I killed it (to avert being flamed for inappropriate resource usage).] -john == jfieber@indiana.edu =========================================== == http://fallout.campusview.indiana.edu/~jfieber ================