Keyboard input / init + questions

[Jerome Martin]

On Tue, Sep 28, 2010 at 10:53 PM, Ray Strode <halfline at gmail.com> wrote:

> Hi,
>
>
> > Yeah the \123 is more standard.
> Note C supports \123 for octal and \x123 for hex.
> python uses \u1234 for unicode codepoints.
>

The first two are trivial to do with string.h, as for the third I do not
know. I say let's support all three, but honestly I never saw anyone use the
hex ascii representation in the last 20 years...


>
> > Although now I am thinking all of this
> > should be unicode characters and have a unique character for each key
> stroke
> > (ctrl-V, esc, etc).
> that works for control characters (and sort of what we have now) but
> not for escape sequences. There's not unicode codepoint for "user hit
> the up arrow key"
>

Right.


>
> I don't really think it should be inline with the user's typed keys,
> honestly.  We should filter it out at the plymouth daemon level, and
> send it to the plugin out-of-band using a different call back.
>

Well, that idea is fine too, but I suggest, as normal chars are, well ...
single chars, that if you do some preprocessing the raw chars are passed as
single chars to the callback, and special ones (ANSI sequences) as
multi-chars strings, like "UP", "DOWN" in cooked mode, using the same
callback (I cannot see any reason to use a different one there). The only
problem is that you get some control out of the users hands by doing that.
Unless you do a blend of both, cooking escape sequences at plymouth C code
level, and sending a generic string to the callback to signify that, without
needing to implement a large case statement in the C code. Instead of "UP",
you would get the actual ESC char + [ + A (allowing "if (key == "\033[A")
{...} ). _I_ would prefer that last solution. It would mean just decide the
duration of a "compose delay", and every chars arriving at less than this
interval are just grouped together and sent to the script. Easy, robust and
unobtrusive while being powerfulland solving all escape sequence issues.
However, a String.Len might come in handy to handle that ;-)

-- 
Jérôme Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/plymouth/attachments/20100928/70e01639/attachment.htm>