|
Be Newsletter
Issue 6, January 17, 1996
Table of Contents
BE ENGINEERING INSIGHTS:
Customizing the Be OS Keymap
By Robert Polic
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.
User Interface
By Jean Louis Gassée
"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.
Be Developer Profile:
Charles Turley
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.
Developer Update
CK Haun & Valérie Peyre
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.
A Crazy, Happy Week!
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!
|
