NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/atari/st/12828

Internet Message Format | 1992-08-27 | 3.6 KB

Path: sparky!uunet!mcsun!uknet!bcc.ac.uk!link-1.ts.bcc.ac.uk!ucacmsu
From: [e-mail] (Mr Stephen R Usher)
Newsgroups: comp.sys.atari.st
Subject: GEM.. what needs to be fixed, and soon!
Message-ID: <[e-mail]>
Date: 27 Aug 92 10:05:51 GMT
Sender: [e-mail] (Usenet News System)
Organization: Bloomsbury Computing Consortium, London
Lines: 69


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.

(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).

(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.

(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.

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.

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:-        [e-mail] or    [e-mail] (preferable)
Internet:-    [e-mail] or    [e-mail] (preferable)