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.