Subject: Ctrl-Shift (was Re: keyboard input of arbitrary characters)
From: Paul Rohr (paul@abisource.com)
Date: Fri Apr 27 2001 - 16:15:41 CDT
At 03:09 PM 4/27/01 -0400, jrb@redhat.com wrote:
>In GTK+-2.0, you can do this as Ctrl-Shift-[Unicode char code number].
>Apparently this is an iso standard somewhere, too. Additionally, it has
>a pretty sophisticated input method mechanism that can be used by the
>application, if it wants.
Thanks for pointing this out. Markus Kuhn also mentioned this convention
(ISO 14755) in a recent post:
http://www.abisource.com/mailinglists/abiword-dev/01/April/1129.html
As various people have pointed out, it's nice to be able to leverage
existing platform services for stuff like this, and I'd hate to reinvent the
wheel if we don't have to.
Potential issues with this mechanism (as opposed to the Alt-Insert proposal
also in play) include:
1. It's a standard, which is a Good Thing. It's also a fairly recent
standard, so I'm not sure how much (if any) implementation experience
there's been with it yet.
Does anyone know whether any of our existing platforms *use* it in ways we
can take advantage now, or is this something we'll need to wait for OS
upgrades before using?
(For example, at some point I expect that we may decide to make GTK 2.0 an
"upgrade or else" requirement for our users, but I have no idea how soon
that's likely to be.)
2. This is inherently a two-handed mechanism, no? One hand chords the
Ctrl-Shift while the other types in the hex. Or do all our platforms now
have accessibility mechanisms to make that Ctrl-Shift state sticky?
3. Our current keybinding mechanism is fairly sophisticated, to help us
work around various platform oddities. If for any reason we wind up
implementing this ourselves instead of relying on platform input methods, it
could get tricky.
In particular, if I read the spec correctly, the state machine needs to
detect a sequence of chorded numbers and letters of arbitrary length, only
generating an insertChar(..) when done.
4. Finally, no matter how this gets implemented, it may create conflicts
with other existing Word-like keybindings. For details, see:
abi/src/wp/ap/xp/ap_LB_Default.cpp
To be honest, I don't know enough about the interaction of stuff like caps
lock on our current binding mechanism, but I can imagine conflicts with
various Ctrl+Shift+<hexdigit> bindings. For example, on my en-US keyboards:
Shift+<0..9> == <punctuation>, and we have Ctrl+<punctuation> bindings
Shift+<a..f> == <A..F>, and we have Ctrl+<capital letter> bindings
How would we disambiguate these cases from #3, and still make the user
experience Just Work?
bottom line
-----------
I expect that many or all of the above issues are probably solvable, but it
kind of makes my head hurt just to think about it.
Paul
This archive was generated by hypermail 2b25 : Fri Apr 27 2001 - 16:08:24 CDT