Keysym additions.

[Jim Gettys]

On Thu, 2006-09-21 at 21:28 +0300, Daniel Stone wrote:
> On Thu, Sep 21, 2006 at 01:57:34PM -0400, Jim Gettys wrote:
> > 1) I'm disturbed there are no comments by any of the XF86 keysyms we
> > added some years ago around multimedia, etc.  I think comments should be
> > added to those to reduce the probability of confusion.  I plan to try to
> > do that as well, to reduce ambiguity of intended meaning.
> 
> Feel free.
> 
> > 2) Should we continue in the XF86 name space for additional X.org
> > keysyms:  I think not; that way we can't have collisions with XFree's
> > allocations.
> 
> Presumably the names are tied to DDX rather than vendor, which could
> easily make it either.  The worst they can do is to add non-colliding
> keysyms.  There's no way they can add keysyms that conflict with what we
> have now.

The point is if we add to the keysym list in the range of keysyms that
were defined XF86, we could collide.

> 
> > a) XK_F1_5 through XK_F34_5, as intermediate keysyms for the F1-F35
> > range
> 
> That's ... a lot of keysyms.  Could you not use modifiers for this?

They aren't modifiers.  They are bona-fide keys.

> 
> > b) XK_FuncGroup1 - XK_FuncGroup5 (5 sets of function keys)
> 
> Can you elaborate?  Do you have one row of function keys, and these are
> essentially modifiers that shift the function number?

We have a rubber keyboard; groups of function keys will be together as
sets, with little nubbins on top for the individual keys themselves.

We don't want to always have to present 12 function keys to 5
year-olds....

> 
> > XK_Frame    /* we have a notion of a "frame" in our UI */
> 
> Can you elaborate on this?

It makes a frame  visible around the UI window (we're doing one
application at a time, again for simplicy).  There are various icons in
the frame to access other activities.

> 
> > XK_Chat	    /* invoke instant messaging */
> 
> XF86XK_Messenger.

Good point.  I missed it; this is why comments are needed ;-).

> 
> > XK_Grab_L  /* when grabbing things like maps to scroll them around */
> > XK_Grab_R  /* when grabbing things like maps to scroll them around */
> 
> Can you not use pointer keys to simulate a mouse button?

I'm not sure what you mean.

> 
> > d) We also plan to have the fn key generate a keycode, rather than being
> > entirely silent; it turns out I could not find a definition for it:
> > 
> > XK_Fn	/* keysym if the Fn key is kind enough to send a code */
> 
> I assume this is yet another modifier.  Maybe take Hyper?

Hyper is usually mapped to the Microsoft Windows key.

I'm referring to the (typically labeled blue) Fn key you find on
keyboards that let you synthesize other keys.  Rather than it being
entirely dead to the window system, we see no reason to not allow it to
be a fully fledged key and usable in other ways.

> 
> > e) Last, but not least, kids may be learning languages.  So we'd like
> > some way to indicate a mode switch to a different language.  But given
> > the number of languages in the world, it isn't clear to me we want to
> > add a mode switch for each and every of hundreds, or even thousands of
> > languages.  (or do we?  the most common languages is just a 100-200
> > languages, IIRC).
> 
> Dude, you can't add 200 keysyms for languages.

heh: we could; we have 32 bits of address space.  I wasn't seriously
suggesting it, but I did want people to at least think about it.  We
could incorporate the ISO language specs into a piece of the address
space.

> 
> > If we don't want to add such a plethora of mode switches to the list,
> > I'd suggest just 
> > 
> > XK_Language_switch_1
> > XK_Language_switch_2
> 
> Could you not use XK_Mode_switch and have the language smarts in
> userspace?

Maybe: I'm not enough of a keyboard guru to know exactly the semantics
of Mode_switch.

And we have two of these keys.

> 
> Cheers,
> Daniel
                              Thanks for the comments,
                                      - Jim

-- 
Jim Gettys
One Laptop Per Child