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

[Michal Suchanek]

2009/9/14 Bean <address@hidden>:
> On Mon, Sep 14, 2009 at 5:56 PM, Michal Suchanek <address@hidden> wrote:
>> 2009/9/14 Bean <address@hidden>:

>>>
>>> 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.
>>
>
> Hi,
>
> Right, the previous example doesn't cover the data binding between
> edit box and popup window, perhaps we can write something like this:
> (text is the attribute name).
>
> popup " + edit { src=text }"
>
> We could have multiple edit box, for example, one to edit label,
> another to edit content.
>
> As for password protection, we could just use a attribute, for example:
>
> + onkey
> {
>  key = "F1"
>  password = "true"
>  command = "..."
> }
>
> We could also put the password attribute in css. With this, we can
> fine tune which command needs protection.
>
>>>
>>> + 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
>
> Each label can have associated hotkey, but onkey is different, it's
> the event dispatcher, for example:
>
> + menu
> {
>  + onkey
>  {
>    key = "c"
>    password = "true"
>    command = ""
>  }

This is a severe regression from grub legacy which allows protecting
each item with a specific password or have some items protected but
not others. It also does not allow implementing the more advanced
password protection that has each item accessible and editable by
specific set of users (who then have their passwords).

>  + onkey
>  {
>    key = "e"
>    password = "true"
>    command = ""
>  }
>  + label
>  {
>    text = "help"
>    hotkey = "F1"
>  }
>  + label
>  {
>    text = "1. Boot Windows"
>    password = "true"
>    hotkey = "1"
>  }
> }
>
> Pressing F1 or 1 select the item, while pressing c or e laugh specific
> command, regardless of which item is currently selected.

The hotkey should directly activate the item, no need for the middle
step. Normally if you press F1 to get help you do not press Enter
after pressing F1 to actually get help.

Menu accelerators that move to a specific item in the menu are
somewhat useful in menus with various items but the typical grub boot
menu will have a list of kernels which are almost the same so there is
no logical choice of accelerator.

You could perhaps get "L" accelerator for Linux and "W" for windows
but then windows typically do not have multiple kernels so you could
just install a "W" hotkey which boots windows directly and have the
first Linux kernel as the default.

If you have Gentoo and Debian Linux and you boot both of them often
then this might be handy. On the other hand, you can also use submenus
or two menus side by side, one for each distribution.

Thanks

Michal