lrg7030@uxa.cso.uiuc.edu (Loren J. Rittle) (01/31/91)
Before I say another word: I just want to state, ``I have used and
programmed extensively both the Amiga and the Mac, so I at least have
a chance to know what I'm talking about.'' :-)
For the record:
I worked at the DOE's Ames Lab in Ames, IA on a Mac application under a
grant from the Federal Government for about a year and a half. We used
Prototyper and LightSpeed C.
I have programmed the Amiga for *fun* (it is truely a fun machine, I just
saw the jumping man from MED last night, extremely amusing) for the last 3
and a half years.
I will never program the Mac again for fun or money, the OS sucks. Life is
too short to waste time trying to figure out what the hell the MacOS is
trying to with its file systems!
I digress a bit:
If anyone knows how to create a directory (a folder to Mac people) in the
MacOS from *within* a user level program, I'd love to hear about it. Any
source code you send me, must create a folder exactly where I want it
(specified at compile time, say), non-interactively without any file
requestor type things involved. I claim it can't be done :-). Prove me
wrong :-) in e-mail, I will summarize the flood of responses I get :-).
PS, under AmigaOS this following line of code will create a new directory,
with the same constraints I gave above:
CreateDir("root:work/newdirname");
I've said it before and I'll say it again:
To [most] users, the MacOS looks great, but it is a programmer's hell.
In article <1991Jan31.011702.12095@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes:
>peter@sugar.hackercorp.com (Peter da Silva) writes:
>>In article <1991Jan25.075446.716@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes:
>>> Can your program get its hooks into this event BEFORE the OS gets
>>> hold of it and "do its own thing"?
>>Nope. You can tell Intuition the bounds you're willing to let the user manage
>>the window within, but that's it.
Peter, shame on you. Of course, a program can insert an Input Event
Handler and do whatever it pleases (of course this will most likely
displease the user...) with the raw events. It can ``do its own thing,''
but unless there is a good reason, an Amiga application had better not!
A much better solution is to write a program that changes the way some
functionality or another works for all programs, thus people who like
the change get it with *all* their current and future programs. See
below.
> Well this will probably cause some flames, but this is an example of
>where the Mac is MORE customizable than the Amiga... i.e. where the
>user can make things work the way he wants, not the way the OS wants.
No flames to you, I'm just setting you straight. :-)
The flames go to blind Mac users everywhere, you at least
seem interested in hearing why the Mac sucks. I can say this in
c.s.amiga.advocacy, right? :-)
I think Peter failed to mention an important fact related to the AmigaOS:
Any old user program, in general, *can* get its hooks into low-level events
and do anything they (the applications) want to do just like you have to do
under the MacOS, but as a convention user programs do not mess around with
this. And thank God they don't, because I and many other Amiga users have
special programs running on our systems called Input Event Handlers. These
programs are just like normal user programs, but I, at least, think of them
as system-level programs, as they usually have one goal in mind - modify
and/or react to the events as they come in to change or extend the way the
system performs these low-level window manipulation (for example) tasks.
I currently run four Input Event Handlers:
Snap - grab text and graphic from any screen and place it in the clipbroad.
DMouse - mouse accelerator, screen and window flipper, screen blanker
NewPop - screen blanker with auto/defeat-blanking, discreet titlebar clock,
- discreet titlebar CPU monitor, discreet titlebar SCSI IO monitor
- pop cli thingy, and Q*X blanker pattern
[ed note: NewPop is by Loren J. Rittle, hey that's me!]
XSize - modifies the way windows are resized
I list XSize last because it best illustrates why the Amiga method is
better: I, not some application writer, decided that I wanted a more
flexible method of resizing windows (*all* resizable windows) than the OS
provided for (i.e. drag the lower-right corner about the screen to resize
a window). XSize traps all conditions where the OS would resize a window
and takes over for it, allowing me to resize on any edge or corner.
With the Mac you're just stuck, with what Apple or some renegade
application writer thought was best.
Because this type of system-level code (resize window) is embedded in every
Mac application, the end user cannot change the functionality in any way,
wheras the AmigaOS supports a way of patching just about anything in the
system. I call this ``open.'' I don't know about your next statement.
> I am reminded of a quote in Steve Chernicoff's Macintosh Revealed
>book... paraphrasing, he said something like "When Apple released the
>Macintosh 128K, critics pounded it for being a closed system. While
>their criticisms of the hardware were well-founded, what they didn't
>realise was that the Macintosh had an almost completely open software
>design".
Well, I won't argue that Steve Chernicoff said that (I don't have
that book, I believe you that he said it :-), but I will say he must be
talking about a different kind of ``completely open software design,''
than I would imagine.
Mac Way:
1) Provide and document low level system support for a windowing system.
You get `mouse clicked in your window at loc. x,y' type messages (low level!)
2) Publish standards and code that will allow everyone to build up the same
higher level `look.'
``When *you* find a mouse click has landed in a resize box, take action
to follow the mouse, resizing the window when the user lets up the
button.'' etc, etc, etc.
3) Finally, of course, hope people follows them :-), they did :-).
End users are locked into what Apple or renegade application writers
thought was best.
Amiga Way:
1) Provide and document high level system support for a windowing system.
You get `Your window xxxx was resized, by the user to be 120x100 now'
type messages (high level!)
2) Provide a mechanism to change the default behavior of how these
system functions work.
3) Publish standards that will allow everyone to react the same way
to system messages.
4) Finally, of course, hope people follows them :-), they did
(well, they are now!) :-0.
In the Amiga, there is a standard way to change any aspect of the
system's functionality via the SetFunction() call. Any system
function can be modified in a system friendly way.
Whereas in the Mac, you *have* to kludge it. There is no standard
set way to replace a builtin functionality: there is always a hostile
take over involved.
> For example, all the hooks into window definition functions, menu
>definition functions, etc... where you can roll your own code, and
>make your own windows/menus etc... this is how the Mac gets all those
>nice NeXT/Motif type windows without having to rewrite existing
>program code.
Are you claiming that there are programs that can give a NeXT/Motif look to
all Mac windows, without recompiling each application? Actually, because
so much code is compiled into every application, I don't see how this could
work. If so, they are pulling some sort of magic by overriding some of the
application code to handle a window (I would guess). Or, are you claiming
that some applications now have this look because their programmer made
it so?
You can do this (give all windows a different look without recompiling
each application) on the Amiga quite easily because all the system code
to monkey about with low level details of windows is where it belongs in
the system routines. I know it makes sense, but the MacOS does not work
this way, alot of system-level code is in each and every application.
> While it means you may have to write more code to handle the general
>case, it gives you more control over the final result as well.
But then, if I want to change the default way something works in the
system, I have to recompile *every* application for the change to take
effect... Look what happened when Apple added the Zoom box :-). AmigaOS
2.0 adds a Zoom box, in fact Commodore totally changed the layout and
functionality of the standard system gadgets, and no code will need to be
recomiled to take advantage of the changes. Apple cannot make this sort
of change anymore, they are stuck in 1984!
>>Amiga scrollbars (proportional gadgets) don't have arrows. If you see an arrow
>>the application is managing two gadgets together. But if you want to know how
>>Intuition (which, by the way, is not the O/S, it's just another task) knows how
>>far you can frag a scrollbar with the mouse, I can tell you that: the
>>application tells it how far it can move the knob.
> Can you have callback functions.. i.e. get Intuition to call your
>function while it's moving the knob?
Yup, this is a very sensible way to do it. You can set it up so it looks
very OOish. Actually what happens, is Intuition sends your program a
message saying that the knob with id xxxxxxxx moved, you can then use
some sort of dispatcher to implement the callback mechanism.
--
``In short, this is the absolute coolest computer device ever invented!''
-Tom Denbo speaking about The VideoToaster by NewTek
``your pathetic architectures won't support it'' - Kent Paul Dolan
``Think about NewTek's VideoToaster! Now think about the Amiga!''
Loren J. Rittle lrg7030@uxa.cso.uiuc.eduyorkw@stable.ecn.purdue.edu (Willis F York) (01/31/91)
Xsize Sounds Nifty. Where'd ya find it? (Or did ya make it yaself..) ps: Macs have a "idiot-resistant" interface in my oponion.. -- yorkw@ecn.purdue.edu Willis F York ---------------------------------------------- Macintosh... Proof that a Person can use a Computer all day and still not know ANYTHING about computers.
peter@sugar.hackercorp.com (Peter da Silva) (02/03/91)
In article <1991Feb1.075535.369@Neon.Stanford.EDU>, torrie@cs.stanford.edu (Evan J Torrie) writes: > For example, I now have probably 5 routines sitting on GetNextEvent > before it actually gets to the application program... among them are > macro programs, screen clippers, clocks in the menu bar, easy ^^^^^^^^^^^^^^^^^^^^^^ > launching utilities.. On the Amiga you just run a clock program with a small window over the menu bar. Why add to the load of handling events? Just run a program that sleeps for 1 second at a time, taking up virtually no CPU time. On AmigaOS 2.0 a formerly freely redistributable program called "Commodities Exchange" has been included with the system. This program manages input handlers better, further reducing their overhead. Efficiency is still a concern at Commodore, unlike some companies. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.