Re: top <repeat 100 times \r rant \r end repeat>
Re: top <repeat 100 times \r rant \r end repeat>
- Subject: Re: top <repeat 100 times \r rant \r end repeat>
- From: has <email@hidden>
- Date: Mon, 7 Oct 2002 17:51:53 +0100
Alex Robinson wrote:
>
"By contrast, many people have raised serious objections to the "black box"
>
approach used by machines such as the Macintosh, arguing that by making
>
the machine into a closed system it not only reduces the range of choices
>
open to the user, but perhaps more importantly it encourages a particular
>
attitude towards machines in general by mystifying the processes involved."
>
The Macintosh Computer: Archetypal Capitalist Machine?
That's an interesting quote, though I'm not sure what point you were
attempting to make.
If you're suggesting that abstract user interfaces are bad, that's
nonsense; by that argument, the only good UI is patchboards and jumper
cables. Everything beyond that is abstraction, including the unix command
line.
>
>But why not support verbose aliases for the same commands? Have text
>
>macros/autocompletion that can intelligently expand an abbreviated form (or
>
>even go the other way)?
>
>
Because these commands now span multiple versions of multiple OSes. [...]
Saying that something won't be easy to do is hardly a valid argument
against doing it. That only holds water if you can show the cost can't be
outweighed by the advantage. Otherwise you might as well argue "why have
different platforms/languages/ways of doing things" at all.
As for who takes the first step... well, those are what used to be called
"innovators", before the term became just another empty marketing slogan. :(
>
>The ability to view a summary of common options
>
>without having to pull up multi-page mans?
>
>
What about apropos?
Mmmm... apropos is interesting enough. But I was thinking command
arguments, though wasn't clear.
For example, I know ls, cd and rm, but I can never remember if I should
follow that with -a or -r, or what. If I pull up the man, I'm faced with
twenty or thirty options, all of which I have to read through in
alphabetical order just so I can eliminate all the rare and special-case
ones and end up with a list of the 20% I'll actually use for 99% of the
time.
It's not hard to imagine other, more valuable ways of presenting this
information in the first place; for example, by general
usefulness/frequency of use, with highest ranked items floated to the top
of the list. Then, when I want to look something up, I can view a quick
summary of the top half-dozen most likely options, and usually I'll find
what I'm looking for right there. If not, I can drill down further until I
do find what I'm after. Hardly a novel concept: e.g. think Google.
>
And if you don't want to view it from the command line
Never said I didn't want to view from the command line. I said I wanted the
command line to change so things were easier to view _there_.
>
ManThor
>
<http://www.blackmac.de/manthor/>
>
ManOpen
>
<http://www.clindberg.org/projects/ManOpen.html>
At a glance, ManOpen doesn't look very interesting but ManThor does appear
to make a credible nod towards improved presentation: natural line wraps;
non-monospaced fonts; bringing out headings, emphasis, etc. by applying
styles. Why can't we see this in a terminal?
>
>To work spatially? Non-linearly?
>
>
Sorry has. What do you mean? Non-Linearly?
In a terminal window, the only "live" bit is the very last line. One of the
things I enjoy about Satimage's Smile editor is that I can open a text
window, type one or more lines of code, then execute that code as often and
at any time I like: I just place the cursor over it, hit enter, and away it
goes again. With Terminal, I type, I hit return, and that's it: one shot
there-and-then and that's it.
>
What about having as many terminals open as you want?
Who want's tons of GUI windows floating randomly about. How about a single
window interface that can do tabbed and/or tiled views? How about pulling
up indexes in a side panel? Or typing in one pane with output going to
another? Heck, how about typing a command in a single text field built into
the Finder interface, and watching the results occurring in the Finder
windows themselves? Some enhancements apply to the terminal app rather than
the command line itself.
>
>Perhaps even... <gasp> some TYPOGRAPHY?
>
>
Well, here I'd agree with you. The way to handle colouring and fonts is
>
arcane. Maybe someone will make a nice GUI that will generate the
>
necessary lines to insert in your relevant .profile or .csrc file. Maybe
>
someone already has.
I was hoping for something a little more sophisticated than making my
terminal window 50% transparent with red 6pt Techno because I am L33T". I'm
used to DTP, XHTML+CSS; surely there are concepts used in those
technologies that a really great command line interface could steal.
>
>Mmmm. But how's any newcomer supposed to get to your intermediate/expert
>
>level if that essential first-step beginner experience "blows"?
>
>
By asking. By trying. And with OSX, the beginner has the largest group to
>
ask ever. And the most unified environment. And it's really not that hard -
>
as long as you concentrate and don't let yourself glaze over.
I've been glazed for the last fifteen years. All I want now is for the
stupid box to do it for me. ;p
But something else: no Undo. It's a very unforgiving environment.
>
>I consider the division totally bogus. "Pretty buttons for the happy
>
>idiots, Real Text for Real Men." Reactionary humbug.
>
>
Fair dos. The quote at the beginning could equally be turned on its head
>
and applied to the CLI (it is after all, an equally arbitrary and arcane
>
interface). But the distinction is still valid - here's an interface if you
>
want to hide from your machine's complexity vs ok, you're prepared to roll
>
your sleeves up and get a bit dirty.
And, as I said earlier, _both_ GUI and CLI are abstractions of the machine
itself. Thus the division is false: both are apsects of the same thing, and
any differences in complexity that might exist are relative. We use
abstractions because they make our lives easier: moving more of the nasty
low-level thinking and stuff out of our way so we can do out high-level
thinking uncluttered.
But why create one set of abstractions at one fixed level of complexity,
and another, separate set, fixed at another level? All you've got now is
two big black boxes, instead of one box that can open up to expose smaller
boxes when you need to dig deeper, and those into smaller boxes, etc
My problem now is that folk on both ladders seem to think they've reached
the top, that there's no higher the could go or should want to go. It never
occurs, for example, that one might create a longer, stronger ladder by
combining the best rungs of the two existing ones into something new.
--
I realise chewing the fat in this forum is bordering on the irrelevant, but
AppleScript, GUI and CLI all exist to fulfill the same requirement:
enabling the user to do the things they need to do, in as convenient and
[hopefully] efficient and low-key manner as possible. I'm waiting for the
day I can pop open a frame on my Finder window, click to create a new
observer object and type in a few line of script that'll execute in
response to events in that window. Or drop a set of third-party action
buttons into the window toolbar that turns it into a viewer/organiser for
my MP3 collection. Some of these pieces may already exist to some degree,
but even with those there's no real sense of integration; of layers of
functionality and enhancements built one atop the other; of a deep,
coherent structure which you can dig into as deep or as shallow as you
like; no great foundation to build on. What a shame.
But I'm going to try real hard to stop philosophising for a while: it's
fine mental exercise, but there's other things I should be concentrating
on. Anyone want to talk Framework Design? ;)
Cheers,
has
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of AppleScripts
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.