"Norton, Chris" wrote:
> 
> Hi Joachim.
> 
> One thing I'd like to see in KeyboardPolicy: a mechanism that maps a
> keyboard event into various editing/text cursor movement events.
> [Snipped your discussion regarding KeyboardPolicy, menus and
> accelerators]
> 
> Great thoughts -- all of 'em.  This is the kind of thinking we will
> have to pursue for each "Policy" object.

Thanks :))
(I know I'm good at this type of game... don't ask me why. But I'm glad
whenever I can make use of this ability - it's not in very high demand
where I work right now.)

> Question:  Do you think it might be useful to have some kind of
> KeySequence object that explicitly defines a combination of "keys
> pressed"?

It would be required to create a dictionary of key combinations against
editing actions, so I'd say Yes to that one.
I would not call it a *sequence*. That would imply a fixed order.
Combinations with multiple modifier keys wouldn't work: It doesn't
matter if you press Ctrl-Alt-F or Alt-Ctrl-F (and it *should not*
matter, remembering an exact sequence isn't easy).

It might be useful to structure the key combination into a set of
"modifier keys" plus a single "main key". At least that's the logic
behind the Windows keyboard input.

> If we had a KeySequence instance that represented a particular key or
> keys pressed, we could then apply that object to an "editing" feature.
> Then, I suppose, each "editing" feature would have to be defined by an
> object too (because, as you pointed out, you may tie multiple
> KeySequence objects to each "editing" feature).

Right. These features may not be very interesting; just enough to
identify the key combination.

> So what kinds of attributes would an instance of KeyboardPolicy have?
> *       an identifier (what kind of keyboard policy is this?  Is it
>         just for editing on a Mac?  Is it for games?)

OK.

  *       a collection of modifier keys
  *       a collection of main keys

These two define what's valid for a KeyCombination object.

> *       a collection of the available KeySequence objects

KeyCombination object in my terminology. Otherwise agreed.

> *       a dictionary that ties "editing" features to collections of
>         KeySequence objects

The "features" being just names. LineDown in a drawing application is
quite different from LineDown in a DTP program.

> *       perhaps some kind of collection of arrays of keys that might
>         be used to "draw" a virtual keyboard morph?

YES! This would be essential to build keyboard mapping editors. The
model behind the keyboard morph should also provide the modifier key and
main key collections.

> Can anyone else think of any useful attributes and/or behaviors of
> KeyboardPolicy?
> (More use cases would be a good start :-)

For gaming, some way to find "the leftmost top-row key on the keyboard"
might be useful. (This might be a less-than-optimal idea. It might be
better to allow the user to pick the appropriate keys on the keyboard
morph. OTOH it would allow some nice things: e.g. the user says "have my
gizmo controller around the S key" and the software knows which six keys
are around it, so the user can specify six keys for the price of one.)

Menu controllers should tell menu views which keyboard combination is
tied to which menu entry. The menu view could then display a textual
representation of the combination on the menu line. (*Very* useful to
learn the shortcuts for an application.)

For gaming, you need key-down and key-up events. The automatically
generated key-repeat events are typically ignored (at least in real-time
games, like arcade shooters).

A separate typematic rate for each key might be a good idea; e.g. the
letter and digits keys could work with typematic, but no typematic for
Return. (Not sure whether this is a good idea. Just brainstorming.)
(Probably not a good idea. You can always ignore key-repeat events for
"dangerous" keys.)

Policies could also apply to Shift-Lock. One policy switches Shift-Lock
off when you press the normal Shift key, the other switches Shift-Lock
off if you press Shift-Lock again. In the latter case, pressing Shift
will get you lowercase letters.
Shift-Lock has also different effects on non-letter keys: In one policy
it will result in the shifted characters, in the other it will have no
effect on them.

I'm not sure how command keys are routed to menu actions in MVC and
Morphic. Some standard mechanism to map keyboard events to menu events
would be very handy if it's not already there.

Regards,
Joachim
-- 
Please don't send unsolicited ads.