Keyboard input / init + questions

[Jerome Martin]

On Tue, Sep 28, 2010 at 11:21 PM, Charlie Brej <plymouth at brej.org> wrote:

> On 09/28/2010 09:28 PM, Jerome Martin wrote:
>
>>    Yeah the \123 is more standard. 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).
>>
>>
>> I think that would make things more difficult, but you know what fits
>> best with the plymouth style. I would not have done the indenting in the
>> code the same as you neither, this is just a matter of style ;-)
>>
>
> Well, lets start with what Ray was saying and have a side channel for non
> text keys, and that should be half the issue solved. I'm only erring towards
> unicode because thats what other scripting systems do.


<nod>.
OTOH, other script systems usually use LUA or embed some sort of lisp or
python interpreter, NOT a full-blown homemade C-like syntax parser not even
leveraging any grammar generator tool :-)


>  Then what do you suggest ? Frankly is the only issue is a plugin script
>> writer forgetting to properly bind a key for viewing details, well, I
>> think people are grown ups :-)
>>
>
> Thats the interesting question. I currently treat theme writers as foolish
> users who even if they screw up, will not screw up the system boot. This may
> be over protective.


I guess I might not be your average target then.
But honestly, highly capable people like Frederic Crozat or I assume other
guys working for larger distros should not be dismissed as foolish by
default. I think they would actually like more control. As for end-users
just toying with themes, well, I said that I was advising to make the
pass-through behavior _optionnal_, so either "forget" to document the
callback setter  function for those essential keystrokes, or have a clear
and loud warning that it should not be used lightly and WILL backfire on
them.


>  Sure, no problem. It is simple, really. Find a sample script attached
>> (pardon the awkward implementation details, this is just a
>> proof-of-concept so some tidying up has yet to be done).
>>
>
> Wow, that is rather impressive.


Thanks, but it really is very simple code in a rough prototype state...
TBH, most of it took less than an afternoon, including testing usplash,
splashy, discovering that plymouth existed on google, reading your blog's
howtos and coding 90% of it. Plymouth really _is_ straigthforward to use.
The most difficult part was to tame the gimp :-)


> Is there anything else you need to add to it?
>

A lot :-) I have some ideas that I will probably implement at some time. I
have more urgent matters to do now, but in the mid-term I will probably add
switching info screens with left/right arrows and put a separate event log
aside for "live" debug. Also, I will add a menu for basic tasks (you
probably guessed that this is a cluster node) like rebooting the node,
dumping configuration on a USB key, running a self-check, things like that
for recovery mostly.

Also, the node normally auto-configures itself and connects to the cluster
without any assistance, but for recovery scenarios I might add an emergency
IP setup menu, that will require the user to pick a network interface,
optionally a vlan number, and type in an IP address, netmask and optional
gateway. For the list selection of eth widget, no problem, this is easy to
do, same for picking a vlan number with +/-  keys, the only thing I haven't
experimented yet is with text entry, aka do I have to code it myself in
either C or script or is the "ask" feature you have will work ?

BTW, I forgot to say so, but this is a very nice piece of work guys !
And I love the script syntax and parser, I thought that was impressive to
code a parser for a splash tool, nice move (I would have been OK with python
bindings, you know ;-) - kidding, I realize you needed something that works
in initrd).

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