#Workbench for novices
21 messages in this thread
No, the "resource fork" of Mac files is not necessary for icon
information. It is perfectly possible to do the same things without using
such things as two distinct forks to a file.
You comments about Apple restricting peoples attempts to get to the innards
of the machine have me lost. Apple does no such thing–its just that
programs that don't adhere to the Mac interface don't sell, the user
community won't buy such programs.
Of course, there is no such problem on the Amiga, nor am I advocating the
adoption of such principles. I'm mere drawing upon experience from several
other systems (the Mac being just one of them) to suggest a method that
works quite well in having an icon based user interface that wouldn't get
in the way of CLI based users and would use considerably less memory than
(er, disk space) than the current ".info" method.
Apple did not (at least early in the Mac's life), publish anything beyond
what was needed for writing the 'standard' interfaces. I don't know this
fromn direct experience, but from the comments and anguished screaming I
heard from people trying to do anything a little out of the gospel ways as
laid down by Apple. The whole machine is like that from what I can see.
Closed software, closed hardware, and only recently has Apple decided that
perhaps the users might be better able to judge what they really want, and
have allowed for expansion in at least one of their machines.
Well, as a former developer of Macintosh software, what you are saying is
just not the case (I was working on Mac stuff back in 1984 when the machine
first came out–then jumped to the Amiga when it finally came out). Sure,
the documentation on the Mac was minimal to none back then, just like it
was for the Amiga in its first year or so of life. But to say that Apple
was restricting information is nonsense, its just that this stuff was
difficult to find because it wasn't written down anywhere!
This idea that the Mac was a closed machine is primarily due to the way the
machine was marketed in those first years–it was supposed to be the first
"appliance" machine, so I can see how non-users would get this impression.
But to developers this was just not the case.
Documentation was available from day 1 on the Amiga. Full disclosure of
all system calls, on many different levels, with all sorts of suggestions
on style, as opposed to dictated style. It's a different philosophy
altogether, and I prefer the openness of the Amiga by a long shot.
Tell me james, who wrote 'Inside MacIntosh' and why was it necessary?
Who wrote "Inside Macintosh"? Well, the Apple people who developed the Mac
system software of course (who wrote the Amiga's RKM, Intuition, or
AmigaDOS manuals? The people who wrote the Amiga system software of
course. Its the same situation).
And I still disagree with you. From a developer's standpoint there was
virtually NO difference in philosophy when the Mac was introduced vs. when
the Amiga was introduced. The "rigid guidelines" were not rigid in the
Mac documentation, any more than the "guidelines" in the Intuition manual
were rigid. They were simply more thought out and complete (and, unlike
RJ's ramblings in the Intuition manual, the Mac's suggested guidelines were
also internally consistent). There was nothing in the system whatsoever
that made people use these guidelines–as I stated before this was all due
to the marketing people who convinced software buyers that programs should
follow the guidelines.
I don't know where you got your ideas about what programming on the Mac is
like, but I can tell you from experience (I was working on both machines
the year, and almost the month, they were both released) that your
conceptions do not agree with what really happened.
I guess I shouldn't have believed the people that told me that the
information was just not there; that anything deeper than 'first level'
interfacing was actively discouraged and completely undocumented; that the
philosophy of the software closely mjatched that of the hardware, with
severe repercussions if ignored. The people that told me these things were
those trying to program the beast, before "Inside MacIntosh" came out.
Larry, there are what, seven! volumes of Inside Mac, plus Apple forums on
several networks where you can download text-and-graphic integrated tech
and app notes on how to do this stuff. They've got things documented up
the wazoo. Sure, there are kludges here and there, and Blish knows how
many revs of the OS they've had. Where are the supplementary docs from
CBM?
Yes! The Amiga Workbench / Intuition morass was not internally or
logically consistent, while the Mac was. The Mac system was obviously much
more thought out, meanwhile, all RJ can muster is "make it beautiful and
easy to use." Sorta like Intuition, huh, RJ? 🙂 Forcing users to the CLI
is the biggest crime on the Amiga, and so few of our blessed hackers care a
whit about user interface. Unless this attitude changes, until we have a
system that does not require the use of the CLI for anything, we'll always
be a second-class machine. And I'd be willing to write an article about
that, Malcolm. 🙂
I feel the same way. I'd rather ue WB if it did everything I can do
from CLI. Since it doesn't, I don't use WB at all. However, there are
factions (like Thomas) who feel that limiting it's power is reasonable,
well thought out, and as it should be. For me, WB should be all things to
all people. The Mac interface is very close. GEM's desktopisn't as close,
but much more so that WB.
Could it be that the reason many favor using the CLI over WB is the CLI's
very existance? If there were no CLI then any application that needed
keyboard parameters would either find them in TOOLTYPES or open a
requester for user input. Since the CLI _is_ available, most applications
accept command line parameters, but it's the CLI that does the work rather
than the application code. So isn't one of the issue's 'HOW TO PASS
PARAMS' ?
Now if we could figure out how to do it, it would seem more direct to click
on an icon…or press a single key…rather than to type:
DoItToIT >ram:outfile MyProject -quick -dirty
The question is how to provide all that variable information via point and
click.
Chuck,
You hit the nail: how to provide parameters via a mouse?!
We're struggling with this now on the CoCo. We've started writing PD GShell's
(our "Workbench"), because we hunger for more power. In the reverse from the
Amiga situation, we've had a shell (CLI) for over half a decade, and only
recently got icons. After years of doing things like:
( program -option file*.* ! spellchek >/r0/listxx; page <listxx >/p )&
[have Program pipe filenames to checker, with output to ramdisk file;
then send page-numbered listings to printer; all done "&" in the background]
Now we'd like to have the same power in our GShell. We partially can; a
user-defined icon can mean to run a script just like the one above. Some have
icons for a Make script to auto-compile their latest source, for example.
Anyway, we've talked some. Certainly the piping and redirection seems easy
enuf. Something like drag program on top of another program for pipe (or use a
pipe icon intermediary), and drag on top of printer for output. Drag file on
top of program for file to be one parameter.
You could have a popup mouse-directed keyboard on screen for parameters, which
is not perfect, but about the only way we can think of for variables. At least
you could still lean back in your chair (grin).
I'd love to hear any and all ideas. The one someone here had about a editable
CLI window echoing the equivalent of what you're mousing was a great idea, and
is going into our next GShell, btw.
Kevin
The nasty upshot of it all is that the things that a user is most likely to
want to change printer drivers – and there is no way to do that from the
WB. Or, delete extra, unneeded files from C: to free space on a crowded WB
– again, no way to do that. Or, modify or move new fonts from one disk to
another – again, no way to do it, and in the case of adding point sizes to
fonts, no way to do it rigP;KQPout additional, third-party software.
Steve, there's a font resizing program available with Gold Disk's "Font Set 1".
It works best if you're sizing to an even multiple of the original size. -Jim
For that amount of change, I think Calligrapher would do it just fine, too. If
you don't have Calligrapher, you might upload the font and I'll see if it makes
it without too much distortion.
Better font handling is in the Amiga's future, but probably quite a long way
off as part of the regular system. It HAS to come before the high-res monitor
will be very acceptable.
If you want to give it a try, I'd appreciate it. It's the ST font in the
Pointer/Fonts lib in AmigaArts (I believe it's called ST.ARC).
Bravo! I couldn't agree with those sentiments more. RJ is much too much
overblown in the Amiga world. And while I don't think there is anything
wrong with _using_ the CLI, I agree that to be _forced_ to use it because
the Workbench is so primitive and ill-concieved is a crime against the
Amiga.
Apple didn't think the core of their system software out too well (and they
are still paying for that), but they _did_ put a lot of thought into the
user interface–thoughts and studies in usability, consistency, and the
like. And it shows–even IBM is trying to catch up to the Mac in this
regard!
I got one of the original developer's machines from CBM, and along
with it got 7 volumes of documentation. That's not what I'd call minimal
by any stretch of the imagination.
Don
By minimal I was not referring to the volume of information, but rather to
the quality (I too got one of the original developer's machines with the
original documentation). The quality of the original Amiga documentation
is about on par with the quality of the original Mac documentation (the
Mac's documentation didn't fully come out with the machine's introduction
though. But there was only a month or two difference, so it really almost
the same thing).
Hehe, the RKM alone probably was 3-4 times what was available for the
Mac. The first time I looked through it I about died when I realized that
half of that phone book was 2 up for the includes and system call sheets.