Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!pyramid!claris!wombat From: wombat@claris.com (Scott Lindsey) Newsgroups: comp.sys.apple Subject: Re: The Nifty //GS and Apple Support Message-ID: <9107@claris.com> Date: 20 Mar 89 06:28:14 GMT References: <8903181758.aa00561@SMOKE.BRL.MIL> Organization: Claris Corporation, Mountain View CA Lines: 95 From article <8903181758.aa00561@SMOKE.BRL.MIL>, by LWELCH@COLGATEU.BITNET: > > If Apple has a desire to expand, fix, and support the OS and tools, what more > do you and other programmers at CLARIS want to see from Apple? What nifty > things have you written for the GS? AWGS is huge and too slow in many > respects. The people at CLARIS deserve congradulations for developing a >powerful application for the //GS and not a product that fits into Apple's "K-8 > Educational market" for the // family. Appleworks and Applworks GS show that > there is a demand forproductive, powerful, small business applications for the > // family. Yes, AWGS is big and is slow in some situations. I myself have called it a behemoth. The size is mainly due to the fact that we were so ambitious for this program. I believe it is the most fully integrated package in the market, period. Not just on the GS. Admittedly using multiple applications under Multi-finder on a Mac comes close, but the level of integration is not there. Yes, some of the slowness is our fault. Work does continue onward on AWGS: bug fixes, speed enhancements, etc. Personally, I don't really see myself as an application programmer. The things I enjoy most are utilities and glue-code etc. To give you an idea, here's what I did on AWGS: About 2/5 of page layout, mainly in user- interface... the rulers, the palette, etc. I also wrote all the charting code which provides an interface from the spreadsheet to the graphics. After that, it gets more difficult to point out: a mergesort routine used by database and spreadsheet; formatting of numbers in spreadsheet; selection routines for database; interface to lowlevel quickdraw cursor routines; and, of course, that nasty little alert that tells you your machine is dead (yes, the text of that is going to be changed. For those who care, Resume meant to resume what the computer was about to do: crash... into the monitor.) I've been working on the ImageWriter driver that Claris has licensed from Apple... A mindless memory tester to try and spot bad chips... Most other stuff is for internal use and probably won't ever see the light of public release (various DA's and utilities). All this is the sort of stuff that I don't consider powerful, nor especially useful to the common person... but it has its place. > But, since Scott has said that Apple is working on improving the tools and OS, > what else are the programmers at CLARIS looking for from Apple? Part of the > blame for the slowness of Appleworks GS needs to be taken on by the people at > CLARIS. I hope that they are working to improve the code of Appleworks GS so > that it can work faster. There are some indications of this, but I hope their > upgrades will go beyond fixing bugs in Appleworks GS and increase the speed and > features of the program as well. CLARIS shouldn't rely on Apple to produce all > of the improvements to their program simply through tool speedups and system > improvements. No, Claris is not depending on Apple for all the fixes. The point was that bugs in tools and OS make figuring out what's really wrong often impossible. Sometimes we end up trying to debug the tools. Fixes, speedups and enhance- ments are in the works (no pun intended). Beyond that I really shouldn't say. > I think that Appleworks GS is the best thing that could have happened to the // > family and the people at CLARIS deserve a lot of credit. The program reveals > shortcomings in Apple's hardware & tools and can help show the way towards > improvement in the // line at Apple. Appleworks GS establishes 1 Meg of RAM as > a minimum standard for future //GS's and shows that the // line can be > successful in the business market if Apple and software developers are willing > to put in enough effort. As I've said before, I think AWGS is a behemoth. I think that in designing it we failed to truly evaluate the abilities of the computer. We tried for too much. Yes, the tools and OS will/have grow(n) to accept the challange and we are fixing and elaborating AWGS, but I really think we might have been better off to have done something that was a little less useful and more usable. Maybe that might have breathed a bit more life into the GS. At the time we designed it though, we were StyleWare, looking for another product to keep a small business going... obviously we wanted to reach for all we could get. One other 'unfortunately': Unfortunately, we currently reccommend 1.25Mb for AWGS. It WILL run with only 1Mb, but those 256K really make a difference. _THAT_'s how close AWGS is to straining its confines. I also say 'currently'. It's possible we might be able to reduce that strain a bit, working toward more memory-efficient code, and improved tools... but don't hold your breath. Not yet. I'm not flaming Apple about the state of the tools etc. We have been work- ing with them, pointing out our biggest concerns. Right now we're pretty much in a wait state. I'm waiting to see what Apple can and will do with the GS. I'd really like to see it turn into a viable platform. Like Jeff, I fear that it may be to late. Unlike Jeff, I haven't quit waiting. -- Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air Claris Corp. | About an age of power when no one had an hour to spare" ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, wombat@claris.com | StyleWare, the author, or anyone else living or dead.