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

Internet Message Format | 1992-08-29 | 7.5 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: Re: GEM.. what needs to be fixed, and soon!
Message-ID: <[e-mail]>
Date: 28 Aug 92 09:54:13 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail] (Usenet News System)
Organization: Bloomsbury Computing Consortium, London
Lines: 158

In article <[e-mail]> [e-mail] (Stefan Monnier) writes:
>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 !

Why not just stop looking for the double click as soon as the mouse starts
moving? This would mean that click-and-relocate response time would be
acceptable but nothing else will change.

Also, there is no need to wait when you click on radio buttons, maybe the
routines should be made to be context sensitive.

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

It should be on ROM so that the innocent new users need not know anything to
start playing.. ie Buy machine, install word precessor using manual to tell
them what to do, run word processor... lovely fonts.

OK, if you want it upgradable, you buy the upgrade which just patches over
the old version, just like official Atari patches do now!

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

Because C is the most widely used development language used today.

As to whether better interfaces appear on other machines, it doesn't really
matter. As the Atari machines are a small minority the coding interface of
the machine has to be addapted so that it looks like one of the big boys
(however awful that may be) so as to persuade big time developers even to
look in the direction of the Atari. (If all it needs is a quick recompile
of, say, the PC code of a word processor, or anything, without any rewriting
then a software house is more likely to support it.)

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

Mostly true. But at least X etc have a resolution independent standard for
image formats. This means that whatever the machine the same code will be
able to be used to generate the pixel map to be placed in the window. ie you
don't have to worry about, oh this mode as this many planes, arranged in
this way, or whatever. You just generate a standard bit map and let the
libraries and servers do the rest. The nitty gritty of the hardware is no
concern of yours.

>
>> 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 !

Hmm.. just wait for the 3D virtual reality office.. :-)

The Falcon's got the HiFi stereo sound, now all it needs are the binocular
hardware renderers. :-)

>
>> 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)
>
>
>Stefan Monnier
>
>
>-----------------------------------------------------
>-- On the average, people seem to be acting normal --
>-----------------------------------------------------

Steve

--
Addresses:-
JANET:-        [e-mail] or    [e-mail] (preferable)
Internet:-    [e-mail] or    [e-mail] (preferable)