
     From: steve@thelake.mn.org (Steve Yelvington)
     Subject: Programming considerations
     Date: 7 Jan 92 19:29:26 GMT
     Organization: The little computer in the little town that time forgot.

     Bill Rehbock at Atari Corp.  posted  a  message on GEnie recently that
     outlined some things to do and not to  do if you want your software to
     be compatible with  future  (multitasking)  versions  of  TOS and with
     other GEM applications.

     Here's a rundown (paraphrased):

     -- Avoid dialog boxes, because  they  take  control  of the system and
     don't allow the user  to  get  at  other  applications. Instead, use a
     window.

     -- Make all your windows  resizable  and  scrollable, unless there's a
     solid reason not to (i.e., Pagestream's toolbox).

     -- Use wind_update sparingly.

     -- For consistency, always  have  at  least  Desk-File-Edit entries in
     your menu bar.

     -- Be flexible about monochrome  and  color. There are 24-bit 1280x960
     color systems in the works.

     -- Use keyboard equivalents for cut/copy/paste/print: control-x/c/v/p.

     That last recommendation has prompted a lot of grousing from users and
     programmers who believe the ALT  key,  not  the CONTROL key, should be
     used for such  functions.  I  have  not  noticed  any  support for the
     CONTROL point of view.

     -----
     From Konrad Hinsen (hac041@djukfa11.bitnet)

     From me you can get any amount of support for CONTROL you want :-)

     Before deciding on such matters,  one  should think about what purpose
     the Shift/Alt/Control/CapsLock modifiers originally  had and/or should
     have nowadays. For the benefit of  users,  it would clearly be nice to
     assign exactly one meaning to each  of these modifiers, and conversely
     use exactly one modifier for  each  purpose.  The meaning of Shift and
     CapsLock has been clear from the  good  old days of the typewriter, so
     there is no need  to  discuss  it.  Which  leaves  us with Control and
     Alternate for other purposes, of which there are mainly two:

     Specifying  commands,  and  making   available  more  characters.  The
     necessity of having more characters available  might not be obvious to
     Americans (and others), but for many Europeans there is a real need to
     be able to  type  in  several  languages,  and  all European languages
     except English use some additional characters. Kludges like ALT-keypad
     are not acceptable for normal  users,  and  approaches like the 'dead-
     key' method  are  applicable  only  to  some,  but  not  all,  special
     characters. And if we look at the foreign-language keyboards Atari has
     been shipping with STs for years, such as the German keyboard I am now
     typing on, we notice an obvious solution to this problem:

     use ALT to enter additional characters.

     Therefore my proposal for the use of ALT and Control is the following:

     1) Use Control, and only Control, to enter commands.
     2) Use ALT, and only ALT, to get an alternate keyboard layout.

     This is the  only  way  to  achieve  a  consistent  assignment  of the
     modifiers, and it also corresponds  to  the original meanings of them,
     implied by their names. For European  use  it  is also the only way to
     remain consistent with  the  standard  keyboard  layout implemented in
     TOS.

     Restricting commands to one modifier does lead to one problem however:
     how to  implement  more  than  26  (or  36,  if  numbers  are allowed)
     different keyboard commands, and  how  to  find  memorizable names for
     them? The solution dates  back  to  WordStar  and  can  be  found in a
     modified form in today's Windows applications:

     Use two keys for each command, of which the first one specifies a menu
     and the second one an entry  in  this  menu.  For 'Open' in the 'File'
     menu, use ^F^O. In this way,  a  large  number of commands (26x26) are
     available, which allows one to  assign a memorizable keyboard shortcut
     to practically every menu entry even in complex programs and therefore
     make such programs comfortable even  for notorious mouse-haters (which
     are by no means a small minority).

     -----
     From Steve Whitney / Silicon Graphics OS Group

     Well, the big problem with this is  that programs which _must_ use the
     control  key  such  as  terminal  emulators   will  be  forced  to  be
     inconsistent.  Keys like control-C, control-S  and control-Q to name a
     few  have  very  well-defined  functions   on  many  computer  systems
     including IBM PCs.

     If we use _only_ the  control  key  for  commands,  how can a terminal
     emulator provide a short-cut for Cut form the edit menu (traditionally
     C) and still allow the user to break out of a program.  This will lead
     to different keys for cut and paste in different applications which is
     the thing we are  ultimately  trying  to  avoid.   So what about other
     characters?  They can't be used  in  most  terminal programs which are
     limited to ASCII so  overloading  the  control  key  between these two
     mutually-exclusive features doesn't seem too bad.

     Macintoshes have solved the problem  by providing control, command and
     option keys.

     -----
     From Konrad Hinsen (hac041@djukfa11.bitnet)

     That's true, but terminal emulators  are  the  only applications I can
     think of that have such a problem. So the choice seems to be either to
     make terminal emulators  inconsistent  or  all  other applications. In
     that situation I would rather place  the burden on terminal emulators,
     for a number of reasons:

     1) It's just one type of inconsistent application.

     2) People who use  terminal  emulators  are  actually doing their work
     on a different  machine,  which  means  they  are  not  using anything
     resembling a GEM interface. Hence  they  have to change habits anyway,
     so an additional change on the ST side wouldn't disturb as much.

     3) People who use terminal  emulators  are  normally not beginners and
     tend to know what they are doing.

     "allow the user  to  break  out  of  a  program.   This  will  lead to
     different keys for cut and  paste  in  different applications which is
     the thing we are  ultimately  trying  to  avoid.   So what about other
     characters?  They can't be.."

     True, but it's not  the  only  type  of  inconsistency  that should be
     avoided.

     "used in  most  terminal  programs  which  are  limited  to  ASCII  so
     overloading the  control  key  between  these  two  mutually-exclusive
     features doesn't seem too bad."

     We seem to agree that some kind  of overloading is unavoidable, but in
     my opinion it should be the  ALT  key  that gets a double meaning. The
     connection between the Control key and  entering commands goes back to
     ASCII terminals and is  one  of  the  oldest traditions among computer
     users. It is even apparent from the  name 'control' (try to convince a
     novice that he should use ALT  to  control  his program and control to
     enter characters).  And  even  in  the  case  of  terminal  emulators,
     pressing Control leads to some kind  of  action, even if on the remote
     machine.

     Using ALT  for  entering  commands  leads  to  an  extremely  annoying
     inconsistency for all users  of  non-English  keyboards. How would you
     explain to a German  beginner  that  ALT-A  performs a command whereas
     ALT-A(Umlaut) produces a square bracket?

     "Macintoshes have solved the  problem  by  providing control, command,
     and option keys."

     Just as IBM  compatibles  nowadays  have  Control,  Alt  and AltGr. Of
     course a third modifier key would  be  the best solution, but we don't
     have a spare one...

     -----
     From Mark T. O'Bryan  Internet:  obryan@gumby.cc.wmich.edu

     I'm glad you posted this summary here  (I read the original via Znet),
     but this extract implies  that  all  dialog  boxes  are to be avoided.
     What was really meant is that the main application should be set up to
     run in a window, not  as  a  dialog  box.   A  couple of programs that
     "break" this rule that spring to mind  are ArcShell and most of the DC
     utilities (Squish, Xtract, etc.)

     " -- Make all your windows  resizable and scrollable, unless there's a
     solid reason not to (i.e., Pagestream's toolbox)."

     Unfortunately, this isn't always  possible,  due  to  the screen space
     eaten up by all the window  gadgetry,  if you want your application to
     be able to fit on a  medium-res  color  screen.  This is made worse by
     the GEM bug that forces  empty  scroll  bar  areas on you whenever you
     include the SIZER box.  In my opinion, this is a bug that Atari should
     finally fix, if they expect developers to follow these rules.

     I appreciate Bill outlining the do's and don't's, but think that a bit
     more explanation of the motivation for some of these would help people
     to understand and encourage them to comply.

     -----
     From: steve@thelake.mn.org (Steve Yelvington)

     " -- Avoid dialog boxes, because  they  take control of the system and
     don't allow the user  to  get  at  other  applications. Instead, use a
     window."

     It's a little broader than that. Even  with a program that uses a menu
     bar and windows, it's  easy  and  tempting  to  hog  the screen with a
     status box while performing some  lengthy  task. (Rehbock offered file
     transfers and printing as examples).


     A dialog doesn't block  GEM's  pseudo-multitasking,  but it blocks the
     user from having access to the menu bar or other objects, such as desk
     accessories that already have been  opened. Rehbock's posting suggests
     to me that the same  will  be  true  of  the revised user interface in
     multitasking TOS.

     Somewhere around here I have a chunk  of code from an unfinished email
     program that probably would serve  as  another example. I prompted the
     user for an email address and subject  line  by using a dialog box and
     form_edit. I can imagine a situation in  which I might start to type a
     list of addresses, then need to root  around in a file to find another
     address.

     With a dialog box on the  screen,  I  can't activate another window or
     another application (desk accessory) to  perform  that  task. If I had
     coded my user interaction to take  place  in  a window, I could switch
     applications, find the information, and switch back.

     -----
     From: bammi@acae127.cadence.com (Jwahar R. Bammi)

     " -- Avoid dialog boxes, because  they  take control of the system and
     don't allow the user  to  get  at  other  applications. Instead, use a
     window."

     hmm... I have quite successfully  used  non-modal  dialog boxes in the
     past. I was programming in NeWS at the time. There seems to be a fixed
     notion in some peoples minds that  dialog boxes are always modal. It's
     a lot more convenient to dismiss a  dialog box as opposed to a window,
     and more consistent use of  the  visual  metaphors  of dialog boxes as
     opposed to windows, IHMO of course ...

     "-- Use wind_update sparingly."

     If a decent window manager is available, there should be absolutely no
     need for this.

     "-- For consistency, always  have  at  least Desk-File-Edit entries in
     your menu bar."

     Where do the per application menus go ??

     "--  Be  flexible  about  monochrome   and  color.  There  are  24-bit
     1280x960color systems in the works."

     That's great. My request to Atari is that they make enough information
     easily available to do this without resorting to line_A.

     "--  Use  keyboard  equivalents   for  cut/copy/paste/print:  Control-
     x/c/v/p. That last recommendation has prompted  a lot of grousing from
     users and programmers who believe  the  ALT  key, not the CONTROL key,
     should be used.

     Obviously there are not enough EMACS users around :-)

     ------
     From: mjl-b@minster.york.ac.uk

     "Unfortunately, this isn't always  possible,  due  to the screen space
     eaten up by all the window  gadgetry,  if you want your application to
     be able to fit on a  medium-res  color  screen.  This is made worse by
     the GEM bug that forces  empty  scroll  bar  areas on you whenever you
     include the SIZER box.  In my opinion, this is a bug that Atari should
     finally fix, if they expect developers to follow these rules."


     But if you didn't have the empty  scroll bars, where would you put the
     sizer box? Inside  the  window?  Sticking  off  the  bottom right hand
     corner?

     -----
     From: kbad@atari.uucp (Ken Badertscher)

     "CTRL-C/V/X etc.  is  used  by  practically  ALL  modern  GEM programs
     (SciGraph, Interface, Phoenix, Script....)"

     I also agree that the  only  programs  that  have  a real problem with
     Control-ized key equivalents are terminal programs.  Several solutions
     exist for terminal programs, too.  Make  them more modal, so that menu
     key equivalents are not available during terminal input (not the best,
     but _a_ solution).  Let the user configure key equivalents for problem
     keystrokes.   Provide  other  means   of   generating  common  control
     keystrokes or of performing  standard  File  & Edit operations.  White
     Knight on the Mac, for  example,  has  the  option of using buttons to
     start and stop text and to send ^C.

     This issue concerns me a lot because 2 of the programs I use more than
     any other, STalker and STeno, would probably end up with different key
     equivalents for common menu items.  On the other hand, the "Edit" menu
     items in STalker are so rarely  used,  I wouldn't miss the control key
     menu equivalents.

     --
     From: atai@sdcc13.ucsd.edu

     "Bill Rehbock at Atari Corp. posted  a  message on GEnie recently that
     outlined some things to do and not to  do if you want your software to
     be compatible with  future  (multitasking)  versions  of  TOS and with
     other GEM applications.

     Here's a rundown (paraphrased):

     -- Avoid dialog boxes, because  they  take  control  of the system and
     don't allow the user  to  get  at  other  applications. Instead, use a
     window."

     Yea, great.  First provide a  "feature"  as  an  essential part of the
     Atari interface and then 5  years  later  ask  not  to use it.   It is
     Atari's fault not to provide support for modeless dialog boxes.

     Use a window?   but there are only eight windows to play with!

     "-- Make all your windows  resizable  and scrollable, unless there's a
     solid reason not to (i.e., Pagestream's toolbox)."

     If GEM windowing was usable,  than  not  most programs would use full-
     screen windows...

     "-- Be flexible about monochrome and  color. There are 24-bit 1280x960
     color systems in the works."

     If GEM would provide device-independent support....

     -----
     From: Alex.Valdez@actrix.gen.nz (Alex Valdez)

     " But if you didn't have  the  empty  scroll bars, where would you put
     the sizer box? Inside the window?  Sticking  off the bottom right hand
     corner?"

     You're right, of course. But  you  also  don't  need both vertical and
     horizontal empty scroll bars, either. One would suffice.

     Incidentally, the Amiga does that sort  of thing - the sizer doohickey
     sort of takes up a notch  in  one  corner, making the window work area
     non-rectangular.

     -----
     From: micro@imada.ou.dk (Klaus Pedersen)

     "-- Be flexible about monochrome and  color. There are 24-bit 1280x960
     color systems in the works."

     When I first heard about a 24 bit VDI, I looked at the VDI and came to
     the conclusion that it couldn't be  done.  Please can someone tell how
     to make ones programs 24 bit clean?

     The problems is
     - colour index parameter (only 16 bits),
     - the ncolors (in the workout array) which is 16 bits too (with zero
       meaning 'true color').

     The following is speculation in how  it  could be done (so people have
     something to flame - they just love it!):
     A TCVDI (true colour) could be  implemented  by making use of the VDI-
     palette (which can be up to 30 bits - 10 bits per colour), to set up a
     selection of colours.  The  'color  index'  parameter  will  then be a
     shortcut for a 24 bit colour.

     This will mean that pixels already  on  the screen won't change colour
     even if the palette entry for that colour is changed (on a TC-card).


     "--  Use  keyboard  equivalents   for  cut/copy/paste/print:  control-
     x/c/v/p."

     All the programs I use, use the CONTROL  key! Besides - the ALT key is
     used by TOS to give me NON national  chars! I have to press ALT to get
     '{}[]~@' plus paragraph and dot-dot  (name?).  Why change this parting
     (word?), esp. now when Atari  have assigned the ALT-keypad combination
     to get to all ASCII chars?

     I think that is would be  very  confusing  if  we used the ALT key for
     Control of the program and the Control key to get alternate chars!

     I use both German and US/UK programs  and it is can be very confusing!
     If a German program has a shortcut with 'Z', then most programs expect
     you to press the 'Y' key,  because  Germans have these keys exchanged.
     This could be avoided if people  didn't use the SCANCODE directly, but
     used the BIOS-translation tables to get an ASCII value.

     Some US/UK programs have shortcuts outside  the base keys (fx  '^[') I
     have to press ALT to get to the key and the program expects to see the
     control key alone...

     Or '+' and '-' are next to  the  '0' key on American keyboards but not
     on other keyboards!

     Could we get a French guy to show the first keys on their keyboard? Is
     it 'AZER..(?)' instead of 'QWERTY'? -  boy  they must have a nightmare
     when using 'imported' programs...

     Therefore : shortcuts with CONTROL  and  only  on  the base keys (a-z)
     using the BIOS-translation tables. Or on fixed keys (function, keypad,
     help, undo....) with the SCANCODES directly!

     -----
     From: steve@thelake.mn.org (Steve Yelvington)

     "The following is speculation in how it  could be done (so people have
     something to flame - they just love  it!): A TCVDI (true colour) could
     be implemented by making use of the VDI-palette (which can be up to 30
     bits - 10 bits per  colour),  to  set  up  a selection of colours. The
     'color index' parameter will then be a shortcut for a 24 bit colour."

     Actually, that's pretty close.  My  (limited, thirdhand) understanding
     is that the 24-bit color VDIs  work  with  a 256-color TT palette. You
     set up the palette,  draw  with  it,  then  change the palette entries
     without affecting what's already been drawn.

     "This will mean that pixels already  on the screen won't change colour
     even if the palette entry for that colour is changed (on a TC-card)."

     Yup.

     -----
     From: obryan@gumby.cc.wmich.edu (Mark O'Bryan)

     "..But if you didn't have the  empty  scroll bars, where would you put
     the sizer box? Inside the window?  Sticking  off the bottom right hand
     corner?"

     Sure, why not?  I've seen it  done  this way on many Mac applications.
     But for myself, most of the  time  I'd  like  to  be able to have JUST
     horizontal scroll bars, or JUST vertical  scroll bars... in which case
     the SIZER box is right where it's always been.
