The Be OS uses two levels of indirection to convert a raw key generated by a PC keyboard into a character. The first level of indirection is in the keyboard driver, where the keyboard's scancode is converted into a raw key code. The scancode mapping table is fixed and cannot be changed. Basically the raw key codes follow the design of the keyboard from the top row down, going left to right, with key one being the top-left key (Escape) and key 101 being the bottom-right key (period on the numeric keypad).

The second level of indirection occurs in the app_server, where the raw key code, combined with any active modifiers, is converted into the final character. The app_server mapping tables can be remapped either temporarily, by modifying the tables in memory, or across boots, by placing a mapping table in the /boot/system/settings directory.

The app_server uses nine different mapping tables to map the raw key code into the final character. The mapping tables, in order of priority are: control table; option-caps-shift table; option-caps table; option-shift table; option-table; caps-shift table; caps-table; shift table; and no modifier table. As you can see, the modifier keys that are active when another key is pressed indicate which mapping table is used.

In addition to the raw key code mapping tables, there are a modifier-key mapping table and dead-key mapping tables for the following accents: acute, grave, circumflex, dieresis, and tilde. See the Interface Kit chapter in The Be Book for a description of the key_map data structure.

To remap the character of a given key, you must first determine what the raw key code is. This can be determined by: 1) counting out, from one, the key on the keyboard; 2) using the FontChart application, which displays raw key codes; or 3) referring to the key map in The Be Book. Then you decide for what modifier keys the remapping takes effect, locate the key map in shared memory (using the system_key_map call), and set the new value. Changes take affect immediately and apply system wide.

To remap a modifier key, simply set the appropriate modifier field in the key_map data structure to the raw key code. For example, to swap the caps-lock key with the left-shift key (which some people prefer), set the caps_key field to 75 and set the left_shift_key to 59.

Dead keys are special keys that require two keystrokes, the first one for an accent and the second for a character. They're mapped using a matched-pair table, where the first entry is the completion character and the second is the generated character. The first matched-pair entry is special, in that it determines what the dead key is and also contains the generated character when the space character is the completion character. There are 15 additional entries to map up to 15 accented characters (all unused entries must contain 0).

To make changes that apply only when your window is in the foreground, override the window's WindowActivated method, remap the keys when activate is true, and restore the system default map (using restore_key_map) when activate is false. To make your changes apply every time you reboot the BeBox, simply save the key_map data structure into a file called Key_map in the /boot/system/settings directory.

"What's with you Be-ers? You're missing an opportunity to be as innovative with your user interface as you are with your operating system and your hardware."

Interesting comment. I'll use it as an opportunity to shed light on some of the ideas behind our work and, perhaps, invite more comments and suggestions.

Once upon a time, bit-mapped screens, pointing devices, icons, windows, and menus were invented, creating a revolution in the communication between humans and computers. As with any revolution it had its partisans, opponents, undecided, zealots, ayatollahs, and, soon, the usual dissidents and sects. Quarrels got heated, people and companies accused each other of plagiarism, lawyers got rich, journalists had juicy stories—but today, that revolution is over. It left its imprint on the meaning of user interface, however. The term is mostly associated with visual properties. This is too restrictive.

User interfaces are in the business of quickly creating a myth inside the user's mind, a model of how the computer works. Then the user steps forward and walks on water, the system is faithful to the myth, the user never falls in the water as the programmer is always under the surface supporting whatever move the master makes. No need to belabor the distance between this ideal and today's reality, we are far from the intuitive and infinitely docile computer. But we can point to a couple of areas where we think we bring a little progress.

Multithreading is one. It makes the computer more available to the user, more responsive, more able to manage concurrent user (as opposed to computer) activities. And computing power, multiprocessing, a lighter operating system all help. We all know how hard it is to return to a sluggish system. I often use a vintage 1988 Mac IIx. It keeps reminding me of the role performance plays in the user's experience. The database engine at the heart of our system is another example. My brains hurt when I look at the hard disk on my Windows system or on my Mac.

Inexpensive Internet connections make the situation worse. This is a nice opportunity or our database engine to help both programmers and users make more sense of huge volumes of data, locally or on-line.

Going back to an old debate, command-line versus point-and-click, we think of it as a useless one. Some things are better accomplished by dragging an item from one folder to another, others are better accomplished by typing an expression in a shell window. Or, if you prefer, some users will never grep, others are very comfortable with that style of interaction. If (and it is sometimes a big if) the system doesn't suffer, why not offer the flexibility of both styles? On a slightly different but related vein, we believe full manipulation of windows and menus—sticky menus—from the keyboard as well as the mouse is a good idea. Depending on one's perspective, we lack originality, or we practice heresy, such as using the right button on the mouse. Flexibility and ease of use is what we're after. The fact someone else thought of it first shouldn't be a problem—short of misusing intellectual property.

About a decade ago, a luminary pronounced windows passè. Not really. More than mimicking pieces of paper on a desk, they cater to the universal need for separating contexts. Computers used to be too rigidly modal, as one felt caged in a predefined tree of text menus. Hence the noble call to modelessness. But as one of my more pithy associates remarks, supplying hygienic examples, humans are very modal and generally relate activity to a specific context.

Other technologies haven't come to pass yet, but offer hope. This is the case for voice and handwriting recognition. Both have great potential for changing the way we interact with computers. With a more recent operating environment, we'll be in an excellent position to integrate them when they make the transition into stable technologies that work every time, just like spreadsheets did in 1979.

So we've been conservative thus far, not looking for novelty per se, but for performance, simplicity, and a consistent style. For the latter, we've asked help from a well-known graphic designer, Bruce Browne, who designed icons and the overall look of our interface. We're a little partial, of course, but we like the friendly, colorful face he put on our work. Bruce asked me to clarify he had nothing to do with the color of the BeBox...

Earlier in this article I wrote we were in a good position to integrate new technologies. This applies just as well to feedback and suggestions. Our newsgroup (comp.sys.be) is a lively place, and several of us at Be read the posts and respond on a daily basis. In fact, user interface discussions didn't wait for our newsgroup, they started while we were still hosted by comp.sys.powerpc. Many feel it's an important topic, one where a new company with a new system is more likely to listen than older, more established organizations.

On this and other matters, we'll be happy to demonstrate NIH isn't being reinvented here.

Even on the cutting edge, there's still room for nostalgia. Just ask Charles Turley. The retired molecular biologist from Brisbane, California, is still in love with his Apple II. In fact, he loves all of the Apple machines-even the Apple III, which nobody (possibly other than Turley) has thought about for years.

But even with his nostalgia for computers gone by, Turley is fascinated by the BeBox. Turley is head of a loosely knit, nonprofit consortium of Apple users and developers, called 1WSW-CA. That stands for "One World Software Wizards-Cyber Angels." They go by the acronym because another group on the Internet is claiming the title "CyberAngels."

Turley sees in the BeBox an opportunity to serve all of those disaffected Apple II users, while at the same time creating an opportunity for Be's baby to play in mainstream computing. 1WSW-CA is planning to develop emulators that will allow the BeBox to run the software for virtually any computer Apple has ever made, from the Apple II to the Power Macintosh.

"As Apple has discontinued computers over time, I saw the need to serve the people who still own those computers," Turley says. "Apple will probably phase out the 68K machines to promote the PowerPC. That just makes sense. That leaves 20 million people with no place to go. We're going to support them. That's our motivation."

He also argues that producing a Power Macintosh emulator will help Be sell more computers. Turley won't say which emulator the group plans to work on first. But he says they expect to have a product on the market eight months after they get hardware from Be.

Today there are about 20 in 1WSW-CA, working on a volunteer basis. They're spread around the world, connected through the Internet and through the group's site on the world-wide web (http://www.wco.com/~3d5d1wsw/1WSW.CA.Home.Page.html). The group includes a broad cross-section of people: Retired scientists (like Turley), medical doctors, software engineers, and students from high schools to Ph.D. programs.

As a nonprofit organization, 1WSW-CA doesn't expect to make money on its products. They're just doing it because they love computers.

What a busy few months! The world has known of the BeBox since October 1st of 1995, and in those three months we've been flooded with questions, comments, and nearly 1000 applications to be a Be Developer.

We're very happy, and very gratified, that so many of you think that we can be a platform for your great ideas! I'd like to give you a little update on what's been happening in the developer enrollment process.

We had roughly 100 BeBoxes to allocate to those 1000 applications. That meant that we had to make some hard choices for first recipients, since we did not want to raise expectations and then not be able to follow through.

Our criteria for selecting those initial machine recipients was to select the first 300 or so that had ideas that focused on the unique capabilities of the BeBox, applications that exploited multithreading, dual-processor calculations, and so on.

Of course, even with that as a selection criteria we had a great many more applications than we had machines, so we pared our list down by selecting developers with different backgrounds. We offered membership in our developer programs to developers from Fortune 500 companies, 3-10 person companies, shareware developers, and university students. Our goal was to have a broad range of applications, experience levels, and market segments.

As you can imagine, those first 100 BeBoxes went fast! Our production capability is ramping up, so we're now able to offer BeBoxes to more and more developers. By the time you read this, we should have provided you with costs and details on enrolling in our developer program. This offer will arrive in your e-mail mailbox, so if you don't hear anything from, us please write to dev@be.com to make sure we have your current e-mail address. We won't be able to fill all the requests for a while, so please be patient! We're filling requests as fast as we can, in the order they're received. If you request more than one BeBox, your second (or third, or...) will be shipped after all developers have gotten at least one machine.

And don't worry if you can't participate in the program right now! Our rule is "once a developer, always a developer!" so no matter when you decide to enroll in the program, you can still be part of our developer family.

Thanks to so many of you for visiting our booth at MacWorld SF last week! Many people came to congratulate and encourage us. What a warm and pleasant welcome to our first big show. It really energized us to keep working hard on our products.

A lot of visitors said we had one of the most crowded booths at MacWorld. This may be not too far from the truth... Some figures: We had a 10 x 20 foot booth, around 35,000 people stopped by, we handed out more than 8000 data sheets or information kits, and we gave away around 7500 "We Be Geeks" pocket protectors!!!

We ended this week with our "Geekfest '96" on Saturday. One hundred thirty-five people attended this, our first Be developer conference.

We hope you enjoyed getting to meet the entire Be team. This exchange was fruitful and encouraging, and we certainly enjoyed meeting all of you and answering your questions.

Your ideas and applications are the energy that will fuel our mutual success. Thanks for sharing your great ideas with us!