From: sm86+@andrew.cmu.edu (Stefan Monnier)
Newsgroups: comp.sys.atari.st
Subject: Re: GEM.. what needs to be fixed, and soon!
Date: 27 Aug 92 17:11:06 GMT
Organization: Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.atari.st: 27-Aug-92 GEM.. what needs to
be fixe.. Mr Stephen R Usher@ucl.a (3256)


> From what I've heard, the new version of GEM for the FALCON seems a great
> improvement. I hope that at least some of the following gripes I have with
> GEM are fixed, and the rest to be fixed ASAP if the Atari machines are to
> get anywhere:-

> (1) Response time for mouse button presses.

> 	Has anyone noticed that it takes about a second for a mouse press to
> be acted upon under GEM? This delay is the same on the TT as on the ST. This
> has put off a large number of people when I've tried to promote the ST/TT
> for general use. It can be a right pain when you click on one item, move the
> mouse and the system highlights the one your mouse just passed over.

Well, the same problem exist on Macs. And it is not so easily corrected: the
problem is with the double click: how could you know at the first click
if there 
will be a second one or not ? You HAVE to wait. I know, you don't need to wait 
when the click is long: it means it is a 'click-n drag' and that could
be improved !

> (2) Printer drivers have to be assigned at INSTALL time or by editing a
> 		file.

> 	This is a MAJOR failing. Call the system user friendly? Even the
> first version of MS Windows had the capability to select the type of printer
> driver from a menu at any time.

> (3) GDOS is an optional extra.

> 	In these days any GUI-frontend without a built in scalable font
> generator is doomed. In my opinion a GDOS derivative (scalable font version)
> should be included IN ROM along with a minimum of fonts (eg Times Roman,
> Helvetica etc).

Why in ROM in these days (just think of Macs, OS/2, Windows, Unix, etc..) ?
I personnally think that much more of the OS should come on disk ! (for
faster and easier updates)

> (4) The low-level character of the GEM interface.

> 	In my opinion, the programming interface to GEM is too low level to
> be of much use to simple applications developers. If a higher level STANDARD
> library could be developed and released to the public FREE OF CHARGE (but
> NOT free of copyright) I believe the amount and the quality of GEM
> applications would increase by a great deal. This library should preferably
> be available in all the generally available formats, ie DRI, GCC, Turbo C
> etc. It should include (with the coming of such things as MultiTOS) the
> possibility of interrupt driven user interfaces (ie set up your handlers,
> tell GEM to get on with calling them then get on with your processing task,
> handy for processor intensive tasks which need to be able to cope with
> something such as a window resize/redraw/repair). Maybe it could be just a X
> emulation library (I know, straight X is horrid)with all the support
> libraries. This would at least increase the number of possible applications
> on the machines manyfold and give the machine a "standard" coding API.

That true (but I'm not sure whether better interfaces are common on other 
architectures right now). ACS is a good way in that direction (for those who
don't know, it is a kind of 'interface builder' for GEM: a great
improvement over
RCSs). An OO standard language could also be an answer: why not switch to C++
(also I would personnally prefer Eiffel) instead of C ?

> (5) The low speed of the VDI routines.

> 	The speed of plotting a pixel on the screen using VDI on the TT is
> so slow... dumping a 320x240 picture using point plotting with VDI can take
> up to a minute.. the is UNACCEPTABLE. The fastest possible algorithms for
> the hardware should be used, else developers will just hack the system and
> cause incompatibilities. This is bad for everyone.

VDI is slow, that's true. BUT there is NVDI, which is much better and faster !
(of course it is not really part of the standard OS, bad luck). After
all, you'll have
to get used to slow routines: Xwindows, Display postscript, and the
likes are slow !

> Please note that I'm not saying MS windows or MacOS is the way to go... or
> my machine in better than your machine. I'm just trying to say what I
> believe needs to be done to make the Atari version of GEM a modern and
> attractive (in the view of developers) GUI.

I completely agree with you ! None of the widespread current OSes is good !
TOS is a bit 'older' than others. It needs much work. Maybe in 10 years
? Just wait'n see !

> Steve

> Please don't flame me, I'm just trying to help! :-)

> PS. Not having done too much programming using GEM I may well be wrong about
> the API, but I still think, whatever, that point 4 has at least some
> validity.
> --
> Addresses:-
> JANET:-		ucacmsu@uk.ac.ucl or	steve@uk.ac.ox.earth (preferable)
> Internet:-	ucacmsu@ucl.ac.uk or	steve@earth.ox.ac.uk (preferable)


Stefan Monnier


-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------