home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / atari / st / 12861 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  5.4 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!fs7.ece.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!sm86+
  2. From: sm86+@andrew.cmu.edu (Stefan Monnier)
  3. Newsgroups: comp.sys.atari.st
  4. Subject: Re: GEM.. what needs to be fixed, and soon!
  5. Message-ID: <MebEmeK00awP4Wh0tl@andrew.cmu.edu>
  6. Date: 27 Aug 92 17:11:06 GMT
  7. References: <1992Aug27.100551.4716@bas-a.bcc.ac.uk>
  8. Organization: Carnegie Mellon, Pittsburgh, PA
  9. Lines: 108
  10. In-Reply-To: <1992Aug27.100551.4716@bas-a.bcc.ac.uk>
  11.  
  12. Excerpts from netnews.comp.sys.atari.st: 27-Aug-92 GEM.. what needs to
  13. be fixe.. Mr Stephen R Usher@ucl.a (3256)
  14.  
  15.  
  16. > From what I've heard, the new version of GEM for the FALCON seems a great
  17. > improvement. I hope that at least some of the following gripes I have with
  18. > GEM are fixed, and the rest to be fixed ASAP if the Atari machines are to
  19. > get anywhere:-
  20.  
  21. > (1) Response time for mouse button presses.
  22.  
  23. >     Has anyone noticed that it takes about a second for a mouse press to
  24. > be acted upon under GEM? This delay is the same on the TT as on the ST. This
  25. > has put off a large number of people when I've tried to promote the ST/TT
  26. > for general use. It can be a right pain when you click on one item, move the
  27. > mouse and the system highlights the one your mouse just passed over.
  28.  
  29. Well, the same problem exist on Macs. And it is not so easily corrected: the
  30. problem is with the double click: how could you know at the first click
  31. if there 
  32. will be a second one or not ? You HAVE to wait. I know, you don't need to wait 
  33. when the click is long: it means it is a 'click-n drag' and that could
  34. be improved !
  35.  
  36. > (2) Printer drivers have to be assigned at INSTALL time or by editing a
  37. >         file.
  38.  
  39. >     This is a MAJOR failing. Call the system user friendly? Even the
  40. > first version of MS Windows had the capability to select the type of printer
  41. > driver from a menu at any time.
  42.  
  43. > (3) GDOS is an optional extra.
  44.  
  45. >     In these days any GUI-frontend without a built in scalable font
  46. > generator is doomed. In my opinion a GDOS derivative (scalable font version)
  47. > should be included IN ROM along with a minimum of fonts (eg Times Roman,
  48. > Helvetica etc).
  49.  
  50. Why in ROM in these days (just think of Macs, OS/2, Windows, Unix, etc..) ?
  51. I personnally think that much more of the OS should come on disk ! (for
  52. faster and easier updates)
  53.  
  54. > (4) The low-level character of the GEM interface.
  55.  
  56. >     In my opinion, the programming interface to GEM is too low level to
  57. > be of much use to simple applications developers. If a higher level STANDARD
  58. > library could be developed and released to the public FREE OF CHARGE (but
  59. > NOT free of copyright) I believe the amount and the quality of GEM
  60. > applications would increase by a great deal. This library should preferably
  61. > be available in all the generally available formats, ie DRI, GCC, Turbo C
  62. > etc. It should include (with the coming of such things as MultiTOS) the
  63. > possibility of interrupt driven user interfaces (ie set up your handlers,
  64. > tell GEM to get on with calling them then get on with your processing task,
  65. > handy for processor intensive tasks which need to be able to cope with
  66. > something such as a window resize/redraw/repair). Maybe it could be just a X
  67. > emulation library (I know, straight X is horrid)with all the support
  68. > libraries. This would at least increase the number of possible applications
  69. > on the machines manyfold and give the machine a "standard" coding API.
  70.  
  71. That true (but I'm not sure whether better interfaces are common on other 
  72. architectures right now). ACS is a good way in that direction (for those who
  73. don't know, it is a kind of 'interface builder' for GEM: a great
  74. improvement over
  75. RCSs). An OO standard language could also be an answer: why not switch to C++
  76. (also I would personnally prefer Eiffel) instead of C ?
  77.  
  78. > (5) The low speed of the VDI routines.
  79.  
  80. >     The speed of plotting a pixel on the screen using VDI on the TT is
  81. > so slow... dumping a 320x240 picture using point plotting with VDI can take
  82. > up to a minute.. the is UNACCEPTABLE. The fastest possible algorithms for
  83. > the hardware should be used, else developers will just hack the system and
  84. > cause incompatibilities. This is bad for everyone.
  85.  
  86. VDI is slow, that's true. BUT there is NVDI, which is much better and faster !
  87. (of course it is not really part of the standard OS, bad luck). After
  88. all, you'll have
  89. to get used to slow routines: Xwindows, Display postscript, and the
  90. likes are slow !
  91.  
  92. > Please note that I'm not saying MS windows or MacOS is the way to go... or
  93. > my machine in better than your machine. I'm just trying to say what I
  94. > believe needs to be done to make the Atari version of GEM a modern and
  95. > attractive (in the view of developers) GUI.
  96.  
  97. I completely agree with you ! None of the widespread current OSes is good !
  98. TOS is a bit 'older' than others. It needs much work. Maybe in 10 years
  99. ? Just wait'n see !
  100.  
  101. > Steve
  102.  
  103. > Please don't flame me, I'm just trying to help! :-)
  104.  
  105. > PS. Not having done too much programming using GEM I may well be wrong about
  106. > the API, but I still think, whatever, that point 4 has at least some
  107. > validity.
  108. > --
  109. > Addresses:-
  110. > JANET:-        ucacmsu@uk.ac.ucl or    steve@uk.ac.ox.earth (preferable)
  111. > Internet:-    ucacmsu@ucl.ac.uk or    steve@earth.ox.ac.uk (preferable)
  112.  
  113.  
  114. Stefan Monnier
  115.  
  116.  
  117. -----------------------------------------------------
  118. -- On the average, people seem to be acting normal --
  119. -----------------------------------------------------
  120.