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

[Michal Suchanek]

2009/9/15 Bean <address@hidden>:
> On Tue, Sep 15, 2009 at 2:14 AM, Michal Suchanek <address@hidden> wrote:
>> 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).
>
> Hi,
>
> If we set password=true in onkey, password is checked every time we
> pressed 'c'. If we only wants to protect some item, just remove
> password attribute from onkey and set it in the specific label, just
> like the "1. Boot Windows" item. This is quite flexible, we can
> protect onkey event and/or individual item. The password attribute is
> just an example, a more advanced scheme may use attributes like
> allow_users for fine tune control.

That sounds fine. However, if the key just activates a label we don't
need this handling twice. And we probably would want all the keys that
can be used described somewhere.

>
>>
>>> á+ 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.
>
> Yep, of course.
>
>>
>> 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.
>
> This can be implemented using onkey event handler, perhaps something like 
> this:
>
> + onkey
> {
>  key = "W"
>  command = "boot_class windows"
> }
>
> command boot_class search items with specific class and boot them.
>

I guess this is quite dodgy. We have no specific boot component, only
components that execute commands. This makes it quite non-obvious what
boot_class is. And again, it would be nicer if this was related to the
actual label which is activated so that the key can be displayed next
to the label.

Thanks

Michal