ls1i+@andrew.cmu.edu (Leonard John Schultz) (10/14/90)
On 07-Oct-90 in UNIX is yuck (was Re: Next .. user pfr654@csc.anu.oz.au writes: >I am a long time Mac user and have just recently had to learn some UNIX for >a Decstation 3100. > >IT IS HORRIBLE! > >UNIX is an ancient operating system! Invented in the time of dinasour >computers with less power than a Mac Plus!! > >It may have some multitasking/virtual memory features that the MacOS does >not have at present, but when the Mac gets there it will blow UNIX away! > >I know that UNIX can be made to do just about anything, and that Apple's >A/UX can now run 32 bit clean Mac programs in a Mac-like manner, BUT if you >are forever putting nice front ends onto an OS why not start at the start >and have a nice OS (from the user's point of view anyway)? I believe we are missing the point of the original post that started this string. That is, is the Apple in trouble with the intro of the new NeXTs. I believe so. Why? becaust NeXTstep is incredibly intuitive and "mac like", but has all of the power and customizability of Mach (unix) underneath. Nobody is denying that unix is more powerful than the simplistic Mac OS. Except for this one person who thinks that multitasking is all there is to unix. Mach contains everything that System 7.0 is promising and more, and it has it NOW! No more release dates being pushed back 6 months. (Did you know that the Mac OS does not support the DMA in the IIfx and 7.0 won't either?) Out of all of you people who have been ragging on unix, how many of you have actually used the NeXT and NeXTstep? I suggest you try it. It is incredibly easy to use. You could swear that you were working on a Macintosh with a much nicer looking interface. You never have to see the unix heritege if you don't want to. You can play with your windows, icons, menus, and do simple "control panel" customizations until your arm fall off and never have to type something in at the command line. Just as NeXT has bee tauting it, Unix for mere mortals! Once you've seen one NeXT application, you've seen them all because of the common, consistant user interface. And if you want to do some programming, the power of unix is there for the taking. That is the one thing I always hated about Mac. It is so close ended and so difficult to write a simple program or utility. That's why I am selling my mac and just put an order in for a color NeXTstation with 3 times the memory of a IIfx, 3 times the speed, 2 times the hard drive space, 4 times the hard drive transfer rate, 200 times the networking speed, 20 times the number of colors, 2 times the floppy size, 4/3 times the screen and printer resolution, larger screen, all for less than HALF the cost (at university prices). I left out alot of the hardware that the NeXT has that the Mac has no equivalent for. Len Schultz Carnegie Mellon University
russotto@eng.umd.edu (Matthew T. Russotto) (10/16/90)
In article <4b5vB5e00UhBA=gi8V@andrew.cmu.edu> ls1i+@andrew.cmu.edu (Leonard John Schultz) writes: >On 07-Oct-90 in UNIX is yuck (was Re: Next .. >user pfr654@csc.anu.oz.au writes: >Why? becaust NeXTstep is incredibly intuitive and "mac like", but has >all of the power and customizability of Mach (unix) underneath. Nobody >is denying that unix is more powerful than the simplistic Mac OS. >Except for this one person who thinks that multitasking is all there is >to unix. Mach contains everything that System 7.0 is promising and >more, and it has it NOW! No more release dates being pushed back 6 >months. (Did you know that the Mac OS does not support the DMA in the >IIfx and 7.0 won't either?) Nope, haven't heard that last bit... A/UX supports it, though. BTW, just when is the NeXTStation going to ship in quantity? >Out of all of you people who have been ragging on unix, how many of you >have actually used the NeXT and NeXTstep? I suggest you try it. It is >incredibly easy to use. You could swear that you were working on a >Macintosh with a much nicer looking interface. You never have to see >the unix heritege if you don't want to. You can play with your windows, >icons, menus, and do simple "control panel" customizations until your >arm fall off and never have to type something in at the command line. >Just as NeXT has bee tauting it, Unix for mere mortals! Once you've >seen one NeXT application, you've seen them all because of the common, >consistant user interface. And if you want to do some programming, the >power of unix is there for the taking. But on the original cube, it is so SLLLOOWWWWW. You'd swear you were using an TIMEX-SINCLAIR emulating a Mac. That alone outweighs much for me-- I want a responsive interface. When I click, I want a response-- NOW! >That is the one thing I always hated about Mac. It is so close ended >and so difficult to write a simple program or utility. With Think C or MPW 2.02, it isn't hard at all. >That's why I am selling my mac and just put an order in for a color >NeXTstation with 3 times the memory of a IIfx, 3 times the speed, 2 >times the hard drive space, 4 times the hard drive transfer rate, 200 >times the networking speed, 20 times the number of colors, 2 times the >floppy size, 4/3 times the screen and printer resolution, larger screen, >all for less than HALF the cost (at university prices). I left out alot >of the hardware that the NeXT has that the Mac has no equivalent for. Tell us when you get it. I have my Mac II now. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
melling@cs.psu.edu (Michael D Mellinger) (10/16/90)
In article <1990Oct15.224912.26056@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: [stuff deleted] But on the original cube, it is so SLLLOOWWWWW. You'd swear you were using an TIMEX-SINCLAIR emulating a Mac. That alone outweighs much for me-- I want a responsive interface. When I click, I want a response-- NOW! >That is the one thing I always hated about Mac. It is so close ended >and so difficult to write a simple program or utility. With Think C or MPW 2.02, it isn't hard at all. >That's why I am selling my mac and just put an order in for a color >NeXTstation with 3 times the memory of a IIfx, 3 times the speed, 2 >times the hard drive space, 4 times the hard drive transfer rate, 200 >times the networking speed, 20 times the number of colors, 2 times the >floppy size, 4/3 times the screen and printer resolution, larger screen, >all for less than HALF the cost (at university prices). I left out alot >of the hardware that the NeXT has that the Mac has no equivalent for. Tell us when you get it. I have my Mac II now. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus. The NeXT will ship in quantity in November; they're waiting on the 040. The original NeXT has a little more horsepower than the IIci(perhaps a lot more considering DMA support..etc). The display postscript(and Unix) makes it feel slow. The NeXT is a great machine, and (IMHO) the best buy for under $10,000. However, I still like the Mac, and hope they sell millions more. Apple only has 10% of the market! NeXT is their punishment for not taking more of a market when they had an easy chance to do it. I would be happy if NeXT only garnered %10 of the market, and Apple the other 90%. In fact, I would be estatic. Both companies can be successful. The computer industry will be better if THEY BOTH SUCCEED. -Mike
loca@well.sf.ca.us (John Hoag) (10/22/90)
> With Think C or MPW 2.02, it isn't hard at all.
...once you've written a few hundred lines of environment-handling code
in preparation for printing "Hello World." gft_robert@gsbacd.uchicago.edu (10/22/90)
----- In article <21288@well.sf.ca.us>, loca@well.sf.ca.us (John Hoag) writes... >> With Think C or MPW 2.02, it isn't hard at all. > >....once you've written a few hundred lines of environment-handling code >in preparation for printing "Hello World." Or used Prototyper or AppMaker to "draw" your application and produce the code. Or used the THINK Class Library or MacApp to handle most of the interface for you. (BTW, I use none of these, since I prefer Macho-Coding-And-Total-Control (tm) :->, but they are certainly viable and easier routes. A la NextStep). Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
aslakson@cs.umn.edu (Brian Aslakson) (10/22/90)
loca@well.sf.ca.us (John Hoag) writes: >> With Think C or MPW 2.02, it isn't hard at all. >...once you've written a few hundred lines of environment-handling code >in preparation for printing "Hello World." This is my favorite post of the week. Brian -- .signature: No such file or directory; really.
philip@pescadero.Stanford.EDU (Philip Machanick) (10/23/90)
In article <21288@well.sf.ca.us>, loca@well.sf.ca.us (John Hoag) writes: |> > With Think C or MPW 2.02, it isn't hard at all. |> |> ...once you've written a few hundred lines of environment-handling code |> in preparation for printing "Hello World." The Mac may be a lot more difficult to program than it needs to be, but let's stick to the facts. I don't know about Think C or MPW, but this statement implies that there is no way of writing trivial programs on the Mac. In THINK Pascal, you can use ordinary ANSI-Pascal IO. Here's your "Hello World" program: program hello; begin showtext; writeln('hello world'); end. (you may want to add a readln to the end to stop the window disappearing until RETURN is typed). And you _do not_ have to write hundresd of lines to do the same in a dialog box. Of course, once you get into non-trivial programs, things aren't too pretty. -- Philip Machanick philip@pescadero.stanford.edu
rwt@ohm.york.ac.uk (Richard Taylor) (10/23/90)
in article <1990Oct22.050657.28031@midway.uchicago.edu>, gft_robert@gsbacd.uchicago.edu says: > > Or used Prototyper or AppMaker to "draw" your application and produce the code. Has anyone on the net got direct experience of either the above ? I am writinng most of my code in Light Speed C, an interface builder would be very nice. Richard -- ****************************************************************** * Dr R W Taylor tel : (44) 904 432351 fax : 432353 * * Adaptive Systems Group email : rwt1@uk.ac.york * * University of York, England *
francis@giza.cis.ohio-state.edu (RD Francis) (10/23/90)
Someone wrote: [you can't even do hello world on a Mac without writing a couple hundred lines of environment set-up code.] Someone else wrote: [Not true in THINK Pascal] Also not true in THINK C; the stdio library sets up a default window for you to run relatively standard C code in. I think that things get more complex as soon as you move away from stdin/stdout, though. I don't know because I've never gotten around to doing much more than hello world with my copy of THINK C :-) -- R David Francis francis@cis.ohio-state.edu
dave@PRC.Unisys.COM (David Lee Matuszek) (10/23/90)
In article <1990Oct22.213553.20022@Neon.Stanford.EDU> philip@pescadero.stanford.edu writes: >The Mac may be a lot more difficult to program than it needs to be, but let's >stick to the facts. I don't know about Think C or MPW, but this statement >implies that there is no way of writing trivial programs on the Mac. In THINK >Pascal, you can use ordinary ANSI-Pascal IO. Here's your "Hello World" >program: > >program hello; >begin > showtext; > writeln('hello world'); >end. Let's stick to the facts. This program only works in the THINK Pascal environment. If you want to compile it as a stand-alone program, things get a couple orders of magnitude more difficult. (I haven't upgraded to 3.0 yet, things may have improved...slightly.) -- Dave Matuszek (dave@prc.unisys.com) -- Unisys Corp. / Paoli Research Center / PO Box 517 / Paoli PA 19301 -- Any resemblance between my opinions and those of my employer is improbable. < You can put a mouse on an IBM. And you can put a radio on a motorcycle. >
philip@pescadero.Stanford.EDU (Philip Machanick) (10/24/90)
In article <15356@burdvax.PRC.Unisys.COM>, dave@PRC.Unisys.COM (David Lee Matuszek) writes: |> In article <1990Oct22.213553.20022@Neon.Stanford.EDU> philip@pescadero.stanford.edu writes: |> |> >The Mac may be a lot more difficult to program than it needs to be, but let's |> >stick to the facts. I don't know about Think C or MPW, but this statement |> >implies that there is no way of writing trivial programs on the Mac. In THINK |> >Pascal, you can use ordinary ANSI-Pascal IO. Here's your "Hello World" |> >program: |> > |> >program hello; |> >begin |> > showtext; |> > writeln('hello world'); |> >end. |> Let's stick to the facts. This program only works in the THINK Pascal |> environment. If you want to compile it as a stand-alone program, |> things get a couple orders of magnitude more difficult. (I haven't |> upgraded to 3.0 yet, things may have improved...slightly.) I have written programs in which this worked just fine. I do recall having a problem with one of the earlier versions of Think Pascal, which tended to crash after running standalone if I used the text window (when running a Mac II specifically), but this was years ago. I don't have a Mac in my office, so if you want to tell me I'm wrong, get a copy of a _recent_ version of Think Pascal, type in the program and tell me what happens if you try to run it standalone. Let's stick to the empirically verifiable facts... -- Philip Machanick philip@pescadero.stanford.edu
rgm@OCF.berkeley.edu (Rob Menke) (10/24/90)
In article <1990Oct22.213553.20022@Neon.Stanford.EDU> philip@pescadero.Stanford.EDU (Philip Machanick) writes: In article <21288@well.sf.ca.us>, loca@well.sf.ca.us (John Hoag) writes: |> > With Think C or MPW 2.02, it isn't hard at all. |> |> ...once you've written a few hundred lines of environment-handling code |> in preparation for printing "Hello World." The Mac may be a lot more difficult to program than it needs to be, but let's stick to the facts. I don't know about Think C or MPW... In MPW, if you compile a program as a 'tool' rather than as an 'application,' the stdio is redirected to and from the shell. Really nice if you want to port simple UNIX programs to your Mac... -- "Collision imminent...." | Robert Menke "Energize the force fields!" | rgm@OCF.berkeley.edu "What force fields?" | ...!ucbvax!OCF!rgm
mxmora@unix.SRI.COM (Matt Mora) (10/24/90)
In article <15356@burdvax.PRC.Unisys.COM> dave@PRC.Unisys.COM (David Lee Matuszek) writes: >In article <1990Oct22.213553.20022@Neon.Stanford.EDU> philip@pescadero.stanford.edu writes: >> writeln('hello world'); >>end. > >Let's stick to the facts. This program only works in the THINK Pascal >environment. If you want to compile it as a stand-alone program, >things get a couple orders of magnitude more difficult. (I haven't >upgraded to 3.0 yet, things may have improved...slightly.) > >-- Dave Matuszek (dave@prc.unisys.com) I just tried the said program and it works as a stand alone application. I used THINK Pascal 3.0 I just wanted to point out that fact. -- ___________________________________________________________ Matthew Mora | my Mac Matt_Mora@sri.com SRI International | my unix mxmora@unix.sri.com ___________________________________________________________
russotto@eng.umd.edu (Matthew T. Russotto) (10/24/90)
In article <RGM.90Oct23141652@sandstorm.Berkeley.EDU> rgm@OCF.berkeley.edu (Rob Menke) writes: >In article <1990Oct22.213553.20022@Neon.Stanford.EDU> >philip@pescadero.Stanford.EDU (Philip Machanick) writes: > > In article <21288@well.sf.ca.us>, loca@well.sf.ca.us (John Hoag) writes: (I wrote the next line) > |> > With Think C or MPW 2.02, it isn't hard at all. > |> > |> ...once you've written a few hundred lines of environment-handling code > |> in preparation for printing "Hello World." > The Mac may be a lot more difficult to program than it needs to be, but let's > stick to the facts. I don't know about Think C or MPW... > >In MPW, if you compile a program as a 'tool' rather than as an >'application,' the stdio is redirected to and from the shell. Really >nice if you want to port simple UNIX programs to your Mac... Which is one reason I mentioned MPW 2.02. The above program will work fine, really! The console routines were already written in 2.02. Same with THINK C-- heck, they even give you source. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
KPURCELL@LIVERPOOL.AC.UK (10/28/90)
In article <1990Oct22.213553.20022@Neon.Stanford.EDU>, philip@pescadero.Stanford.EDU (Philip Machanick) says: > >In article <21288@well.sf.ca.us>, loca@well.sf.ca.us (John Hoag) writes: >|> > With Think C or MPW 2.02, it isn't hard at all. >|> >|> ...once you've written a few hundred lines of environment-handling code >|> in preparation for printing "Hello World." >The Mac may be a lot more difficult to program than it needs to be, but let's >stick to the facts. I don't know about Think C or MPW, but this statement >implies that there is no way of writing trivial programs on the Mac. In THINK >Pascal, you can use ordinary ANSI-Pascal IO. Here's your "Hello World" >program: > >program hello; >begin > showtext; > writeln('hello world'); >end. > >(you may want to add a readln to the end to stop the window disappearing until >RETURN is typed). And you _do not_ have to write hundresd of lines to do the >same in a dialog box. Of course, once you get into non-trivial programs, >things >aren't too pretty. >-- >Philip Machanick >philip@pescadero.stanford.edu Strange as it may seem I wrote almost this program this even to see if I could still remeber how to do Pascal I/O on the Mac. Of course I fluffed it and forgot the showtext() call. These macs they force you to do all sorts of unatural things just to get stuff on the screen :-) BTW (the serious bit) some folks have said use MacApp or Think Class Libraries to 'object-orientate' your way around the difficulties with a Mac. Well this doesn't work because you still have to know IM from top to bottom and (in the case of TCL) you have to keep 4 different hierarchies in you head at the same time (I still don't understand that, and I ain't an idiot!). I know OOP ideas are worthwhile, but trying to learn the Mac and a new system of programming at the same time is just too much. The simplest solution I've found is to use TransSkel (and TransEdit and TransDisplay). They take all the donkey work out of building simiple applications, you can write a 20 line application, to do Hello World and it will automatically cope with the Apple menu and DAs and moving windows and ....... You get the drift. Availible for both THINK C and Pascal from indri.primate.wisc.edu. Kevin Purcell | kpurcell@liverpool.ac.uk Surface Science, | Liverpool University | Programming the Macintosh is easy if you understand Liverpool L69 3BX | how the Mac works and hard if you don't. -- Dan Allen
aard@sdcc13.ucsd.edu (Arcturian Mega-Dude ) (10/29/90)
In article <90301.081741KPURCELL@LIVERPOOL.AC.UK>, KPURCELL@LIVERPOOL.AC.UK writes: > >|> > With Think C or MPW 2.02, it isn't hard at all. > >|> > >|> ...once you've written a few hundred lines of environment-handling code > >|> in preparation for printing "Hello World." > >The Mac may be a lot more difficult to program than it needs to be, but let's > >(you may want to add a readln to the end to stop the window disappearing until > >RETURN is typed). And you _do not_ have to write hundresd of lines to do the > >same in a dialog box. Of course, once you get into non-trivial programs, > >things > >aren't too pretty. > >-- > >Philip Machanick Actually, it's not really that bad. Here's the exact program I used to test the ANSI C library in THINK C: main () { printf('Hello World!\n'); } Yep, it not only works, it works beautifully. But let's put this all in perspective. If you need to simply "crank out code" and don't give a hoot about user interface, fine - use the ANSI C libraries. But if you want to produce an application that follows the human interface guidelines and is easy to use then you use the Mac toolbox routines. Yes, the toolbox routines force you to use many more lines of code but look at what you get: You get windows, pull-down menus and an interface that is consistant across many applications. How many lines of code do you think it would take to do pull-down menus, etc. with an MS-DOS machine (for example)? First of all you couldn't use the standard text mode, second of all you couldn't just call these toolbox routines, you'd have to WRITE them! Anyway, my point is that the Mac let's you do both. You can write good ol' fashioned ANSI programs OR you can support the interface. I think that the extra code is worth it. -- Anthony C. Ard ..................................................... :-) University of California, San Diego ................. Cognitive Science InterNet:tony@sdcc13.ucsd.edu BitNet:tony@ucsd UUCP:tony%sdcc13.UUCP@ucsd GEnie:A.C.ARD USmail:3933 Jewell B-5 San Diego, CA 92109 (619) 272-0824
pascal@CAM.ORG (Pascal Gosselin) (10/30/90)
KPURCELL@LIVERPOOL.AC.UK writes: >In article <1990Oct22.213553.20022@Neon.Stanford.EDU>, >philip@pescadero.Stanford.EDU (Philip Machanick) says: >> >>In article <21288@well.sf.ca.us>, loca@well.sf.ca.us (John Hoag) writes: >>|> > With Think C or MPW 2.02, it isn't hard at all. >>|> >>|> ...once you've written a few hundred lines of environment-handling code >>|> in preparation for printing "Hello World." >>The Mac may be a lot more difficult to program than it needs to be, but let's >>stick to the facts. I don't know about Think C or MPW, but this statement >>implies that there is no way of writing trivial programs on the Mac. In THINK >>Pascal, you can use ordinary ANSI-Pascal IO. Here's your "Hello World" >>program: >> >>program hello; >>begin >> showtext; >> writeln('hello world'); >>end. >> >>(you may want to add a readln to the end to stop the window disappearing until >>RETURN is typed). And you _do not_ have to write hundresd of lines to do the >>same in a dialog box. Of course, once you get into non-trivial programs, >>things >>aren't too pretty. >>-- >>Philip Machanick >>philip@pescadero.stanford.edu >Strange as it may seem I wrote almost this program this even to see if >I could still remeber how to do Pascal I/O on the Mac. Of course I >fluffed it and forgot the showtext() call. These macs they force >you to do all sorts of unatural things just to get stuff on the screen :-) >BTW (the serious bit) some folks have said use MacApp or Think Class >Libraries to 'object-orientate' your way around the difficulties with a >Mac. Well this doesn't work because you still have to know IM from >top to bottom and (in the case of TCL) you have to keep 4 different >hierarchies in you head at the same time (I still don't understand >that, and I ain't an idiot!). I know OOP ideas are worthwhile, but >trying to learn the Mac and a new system of programming at the same >time is just too much. >The simplest solution I've found is to use TransSkel (and TransEdit and >TransDisplay). They take all the donkey work out of building simiple >applications, you can write a 20 line application, to do Hello World >and it will automatically cope with the Apple menu and DAs and moving >windows and ....... You get the drift. >Availible for both THINK C and Pascal from indri.primate.wisc.edu. >Kevin Purcell | kpurcell@liverpool.ac.uk >Surface Science, | >Liverpool University | Programming the Macintosh is easy if you understand >Liverpool L69 3BX | how the Mac works and hard if you don't. -- Dan Allen I am presently writing ultra-simple front ends to 'standard' Pascal and C applications with the help of PROTOTYPER. Prototyper lets you design the Mac user interface, and it generates the code for you (the skeleton (event loop), one 'Unit' per window/dialog, etc... and all the resources too). I simply look at the code produced, add whatever I need to get the user's input into MY routines... Voila! Instant Mac applications !!! Now, this may sound easy, but it won't let you exactly write Mac Write II in a few hours.... It has (I have version 2.1) no code to handle scrolling, 'File' dialogs and (the biggest problem) no code to handle printing (another seemingly impossible thing to do on a Mac !!!). Of course, there's presently NO WAY you can sanely write a Mac application without Inside Macintosh I-III (bare minimum). And if you HAVE to use MPW (I don't have a choice, due to the need for shared libraries in the C code that I use), now that's another not-so-obvious package to learn ( THANK GOD FOR COMMANDO DIALOGS, I would have gotten nowhere without these!!!). Think C/Pascal users have it easy, trust me. The NeXT interface builder and associated dev. tools seem to be the real future when it come to developing "hybrid" apps. -- +----------------------------------------------------------------------------+ | Pascal Gosselin | Internet: Pascal@cam.org Applelink: CDA0585 | | Gest-Mac Inc. Apple VAR | Voice (514) 767-4444 Fax (514) 767-7337 | +----------------------------------------------------------------------------+
gwills@maths.tcd.ie (Graham Wills) (10/31/90)
In article <90301.081741KPURCELL@LIVERPOOL.AC.UK> KPURCELL@LIVERPOOL.AC.UK writes: > >BTW (the serious bit) some folks have said use MacApp or Think Class >Libraries to 'object-orientate' your way around the difficulties with a >Mac. Well this doesn't work because you still have to know IM from >top to bottom and (in the case of TCL) you have to keep 4 different >hierarchies in you head at the same time (I still don't understand >that, and I ain't an idiot!). I know OOP ideas are worthwhile, but >trying to learn the Mac and a new system of programming at the same >time is just too much. > Well, no. If you use MacApp you don't need to look ata *lot* of IM. Let's have a browse: (I'll have to use IM2 as an example as I seem to have mislaid IM1. This is not a fix) 1) Memory - you need to know most of this 2) Segment Loader - none 3) OS Event Manager - none 4) File manager - most 5) Printing -none (joy!) 6) Device manager - none 7) Disk Driver - none 8) Sound driver - depends on your application. 9) Serial drivers - ditto 10) Appletalk - ditto 11) VBL manager - none 12) Sys err handler - none 13) OS Utilities -Yes 14) DIP Package - none 15) FP Arithmetic -none So unless you're writing a disk initialization package running across appletalk using the sound manager and other peripherals to handle sys errs which uses the vertical retrace manager, you don't need to know very much IM. My favurite bit is that with absolutely no knowledge of how either MacApp or the Mac itself handles printing, I can print my colour maps out to Laserwriters and HP colour printers using full Mac interface and intelligent error handling. Then again the memory management is so good that ... etc.
KPURCELL@LIVERPOOL.AC.UK (11/06/90)
In article <1990Oct29.231127.3763@CAM.ORG>, pascal@CAM.ORG (Pascal Gosselin) says: >I am presently writing ultra-simple front ends to 'standard' Pascal and >C applications with the help of PROTOTYPER. > >Prototyper lets you design the Mac user interface, and it generates the >code for you (the skeleton (event loop), one 'Unit' per window/dialog, >etc... and all the resources too). The other choice is AppMaker -- and from what I hear it may be a better choice. I received this mail when I was looking into getting one or the other a short time ago: Does anybody know if any of the big mail-order houses is discount AppMaker? I think it generating code for THIBK Class libaries is a big win (but not much use if your using Pascal -- I think Prototyper supports Pascal). Comments from a review in MacUser: The code generated by AppMaker looked better and was about 3 times smaller than that for Prototyper. Kevin Purcell | kpurcell@liverpool.ac.uk Surface Science, | Liverpool University | Programming the Macintosh is easy if you understand Liverpool L69 3BX | how the Mac works and hard if you don't. -- Dan Allen ------------------------------------------------ Date: Fri, 13 Jul 90 13:12:46 -0500 From: Jonathan Mills <jwmills@edu.indiana.cs.iuvax> To: KPURCELL@uk.ac.liverpool, tcm@edu.rochester.cs.cayuga Subject: AppMaker Cc: jwmills@edu.indiana.cs.iuvax I have been using AppMaker for the past four months. It is a good _tool_ but it is by no means magic, particularly in the design of the user interface. In fact, AppMaker alone is insufficient to design the interface, and should be used with ResEdit. This is not to say that AppMaker is bad, simply that the last 5% of your design will probably require some twitches with ResEdit. Examples: 1. Designing a pop-up menu in 9 point Geneva font. You must use ResEdit to change the AppMaker templates so that windows use a font other than Monaco 12; or you must remember to add code to your C source. You must also resize the pop-up box using the Get Info.. AppMaker dialog; if you move it around be prepared to resize it again, as AppMaker will reset the box to its defaults. 2. Use the window font in a button. You must change the ProcID of the button by adding 8, in ResEdit. 3. Remove unused picture resources. You must delete them with ResEdit. Once a picture is in the AppMaker .rsrc file, it is not deletable with AppMAker. Also a warning: Very occasionally, but regularly, if you cut a resource such as a picture button out of a window or dialog, the AppMaker .rsrc file will be damaged beyond repair. Somehow the file is blanked, perhaps because the EOF mark is set to the point just after the previous resource, but the file cannot be recovered even by twiddling with MacTools, etc. So, I always make a copy of the AppMaker file before I begin to edit it. Some good points: AppMaker code is concise and readable. This is because the C generation is done with templates specific to a language system or sub-system. Think C, MPW C, and Think C with Class Library _all_ have different templates. In fact, you can't switch from one to the other without re-generating code; compiling alone may cause the application to bomb. I use Think C, and have found that AppMaker's automatic generation of "stubs" was tailor-made for structured programming. Wherever you must write user- defined code, there AppMaker puts a stub. It is trivial to collect these stubs into your own code's modules. It is also necessary: if you modify the interface, and regenerate code with AppMaker, you will _lose_ all of the code you added to the module. (Sonce you may want to modify a module sometimes, it is best to collect these modules and put them in a sub-folder during code generation.) In closing, although this message may sound negative, it really isn't, and I **strongly** recommend AppMaker. It does most of a typical Mac interface automatically; it allows custom design of picture buttons, palettes & sliders; it does picture menus; it has source for its CDEFs; it can be customized to generate code; the technical support is *incredibly* good and the staff at Bowers Development very responsive; and they are working to improve the product: tear-off windoids, "sticky" controls in resizable windows, picture pop-up menus and more are all in the works based on their user's suggestions. I don't work for them, but spent a week or so bugging the staff daily until I had the hang of AppMaker. (This was in part because my interface is simple but thus not what the applicaion was intended to support. However I have been able to do most of it with AppMaker after a little thought. If you want to see my interface, which is an example of most of AppMaker's features, perhaps I can find a way to send you the Stuff'ed & BinHexed application.) Sincerely, Jonathan