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

[Bean]

On Mon, Sep 14, 2009 at 5:56 PM, Michal Suchanek <address@hidden> wrote:
> 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.
>

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 = ""
  }
  + 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.

>
> 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.

Yep, both method works. In previous post, I've suggested adding dialog
tree, then we can use something like "show dialog_name". But being
able to embed the component in a string means we can construct it
dynamically, this could be useful when appending to the component tree
in sh/lua script.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/