Re: [GITGRUB] New menu interface (second draft)

[Michal Suchanek]

2009/9/14 Bean <address@hidden>:
>Hi,
>
>Thanks a lot for your advice, most of them looks good, although some
>details may need adjustment.

Thank you for working on the new menu system.

Of course, this discussion is here to select the best ways to
implement the menu we can think of and refine them so that we can save
work on (re-)implementation and maintenance.

>
> About edit boxes, I'd prefer to use a command like popup to open a new
> window, perhaps something like:
>
> popup "+ term { class=gfxterm }"
>
> Then we can bind it to specific keys using onkey event:
>
> +onkey
> {
>  key = "e"
>  command = "popup \"+ edit { class=edit_box text=\\\"$CURITEM\\\" }\""
> }

I thought that the editbox should be able to actually edit something
but currently it is not so, it loads a list of commands from the item
and either the list is executed (possibly after modifications) or it
is thrown away so this would probably work.

But it is still somewhat problematic because this does not tie the
edit the the particular label which is going to be edited.

If the label was special in some way (ie linux kernel versus other
kernel) and it was somehow reflected in its properties (which is easy
because linux kernels are done with 10_linux in grub.d while others
are done elsewhere) or it was the single user variant this information
is lost now. What I have in mind here is that people might want the
edit dialog for a red menu item to have red border or something like
that.

This also makes password protection somewhat hard to hook in. If
editing the item is password protected and this key is bound globally
then this seems to bypass the password unless special measures are
taken.

Also there is not only "edit action" but also "execute action" key
binding that applies to labels with an action. This should be also
globally(?) customizable,but possibly password protected.

It's not like the "onkey" handler cannot check the password protection
properties but it's more natural (and probably easier to understand in
the code) if this is handled in the component itself.

>
> + onkey
> {
>  key = "c"
>  command = "popup \"+ term { class=term_box }\""
> }

This is fine, it opens a terminal which is just a new toplevel window.
I would prefer the keyword was "show" instead of "popup" because it
should hide the current window and show the one specified instead.
Popup typically refers to a small additional window in windowing
systems (and we don't really need a windowing system, only
single-window system should be fine).

The other thing with onkey is that if you want to make the key known
you have to replicate the information somewhere in a label.
It might be better to have an element that reacts to a hotkey and also
displays it.

ie

+ label {
 text = Help
 hotkey = F1,h
 action {
  show {

<message box with text generated in grub.d scripts>
}}}

or if this is easier

+ hotkey {
 key = F1,h
 + label {
  text = Help
....

# problematic keys
key = space,comma

I wonder if writing the whole element structure in the show command
directly is the best approach. Perhaps the show commnad should only
accept a class name and try to find a previously defined toplevel (not
inside other element) panel with that class or perhaps there should be
some other naming that would make it possible to define and recall
windows.

Thanks

Michal