Keysym additions.

[Daniel Stone]

On Thu, Sep 21, 2006 at 03:12:51PM -0400, Jim Gettys wrote:
> 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:
> > > 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.

Right, but I don't see how XFree86 are in a position to add keysyms that
collide with the range we specify.

If you really want, we could start using XOXK_foo, but then you're still
going to have collisions as you're within the vendor-defined range, no?

> > > 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.

Ah, 0.5.  So you have seventy function keys, or?

> > > 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....

So you'll be able to press either the overarching Fx-F(x+3) button, or
the individual button?

> > > 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.

XF86XK_TaskPane, maybe?

> > > 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.

XKB supports 'pointer keys'.  Unless I'm very much mistaken, you can
simulate button presses, so would you not be able to use the Grab keys
to generate a button press, and have it locking?  That would presumably
give you the desired 'grab' behaviour, unless your grabbing UI is
something different from the usual 'press a mouse button and start
moving the mouse'.

> > > 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.

Right, I'm aware of the Fn key.  But given that its behaviour is that of
a modifier, it would presumably be best to find and steal a modifier
before adding our own.  Bear in mind that this would be a special case
for OLPC as no-one else that I'm aware of sends Fn; they all do it in
hardware.

> > > 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.

Well, the comment next to mode switch says 'character set switch'. ;)

We could probably add another, though.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20060921/b0e27a73/attachment.pgp>