Minutes from the Unix/X Windows Developers Meeting as reconstructed from hand written notes taken during the Kick Off Meeting, Thursday October 22, 1992, at CTG.
The meeting called to order by Mark Novak from the Trace Center around 7:45 pm. First order of business was for everyone in attendance to introduce themselves (i.e. attached is a list of individuals who attended this meeting). After everyone had introduced themselves. Mark shared a note from Earl Johnson at SUN who was unable to attend the meeting.
The meeting was then turned over to Dr. Gregg Vanderheiden, Trace Center Director, who talked about 10 minutes concerning the purpose of getting a group together for this meeting and the different types of access for X Windows. Briefly, the purpose of the meeting was to discuss accessibility issues related to the Unix/X Window operating system. The two main areas of accessibility were broken into those areas which:
To facilitate organized discussion, the meeting was broken into 3 sections:
StickyKeys allows you to press each key separately when performing a multiple key operation. StickyKeys works with the defined modifier keys (i.e. Shift, Ctrl, and Alt keys on a PC).
MouseKeys allows you to use the keys on the numeric keypad to move the cursor around the screen as if you were using a mouse.
RepeatKeys allows you to set how fast keys repeat when held down. You may also set this to Off and eliminate the repeat function.
SlowKeys instructs the computer not to accept a key as 'pressed' until it has been held down for a specific length of time.
BounceKeys prevents double characters from being typed if you bounce on the key when pressing or releasing it.
SerialKeys allows you to control the keyboard and mouse functions using a special input device attached to the serial port.
ToggleKeys uses a 'beep' to indicate when the Caps Lock, Num Lock, or Scroll Lock keys are activated.
Gregg discussed the remaining two features (A paper discussing these two features in greater detail was also distributed to those who requested it.)
SoundSentry blinks the screen or displays a small musical note in the upper left-hand corner of the display when the computer makes a sound.
ShowSounds (separate paper to discuss this feature)
SoundSentry - flag tied to sounds detected at speaker
ShowSounds - a flag at the system control panel level that a user could set to indicate that they would like a visual presentation of any audible information.
Applications could use to determine when they should provide visual cues to accompany important information presented auditorially
Several questions were raised during this discussion, mainly by individuals who needed more clarification on the features. However, some specific problems or issues were also discussed as follows:
Question/Bob Scheifler:
Did MouseKeys account for some keyboards where keys are chorded for some CAD systems. You may need to make MouseKeys into definable parameters. A better MouseKeys would be software specific, and also handle multiple buttons, since some applications where "double clicks" are necessary and ways to cancel by using a third or 4th button click are needed. You may need to write X mousekeys software to handle the applications that require multiple keys and chording. There are some applications where the needs are very specific and there are not any other means to do a function without multiple/simultaneous keys or chording. SlowKeys would need a wide range of acceptance times.
The alternative input capability (SerialKeys) as defined by the GIDEI standard led to more discussion on the SerialKeys feature.
Question:
Had Trace thought about or done any work with Asian input possibilities. Response was that Trace was just now getting into some work to handle the European community of languages, but did not have any experience with Asian languages.
Question:
about hardware incompatibilities with Japanese keyboards, some of which apparently can have "radio keys".
Question:
It was unknown whether these were mechanical or software or whether or not there was a way of decoupling? Most everyone in attendance was interested in internationalizing the GIDEI standard.
Question:
about function keys and how Trace has used an "esc key" sequence for serial keys and also that many devices can't handle an 8 bit byte stream.
There will be a great need program instructions that are user friendly, and Trace has experience in the area of programming devices to work with SerialKeys, so this would be of assistance.
Question:
as to whether or not the GIDEI Standard discussed that every system has a serial port/RS-232. Response was that was not part of the standard.
Questions:
as to how SerialKeys functioned transparently on a PC. Response was on PS/2 style PCs, it is very easy to reinject scan codes back into the system, basically at the hardware level. For other PCs, codes were put into the keyboard buffer. For compatibility reasons across X Window Systems, we would probably not want to implement SerialKeys in this fashion.
Comment:
about Asian systems use phonetic language and the fact that there are (or seem to be) 10,000 different keyboard ports, leading to no compatibility!
The current GIDEI protocol was requested by several in attendance.
Beth Mynatt from Georgia Tech volunteered to lead the discussion for a while to talk about her groups work at Georgia Tech. Beth talked about problems/needs they had with such things as the low level information of X Protocol versus EditRes which can give higher information on what/where the graphic is. Also, problem and need for coordinating message streams of information, keyboard substitute for mouse commands and better control of interface systems.
Bob inserted some ideas along the way, some having to do with event synthesis, and how he uses voice input to allow him to do both keyboard and mouse input, some having to do with EditRes and the Xt (Intrinsics) level for proper synchronization. Bob had a copy of a masters thesis which talked about how to record at the action & call back points. The copy of the thesis was given to Trace. The group was reminded that Xt (Intrinsics) is one of about 4 dozen different toolkits (different architecture).
Beth continued her discussion about the Xt protocol, and being able to work in a class, where icons can be described as class I information and have the ability to query up to look at class II information (i.e. free hand drawing or pictorial). Beth's group would need cooperation and coordination of work with the OLIT group to explain their oddities when trying to complete their work, however what they can currently do in Xt catches the Motif (i.e. largest market share GUI). Their goals are to continue to define work at Xt level and go from there. Those clients which write to Xlib for memory reasons, and may not use Motif (etc.), probably won't work. There was also a concern for the increasing number of terminal applications that are not shared from the host.
The group discussion turned a little towards what was needed to make screen readers work and what to do. Bob presented the fact of the current X Consortium timing was ideal for this sort of effort, but that the Consortium would need/require specifications before May 93 (code by June 93) if any of the previously discussed accessibility areas were to be considered for next the X revision.
There was open discussion from IBM, Berkeley Systems, and others to define their needed hooks to assist X developers such as Beth to build them into her work to allow screen reader work. Beth stated her group was aiming for prototype by Spring (discussion of Midwest or Southern spring ??). Gregg also shared work going on at Trace using auditory spatial organization of graphics, and use of a dynamic display with tactile information from a "touch pad."
Peter Korn of Berkeley Systems led the discussion for a while to brief the group on Berkeley's current work to port outspoken and how they are defining a core set of hooks for MAC, Windows (and NT) while looking at X Windows. Berkeley while defining hooks, also looks at the application and user interface. Peter also discussed their approach to recognizing icons.
Voluntary teams were assembled to address the following specific areas:
The Trace Center offered to continue in the coordination role for the group.
Anyone with interest for providing funds for any part of the X Windows development (direct access features or 3rd party) should contact Gregg and he will notify members of availability.
Gregg encouraged rapid support for hook identification/definition work at Georgia Tech so that the May 93 deadline for specifications could be met.
Group decided to try and meet at CSUN - March 93 in Los Angeles
Meeting adjourned at 10:30 pm.