joel@gould9.UUCP (Joel West) (12/09/86)
In article <360@apple.UUCP>, dgold@apple.UUCP (David Goldsmith) writes: > I disagree emphatically that Inside Mac, the Software Supplement, and the > Tech Notes are insufficient. I have very rarely seen something done outside > the bounds of what we say is OK which couldn't have been done the "right" way. Time for the First Official Solutions Trivia Quiz. Please state the official solutions for these problems; cite the page number or Macintosh Technical note that provides the answer. 1. How do you interrogate or modify the mapping of key codes to ASCII values? For example, how do I find the key code for Enter? 2. How do you disable dead keys, as for a terminal emulator? 3. How does a drawing program set 'Tall Adjusted' mode for the ImageWriter? 4. How does a paint program disable smoothing for the LaserWriter? 5. How does a program find the percentage reduction for the LaserWriter? 6. How do you write a printer driver? I could go on, but as suggested by the category of the questions, my own experience is very specialized. I'm sure if we had many professional developers on this group the list would be longer. We welcome reader contributions to the FOSTQ. -- Joel West MCI Mail: 282-8879 Western Software Technology, POB 2733, Vista, CA 92083 {cbosgd, ihnp4, pyramid, sdcsvax, ucla-cs} !gould9!joel joel%gould9.uucp@NOSC.ARPA
dgold@apple.UUCP (David Goldsmith) (12/10/86)
>Please state the official solutions for these problems; cite the page >number or Macintosh Technical note that provides the answer. Somehow I feel I'm getting myself into this deeper and deeper, but I'll try to reply. First off I should cheat by once again extending my previous answer. There are a class of things which we do not publish because A) not enough people care to make it worth a Tech Note, or B) we don't want people to do it unless they absolutely have to. The reason for this is not that we think it's a morally indefensible thing to do, but because the devloper who does it is likely to get burned in the future as we change things (remember what started this whole discussion). Nearly everything you mention in your list falls into this category. > 1. How do you interrogate or modify the mapping of key codes > to ASCII values? For example, how do I find the key code > for Enter? This is done by calling the keyboard driver with a key code and seeing what it returns. Depending on this information will make your program dependent on the layout of the keyboard. I don't see why ASCII isn't sufficient. > 2. How do you disable dead keys, as for a terminal emulator? Dead keys are only produced with the Option key held down, so I assume you are talking about using Option as "Control". There is a flag to set in the keyboard driver, but this makes your program dependent on the keyboard driver and makes it impossible for users to produce the foreign characters while your program is operating. It's better to use the command key as "Control". > 3. How does a drawing program set 'Tall Adjusted' mode for > the ImageWriter? This information can also be gotten from Tech Support. We discourage people from making their programs dependent on a particular driver. > 4. How does a paint program disable smoothing for the LaserWriter? Same answer as above. Why not let the user choose if they want smoothing or not? > 5. How does a program find the percentage reduction for > the LaserWriter? Why not use the field iVRes and iHRes in the print record (IM II-150), which gives you the resolution of the printer for ANY printer? > 6. How do you write a printer driver? Well, you've got a point there. This information is available from Tech Support. This information also falls in the category of things which could get you hosed in the future, but obviously we must allow people to write drivers. We've mentioned publicly (in the Software Supplement, I believe) that the ImageWriter source code is available for licensing. What I'm trying to say is there is no black and white. We try to be careful about what we say publicly so that we'll have some flexibility in the future. There are some things which we guarantee won't change, and others we discourage people from doing because we think they will. I still think IM and the Tech Notes are all that is necessary for most developers to produce an application; I don't think any of the questions you mentioned are ones most developers need answered. -- David Goldsmith Apple Computer, Inc. MacApp Group AppleLink: GOLDSMITH1 UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold CSNET: dgold@apple.CSNET, dgold%apple@CSNET-RELAY
joel@gould9.UUCP (12/10/86)
In article <368@apple.UUCP>, dgold@apple.UUCP (David Goldsmith) writes: > Somehow I feel I'm getting myself into this deeper and deeper, but I'll > try to reply. I appreciate David's honesty in this matter, and his willingness to cooperate. > First off I should cheat by once again extending my > previous answer. There are a class of things which we do not publish > because A) not enough people care to make it worth a Tech Note, or > B) we don't want people to do it unless they absolutely have to. The reason > for this is not that we think it's a morally indefensible thing to do, but > because the devloper who does it is likely to get burned in the future as > we change things (remember what started this whole discussion). My point is that people do these things, and you will either A) burn people with incompatibilities or B) eventually have to standardize these. > > 1. How do you interrogate or modify the mapping of key codes > > to ASCII values? For example, how do I find the key code > > for Enter? > > This is done by calling the keyboard driver with a key code and seeing what > it returns. Depending on this information will make your program dependent > on the layout of the keyboard. I don't see why ASCII isn't sufficient. No, it depends on the undocumented keyboard driver interface, which is subject to change. I am trying to find out the keycode of the CURRENTEnter key to make sure I DON'T depend on the keyboard layout. Suppose I wanted to make a program designed for a three-button mouse work on the Mac? Suppose I wanted to emulate the right-most button (call it the "blue" button) in my product by calling GetKeys to see if the Enter button was down at the time the mouse was pushed. Sure, I could use the known keycode for Enter from the Mac 512, but this would fail on the Plus, since there is no keycode 52 available anywhere on the Plus. Suppose I decided to call this program Mac Smalltalk 0.2, and call my company Apple Computer, Inc. :-) > > 2. How do you disable dead keys, as for a terminal emulator? > > Dead keys are only produced with the Option key held down, so I assume you > are talking about using Option as "Control". There is a flag to set in the > keyboard driver, but this makes your program dependent on the keyboard driver > and makes it impossible for users to produce the foreign characters while > your program is operating. It's better to use the command key as "Control". It may be "better" to use command, but this is equivalent to saying "we don't want you to do this", while the history of terminal programs on the Mac and their users is that people want and need to do this. (I think Option is better than the Columbia solution of physically removing the spring from the Caps Lock key, but they had no choice.) This is an example where Apple should define a standard (either the existing one, or a new one) in the same way that GetNextEvent or GetKeys is a defined standard. This is such a trivial matter that it shouldn't cause problems for Apple to maintain compatibility in the future. > > 3. How does a drawing program set 'Tall Adjusted' mode for > > the ImageWriter? > > This information can also be gotten from Tech Support. We discourage people > from making their programs dependent on a particular driver. ANY painting/drawing program wants to default the TPrint to square pixels, although the user can obviously change this. MacDraw knows how to do this, so certainly 3rd party programs should. All the answers so far are in the areas where a developer wants to make a product powerful and useful (and thus saleable), and so given a choice of using an unofficial solution or remaining compatible with no solution, many will use the unofficial solution and deal with the consequences in a future release. > > 5. How does a program find the percentage reduction for > > the LaserWriter? > > Why not use the field iVRes and iHRes in the print record (IM II-150), which > gives you the resolution of the printer for ANY printer? Because iVRes and iHRes are ALWAYS 72 dpi (except ImageWriter Tall, where H is 80), even on the Apple LaserWriter. I believe the LaserWriter drivers were done this way to provide compatibility for MacWrite, or maybe MacDraw. > > 6. How do you write a printer driver? > > Well, you've got a point there. This information is available from Tech > Support. This information also falls in the category of things which could > get you hosed in the future, but obviously we must allow people to write > drivers. I think David has essentially said that if Tech Support believes you have a legitimate need to know, they'll tell you. When I asked I guess I didn't have such a need, but this is somewhat encouraging. > We've mentioned publicly (in the Software Supplement, I believe) > that the ImageWriter source code is available for licensing. Tech support also said this is expensive, buggy, obsolete and, essentially, useless. > There are some things which we guarantee won't change, and others we > discourage people from doing because we think they will. Once things are changed, I hope they are changed to the RIGHT way once and for all, and then documented for all to use, rather than saying "We'll tell some people but they may get burned later", which is an unrealistic approach, since if one of those people ends up building the #1 program for the Mac, Apple will be cutting its own throat. I hope no one (including David) interprets this as antagonistic to David or Apple. I just wanted to clarify the two positions to show why people want to know this, and why Apple is approaching it the way it is. Perhaps some changes will come eventually. -- Joel West MCI Mail: 282-8879 Western Software Technology, POB 2733, Vista, CA 92083 {cbosgd, ihnp4, pyramid, sdcsvax, ucla-cs} !gould9!joel joel%gould9.uucp@NOSC.ARPA
joel@gould9.UUCP (12/10/86)
I guess I forgot to put in my concluding summary, which is:
OK, Apple, you don't want to publish the current interface, because it
is "wrong" and you plan to change it. Please do it the "right" way
as soon as possible, and then publish (and freeze) the interface.
You shouldn't try to guess what developers should and should not do
and decide to cooperate accordingly, since this stifles innovation
and won't stop them, anyway. Instead, listen to what they say they
want to do.
The Macintosh software architecture is wonderfully open in many ways,
but there are a few places that were missed (or mis-designed) and
these areas should be fixed incrementally.
--
Joel West MCI Mail: 282-8879
Western Software Technology, POB 2733, Vista, CA 92083
{cbosgd, ihnp4, pyramid, sdcsvax, ucla-cs} !gould9!joel
joel%gould9.uucp@NOSC.ARPA