[GITGRUB] New menu interface (second draft)

[GITGRUB] New menu interface (second draft)

[Bean]

Hi,

After considering the discussion of first post, I come up with the
second draft for new menu interface implementation.

First, the basic drawing unit is now region, there are four types:

text
Single line of text, have alignment attribute.

image
An image, have scaling and alignment attribute.

rect
A rectangle area filled with background color.

viewport
A viewport in the container box. This is used for strolling.

The whole ui are composed of the above regions, components add their
drawing regions to a global tree which handles region updates for
them.

One of the shortcoming of Colin's graphic patch is that the update
process is not optimized. The screen flickers a lot without double
buffer. Double buffer eats up a lot of memory, which is a problem in
platforms like OpenFirmware. And even with double buffer, the
redrawing process takes time and response is quite slow. The new menu
interface split ui into small regions which uses different update
strategy, and redraw only the necessary regions.

Component is the basic unit for interaction. Each component has a flag
that indicate if it can receive input focus. The last component with
input focus will be the current input, you can use a hotkey like
ctrl-tab to switch to other component.

Some of the components:

label
Text label, it consist of text region.

image
Image, it consist of image region.

frame
Window frame. This is normally used by other component to draw the
border, it consist of multiple image and/or rect region.

panel
Layout manager. It can have a scrollbar when the actual content is
bigger than the window size. it consist of viewport region.

text
Multi-line text box. It has a frame and a text box in the center.

edit
Single line edit box. It has a frame and an edit box in the center.
Has input focus.

menu
Menu box. It has a frame, a panel for layout control, and multiple
menu items. Has input focus.

term
Terminal emulator. It has a frame and a two dimension edit box in the
center. Has input focus.

---
Bean

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

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

[Michal Suchanek]

2009/9/7 Bean <bean123ch@gmail.com>:
> Hi,
>
> After considering the discussion of first post, I come up with the
> second draft for new menu interface implementation.
>
> First, the basic drawing unit is now region, there are four types:
>
> text
> Single line of text, have alignment attribute.
>
> image
> An image, have scaling and alignment attribute.
>
> rect
> A rectangle area filled with background color.
>
> viewport
> A viewport in the container box. This is used for strolling.
>
> The whole ui are composed of the above regions, components add their
> drawing regions to a global tree which handles region updates for
> them.
>
> One of the shortcoming of Colin's graphic patch is that the update
> process is not optimized. The screen flickers a lot without double
> buffer. Double buffer eats up a lot of memory, which is a problem in
> platforms like OpenFirmware. And even with double buffer, the
> redrawing process takes time and response is quite slow. The new menu
> interface split ui into small regions which uses different update
> strategy, and redraw only the necessary regions.
>
> Component is the basic unit for interaction. Each component has a flag
> that indicate if it can receive input focus. The last component with
> input focus will be the current input, you can use a hotkey like
> ctrl-tab to switch to other component.
>
> Some of the components:
>
> label
> Text label, it consist of text region.
>
> image
> Image, it consist of image region.

How does an image map to other menu rendering like: text-only, dumb terminal ?

You can render a menu item that has an image and text in both but
image would not show without graphics. The style may turn off  the
text if graphics is available.

IMHO images need not be available separately. You can put them in the
background of an element or as an icon to text+icon label element. The
style then specifies in which direction from icon the text is shown
(hidden, over the center, above, below, left, right ..).

>
> frame
> Window frame. This is normally used by other component to draw the
> border, it consist of multiple image and/or rect region.
>
> panel
> Layout manager. It can have a scrollbar when the actual content is
> bigger than the window size. it consist of viewport region.

How does a frame differ from a panel?

>
> text
> Multi-line text box. It has a frame and a text box in the center.

Why another frame ? We have a frame component already.

>
> edit
> Single line edit box. It has a frame and an edit box in the center.
> Has input focus.

Another frame?
Is this even needed? The only editable thing in gfxterm is multiline -
the whole menu entry.

>
> menu
> Menu box. It has a frame, a panel for layout control, and multiple
> menu items. Has input focus.

Is this even needed? The menu is always generated by a script so there
is no problem if multiple elements are used in the default menu and it
can be customized if it is not a fixed element.

>
> term
> Terminal emulator. It has a frame and a two dimension edit box in the
> center. Has input focus.
>

Thanks

Michal

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

[Bean]

On Tue, Sep 8, 2009 at 4:14 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
> 2009/9/7 Bean <bean123ch@gmail.com>:
>> Hi,
>>
>> After considering the discussion of first post, I come up with the
>> second draft for new menu interface implementation.
>>
>> First, the basic drawing unit is now region, there are four types:
>>
>> text
>> Single line of text, have alignment attribute.
>>
>> image
>> An image, have scaling and alignment attribute.
>>
>> rect
>> A rectangle area filled with background color.
>>
>> viewport
>> A viewport in the container box. This is used for strolling.
>>
>> The whole ui are composed of the above regions, components add their
>> drawing regions to a global tree which handles region updates for
>> them.
>>
>> One of the shortcoming of Colin's graphic patch is that the update
>> process is not optimized. The screen flickers a lot without double
>> buffer. Double buffer eats up a lot of memory, which is a problem in
>> platforms like OpenFirmware. And even with double buffer, the
>> redrawing process takes time and response is quite slow. The new menu
>> interface split ui into small regions which uses different update
>> strategy, and redraw only the necessary regions.
>>
>> Component is the basic unit for interaction. Each component has a flag
>> that indicate if it can receive input focus. The last component with
>> input focus will be the current input, you can use a hotkey like
>> ctrl-tab to switch to other component.
>>
>> Some of the components:
>>
>> label
>> Text label, it consist of text region.
>>
>> image
>> Image, it consist of image region.
>
> How does an image map to other menu rendering like: text-only, dumb terminal ?
>
> You can render a menu item that has an image and text in both but
> image would not show without graphics. The style may turn off  the
> text if graphics is available.
>
> IMHO images need not be available separately. You can put them in the
> background of an element or as an icon to text+icon label element. The
> style then specifies in which direction from icon the text is shown
> (hidden, over the center, above, below, left, right ..).

Hi,

Actually there is bitmap for text mode as well, it's ascii art. And
the main reason to separate image from others is for update control.
Bitmaps uses blt to update a region, rect uses fill, and text uses
draw_font, each have different update algorithm.

>> frame
>> Window frame. This is normally used by other component to draw the
>> border, it consist of multiple image and/or rect region.
>>
>> panel
>> Layout manager. It can have a scrollbar when the actual content is
>> bigger than the window size. it consist of viewport region.
>
> How does a frame differ from a panel?

The frame only draws the window border, and panel is layout manger.
It's possible to use panel without frame, for example, listbox.

>>
>> text
>> Multi-line text box. It has a frame and a text box in the center.
>
> Why another frame ? We have a frame component already.
>

Frame is only responsible for the border, the actual content is
controlled by another component.

>>
>> edit
>> Single line edit box. It has a frame and an edit box in the center.
>> Has input focus.
>
> Another frame?
> Is this even needed? The only editable thing in gfxterm is multiline -
> the whole menu entry.
>

This edit box is mainly for popups, for example, it can be used to
input passwords.

>>
>> menu
>> Menu box. It has a frame, a panel for layout control, and multiple
>> menu items. Has input focus.
>
> Is this even needed? The menu is always generated by a script so there
> is no problem if multiple elements are used in the default menu and it
> can be customized if it is not a fixed element.

This only control the style and layout of menu component, the actual
menu items is added in menuentry statement.

>
>>
>> term
>> Terminal emulator. It has a frame and a two dimension edit box in the
>> center. Has input focus.
>>
>
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Bean

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

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

[Bean]

Hi,

After more consideration, perhaps we should use the following
component structure:

frame - window border
panel - layout manager with scroll bar support
window - frame + panel
label - text
image - image
button - button
list - list box
edit - multi-line edit box
term - terminal emulator  (extends edit component)
menu - menu list (extends list box)

We should be able to construct more powerful component using the above
simple ones, I'm considering adding a dialog tree:

+ dialog
{
  + edit
  {
    + window
    {
      class = "edit"
      + edit
      {
      }
    }
  }
 + message
  {
    + window
     {
       class = "message"
       + label
       {
         text = $1
       }
     }
  }
}

Then we can use something like this to show a popup message dialog:

popup message "Hello World"

And for components with input focus, we can add hotkey node to add actions:

+ screen
{
  + menu
  {
    + hotkey
    {
      key = "F1"
      command = "popup message Hello"
    }
   + hotkey
    {
      key = "F9"
      command = "reboot"
    }
   + hotkey
    {
      key = "F10"
      command = "halt"
    }
  }
}

-- 
Bean

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

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

[Michal Suchanek]

2009/9/8 Bean <bean123ch@gmail.com>:
> Hi,
>
> After more consideration, perhaps we should use the following
> component structure:
>
> frame - window border
> panel - layout manager with scroll bar support
> window - frame + panel

What has window that frame+panel does no have?

I think it is reasonable to just put two elements when this
functionality is wanted.

On the other hand, implementing a frame separately from panel has the
disadvantage that the frame cannot be drawn between the panel
children. Why not just add a frame to every element and make it
optional so that it is shown only for elements where it is wanted? If
somebody wants multiple frames (ie double frame) they can just stack
multiple panes with frames and padding.

> label - text
> image - image

I don't think that image is a useful user-acessible component. Even if
images are internally rendered differently from text there is no
reason for image to be a separate component. Grub has no means of
converting images to ascii art for displaying in text mode. Even if it
did there is no guarantee that two images that looked distinct
originally are converted to ascii art blobs that can be told apart.

If you envision using ascii art a lot in grub then perhaps it should
be implemented as a special graphics format that can be also displayed
in text console. Still ascii art does not work on dumb terminals,
braille terminals, etc.

IMHO we should not encourage components that have only graphical (or
semi-graphical) representation that cannot be represented as plain
text. If an icon or image is wanted it should be packed into a label
with a plaintext description. It is possible to hide the description
when the element is shown on display that can render graphics (or use
an empty description) but there should be no image-only component.

> button - button

What's the difference between label and button?
What would the button typically do?

> list - list box

What's the difference between panel containing multiple labels and a list box?

> edit - multi-line edit box

Yes, this is actually useful compound element. A multiline edit is
more that a bunch of single line edits stacked inside a panel.

I guess it should be possible to have a single-line edit or password
edit. Currently grub does not have passwords in gfxterm so no such
thing is used but they are in planning.
This is probably also possible by limiting the multiline edit to single line.

> term - terminal emulator  (extends edit component)
> menu - menu list (extends list box)

How does it differ from a listbox?

I would rather have as few elements as possible.

This way the implementation of the elements should be smaller and
easier to maintain.

Styling the menu should be easier with fewer elements with fewer
baroque properties and obscure limitations.

You would need to use some IDs or names for the elements and selectors
like CSS selectors or X properties so that styles do not break if
somebody adds a new label above the menu.

The menuentry command could be removed altogether and the grub.d
scripts updated accordingly or if you want to keep it for
compatibility perhaps this command should just add labels to a panel
identified by an environment variable.

>
> We should be able to construct more powerful component using the above
> simple ones, I'm considering adding a dialog tree:
>
> + dialog
> {
>  + edit
>  {
>    + window
>    {
>      class = "edit"
>      + edit
>      {
>      }
>    }
>  }
>  + message
>  {
>    + window
>     {
>       class = "message"
>       + label
>       {
>         text = $1
>       }
>     }
>  }
> }

Couldn't this be done as a function in the support shell scripts that
are used for generating the grub.cfg?

>
> Then we can use something like this to show a popup message dialog:
>
> popup message "Hello World"

What would you report in these popups?

Currently grub messages only happen outside of the menu while booting.

It can possibly change but at best you could probably designate a log
output element that gets the printf messages and displays them as
multiline text.

>
> And for components with input focus, we can add hotkey node to add actions:

I think this could be also useful for components without focus.

However, these keys (and especially key combinations with a modifier)
might not work on some limited or broken key inputs (serial, efi).

Thanks

Michal

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

[Michal Suchanek]

2009/9/8 Bean <bean123ch@gmail.com>:
> Hi,
>
> After more consideration, perhaps we should use the following
> component structure:
>
> frame - window border
> panel - layout manager with scroll bar support
> window - frame + panel
> label - text
> image - image
> button - button
> list - list box
> edit - multi-line edit box
> term - terminal emulator  (extends edit component)
> menu - menu list (extends list box)

Also how is the menu shown?

Currently the menu is implicitly shown if defined but with this
extended menu system you can create multiple "windows".

There could be a menu with some magic ID that is shown automatically
if defined after config parsing ends.

Another approach is adding a show command that shows a particular
element (with its subelements) as the main window on the screen, This
would be likely implicitly present in the edit command for the menu
items that have some action bound to them.

To make the window management simple every time only a single window
would be shown - they could be pushed onto a window stack so that if a
popup (such as the action edit popup) is closed the previous window is
restored.

Thanks

Michal

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

[Bean]

On Wed, Sep 9, 2009 at 6:53 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
> 2009/9/8 Bean <bean123ch@gmail.com>:
>> Hi,
>>
>> After more consideration, perhaps we should use the following
>> component structure:
>>
>> frame - window border
>> panel - layout manager with scroll bar support
>> window - frame + panel
>
> What has window that frame+panel does no have?
>
> I think it is reasonable to just put two elements when this
> functionality is wanted.

Hi,

Windows can also has a title bar. Although this function may not be
implemented in the first version, it's better to keep the component
there. And the frame+panel combo is often used, so having a window
component would make the config file cleaner.

>
> On the other hand, implementing a frame separately from panel has the
> disadvantage that the frame cannot be drawn between the panel
> children. Why not just add a frame to every element and make it
> optional so that it is shown only for elements where it is wanted? If
> somebody wants multiple frames (ie double frame) they can just stack
> multiple panes with frames and padding.
>

This sounds good, perhaps frame should be renamed border to reflect
its function. Border could also be use to implement 3D looks of
component.

>> label - text
>> image - image
>
> I don't think that image is a useful user-acessible component. Even if
> images are internally rendered differently from text there is no
> reason for image to be a separate component. Grub has no means of
> converting images to ascii art for displaying in text mode. Even if it
> did there is no guarantee that two images that looked distinct
> originally are converted to ascii art blobs that can be told apart.
>
> If you envision using ascii art a lot in grub then perhaps it should
> be implemented as a special graphics format that can be also displayed
> in text console. Still ascii art does not work on dumb terminals,
> braille terminals, etc.
>
> IMHO we should not encourage components that have only graphical (or
> semi-graphical) representation that cannot be represented as plain
> text. If an icon or image is wanted it should be packed into a label
> with a plaintext description. It is possible to hide the description
> when the element is shown on display that can render graphics (or use
> an empty description) but there should be no image-only component.
>

Originally, I  add image so that component only implement one
function, for example, if we merge label and image, we need to use
switch statement on the attributes to know if it's a label or image.

But on the other hand, I believe background image is quite common and
could be used by other component, so why not just make background
image an optional parameter for all components. To have a plain image,
we can use a panel with the specific background.

>> button - button
>
> What's the difference between label and button?
> What would the button typically do?

Button is a panel with text in the middle, it's quite common in dialog
boxes such as YES/NO/CANCE, so I guess it deserves its own component.

On second through, this component should not be implemented in C,
perhaps we can add component tree so that users can write customized
component in config file, something like this:

+ component
{
  + button
  {
    + panel
    {
      + text
      {
        valign = "center"
        halign = "center"
        text = "$text"
      }
    }
  }

Then we can create buttons like this:

+ button
{
  text = "hello"
}

Although implementation is not trivial, so this may be come up in a
later version.

>
>> list - list box
>
> What's the difference between panel containing multiple labels and a list box?
>

List box has actions like select an item, jump to next item. And it
could scroll the panel if we jump to items outside the viewport.

>> edit - multi-line edit box
>
> Yes, this is actually useful compound element. A multiline edit is
> more that a bunch of single line edits stacked inside a panel.
>
> I guess it should be possible to have a single-line edit or password
> edit. Currently grub does not have passwords in gfxterm so no such
> thing is used but they are in planning.
> This is probably also possible by limiting the multiline edit to single line.
>
>> term - terminal emulator  (extends edit component)
>> menu - menu list (extends list box)
>
> How does it differ from a listbox?

Menu has specific actions like reading the menu items from environment
variable, boot menu item, edit menu item.

> I would rather have as few elements as possible.
>
> This way the implementation of the elements should be smaller and
> easier to maintain.
>
> Styling the menu should be easier with fewer elements with fewer
> baroque properties and obscure limitations.

Yep, perhaps some of the above component can be implemented as user
defined component in config file. The UI is quite straightforward,
just stack the components together, but action are a little tricky,
each component should have a set of default handler. Perhaps we need
to export some of the component functions to be used in config
scripts.

>
> You would need to use some IDs or names for the elements and selectors
> like CSS selectors or X properties so that styles do not break if
> somebody adds a new label above the menu.
>
> The menuentry command could be removed altogether and the grub.d
> scripts updated accordingly or if you want to keep it for
> compatibility perhaps this command should just add labels to a panel
> identified by an environment variable.
>

Ok.

>>
>> We should be able to construct more powerful component using the above
>> simple ones, I'm considering adding a dialog tree:
>>
>> + dialog
>> {
>>  + edit
>>  {
>>    + window
>>    {
>>      class = "edit"
>>      + edit
>>      {
>>      }
>>    }
>>  }
>>  + message
>>  {
>>    + window
>>     {
>>       class = "message"
>>       + label
>>       {
>>         text = $1
>>       }
>>     }
>>  }
>> }
>
> Couldn't this be done as a function in the support shell scripts that
> are used for generating the grub.cfg?
>
>>
>> Then we can use something like this to show a popup message dialog:
>>
>> popup message "Hello World"
>
> What would you report in these popups?
>
> Currently grub messages only happen outside of the menu while booting.
>

For example, when user press F1, we can show a help box. Or if
something goes wrong, we popup a error message box to indicate what
happen.

> It can possibly change but at best you could probably designate a log
> output element that gets the printf messages and displays them as
> multiline text.
>

Right, that could be useful.

>>
>> And for components with input focus, we can add hotkey node to add actions:
>
> I think this could be also useful for components without focus.
>
> However, these keys (and especially key combinations with a modifier)
> might not work on some limited or broken key inputs (serial, efi).

I'm thinking about more generic names like onkey. Components without
input focus can have other type of event handlers, like ontimer,
oncreate, etc.

As for key limitation, we can load different config sctipt for
different platform, this shouldn't be difficult to implement using if
statement in grub.cfg.

-- 
Bean

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

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

[Bean]

On Wed, Sep 9, 2009 at 10:50 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
> 2009/9/8 Bean <bean123ch@gmail.com>:
>> Hi,
>>
>> After more consideration, perhaps we should use the following
>> component structure:
>>
>> frame - window border
>> panel - layout manager with scroll bar support
>> window - frame + panel
>> label - text
>> image - image
>> button - button
>> list - list box
>> edit - multi-line edit box
>> term - terminal emulator  (extends edit component)
>> menu - menu list (extends list box)
>
> Also how is the menu shown?
>
> Currently the menu is implicitly shown if defined but with this
> extended menu system you can create multiple "windows".
>
> There could be a menu with some magic ID that is shown automatically
> if defined after config parsing ends.
>
> Another approach is adding a show command that shows a particular
> element (with its subelements) as the main window on the screen, This
> would be likely implicitly present in the edit command for the menu
> items that have some action bound to them.
>
> To make the window management simple every time only a single window
> would be shown - they could be pushed onto a window stack so that if a
> popup (such as the action edit popup) is closed the previous window is
> restored.

Hi,

We can have a menu tree like this:

+ menu
{
  + main
  {
    + item
    {
      class = "chainloader"
      name = "Chainloader"
      command = "chainloader +1\nboot"
    }
  }
  + tools
  {
  }
}

The menuitem command adds to the main menu by default, but it could be
overwritten with a option. In menu component, we uses an attribute to
set the menu name.

-- 
Bean

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

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

[Michal Suchanek]

hello

2009/9/9 Bean <bean123ch@gmail.com>:
> On Wed, Sep 9, 2009 at 6:53 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
>> 2009/9/8 Bean <bean123ch@gmail.com>:
>>> Hi,
>>>
>>> After more consideration, perhaps we should use the following
>>> component structure:
>>>
>>> frame - window border
>>> panel - layout manager with scroll bar support
>>> window - frame + panel
>>
>> What has window that frame+panel does no have?
>>
>> I think it is reasonable to just put two elements when this
>> functionality is wanted.
>
> Hi,
>
> Windows can also has a title bar. Although this function may not be
> implemented in the first version, it's better to keep the component

What for? It's of some use in complex multiwindow environments where
users are hopelessly lost. We do not wan  to get there with grub (and
cannot for lack of threading) so it is quite pointless to have a title
bar.

And in case you do want a titlebar for your window you can add a panel
around it with a text label. With the added flexibility that you can
change the directions in which elements are packed in the panel at
whim even in a theme so you can get the title next to the window
content (perhaps to stuff more menu items into a small widescreen).

> there. And the frame+panel combo is often used, so having a window
> component would make the config file cleaner.

If you add a panel border there is much less need for yet another one.

And the config is going to be repetitive whatever you do. Adding a
keyword and a pair of bracers somewhere is nothing compared to the
long kernel argument lists.

>
>>> label - text
>>> image - image
>>
>> I don't think that image is a useful user-acessible component. Even if
>> images are internally rendered differently from text there is no
>> reason for image to be a separate component. Grub has no means of
>> converting images to ascii art for displaying in text mode. Even if it
>> did there is no guarantee that two images that looked distinct
>> originally are converted to ascii art blobs that can be told apart.
>>
>> If you envision using ascii art a lot in grub then perhaps it should
>> be implemented as a special graphics format that can be also displayed
>> in text console. Still ascii art does not work on dumb terminals,
>> braille terminals, etc.
>>
>> IMHO we should not encourage components that have only graphical (or
>> semi-graphical) representation that cannot be represented as plain
>> text. If an icon or image is wanted it should be packed into a label
>> with a plaintext description. It is possible to hide the description
>> when the element is shown on display that can render graphics (or use
>> an empty description) but there should be no image-only component.
>>
>
> Originally, I  add image so that component only implement one
> function, for example, if we merge label and image, we need to use
> switch statement on the attributes to know if it's a label or image.

It's not a label or image, it's a label with an image (both optional,
you can have anonymous items if you really want I guess). And this
will be much more common than a frame with a panel once yous start
with images. Putting a Tux (or Mandriva star logo) image next to each
Linux kernel menu item would require either an element that can
display an image with description or a three element combo panel {
image{} text{} } for each item.

>
> But on the other hand, I believe background image is quite common and
> could be used by other component, so why not just make background
> image an optional parameter for all components. To have a plain image,
> we can use a panel with the specific background.

Yes, people will certainly want background images and decorations.

>
>>> button - button
>>
>> What's the difference between label and button?
>> What would the button typically do?
>
> Button is a panel with text in the middle, it's quite common in dialog
> boxes such as YES/NO/CANCE, so I guess it deserves its own component.

I don't think so.

>
> On second through, this component should not be implemented in C,
> perhaps we can add component tree so that users can write customized
> component in config file, something like this:
>
> + component
> {
>  + button
>  {
>    + panel
>    {
>      + text
>      {
>        valign = "center"
>        halign = "center"
>        text = "$text"
>      }
>    }
>  }
>
> Then we can create buttons like this:
>
> + button
> {
>  text = "hello"
> }
>
> Although implementation is not trivial, so this may be come up in a
> later version.


Why not just

label {
class = button
text = YES
}

style (class = button) {
>        valign = "center"
>        halign = "center"
}

>
>>
>>> list - list box
>>
>> What's the difference between panel containing multiple labels and a list box?
>>
>
> List box has actions like select an item, jump to next item. And it
> could scroll the panel if we jump to items outside the viewport.

This should be part of any panel. It should allow selecting any child
that can get focus (is or contains a label with a bound action)

If you get unexpectedly small screen space you should be able to
scroll any panel that does not fit.

>
>>> edit - multi-line edit box
>>
>> Yes, this is actually useful compound element. A multiline edit is
>> more that a bunch of single line edits stacked inside a panel.
>>
>> I guess it should be possible to have a single-line edit or password
>> edit. Currently grub does not have passwords in gfxterm so no such
>> thing is used but they are in planning.
>> This is probably also possible by limiting the multiline edit to single line.
>>
>>> term - terminal emulator  (extends edit component)
>>> menu - menu list (extends list box)
>>
>> How does it differ from a listbox?
>
> Menu has specific actions like reading the menu items from environment

When this would be used?

> variable, boot menu item, edit menu item.

It should be possible to bind an action ( arbitrary editable list of
grub commands ) to any label.

It may be desirable to disable editing of some actions or have editing
(or even starting) the action protected by password.

>
>> I would rather have as few elements as possible.
>>
>> This way the implementation of the elements should be smaller and
>> easier to maintain.
>>
>> Styling the menu should be easier with fewer elements with fewer
>> baroque properties and obscure limitations.
>
> Yep, perhaps some of the above component can be implemented as user
> defined component in config file. The UI is quite straightforward,
> just stack the components together, but action are a little tricky,
> each component should have a set of default handler. Perhaps we need
> to export some of the component functions to be used in config
> scripts.

What the default handler should be?

In a GUI with panel and label elements (or similar) the panels should
be able to switch between their children that can get focus, and the
labels execute their bound action (if any).

This means that a handler for executing, editing, and password
protecting an action is needed for labels.

Getting focus somewhere without a mouse can be tricky so I suggest
replicating the functionality present in gfxterm at first: one menu
that has focus initially and can be used to select boot commands.

Either the menu that gets focus can be specified explicitly (and will
be the only element usable except for hotkeys) or a more general
solution that determines the correct item automatically can be
implemented.

To this end first the system should determine which elements can get
focus when they are created. Labels without actions do not get focus.
Labels with action and a hotkey normally do not need focus so they
should not get it unless explicitly specified.

If a panel contains a focusable label it can get focus, If it contains
only one it cannot switch focus which is somewhat important.

A vertically stacked panel (like the menu in gfxterm) that contains
only elements that cannot switch focus (labels and single label
panels) can handle up and down arrow keys (and perhaps pgup/pgdn) or
equivalent by switching focus between its children. Optionally if a
vertical panel that only contains horizontal panels it can still use
the keys for vertical movement. And the other way around.

A panel that contains multiple elements that can switch focus should
handle tab key by switching to the next element if it is not on the
last element (in which case it will let the parent panel to handle the
key). If it also contains an element that cannot switch focus and
focus is in that element it can handle directional keys but this
situation is generally not desirable and should be prevented by
building balanced element structure.

Finally a focused label can handle Enter or Space or similar by
executing its action (or asking a password first if required) and some
hotkey like E by opening action editor.

This way you should never notice any trickery with a simple menu like
the one in gfxterm but should be able to get to any focusable element
of any structure.

>>>
>>> We should be able to construct more powerful component using the above
>>> simple ones, I'm considering adding a dialog tree:
>>>
>>> + dialog
>>> {
>>>  + edit
>>>  {
>>>    + window
>>>    {
>>>      class = "edit"
>>>      + edit
>>>      {
>>>      }
>>>    }
>>>  }
>>>  + message
>>>  {
>>>    + window
>>>     {
>>>       class = "message"
>>>       + label
>>>       {
>>>         text = $1
>>>       }
>>>     }
>>>  }
>>> }
>>
>> Couldn't this be done as a function in the support shell scripts that
>> are used for generating the grub.cfg?
>>
>>>
>>> Then we can use something like this to show a popup message dialog:
>>>
>>> popup message "Hello World"
>>
>> What would you report in these popups?
>>
>> Currently grub messages only happen outside of the menu while booting.
>>
>
> For example, when user press F1, we can show a help box. Or if

That sounds useful but I would probably make it a shell function in
the library of functions that are used in grub.d like

message ()
{
cat <<END
+ panel {
 class = message
  + label {
   class = message_text
   text = $1
  }
 + panel {
  class = buttonbar
  + label {
   class = button,ok
   text=OK
  }
 }
}
END
}

style (class = message) { direction = bottom }
style (class = buttonbar) { direction = left } #stack buttons from the right

> something goes wrong, we popup a error message box to indicate what
> happen.

This would likely require quite a bit of changes in how errors are reported.



2009/9/9 Bean <bean123ch@gmail.com>:
> On Wed, Sep 9, 2009 at 10:50 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
>> 2009/9/8 Bean <bean123ch@gmail.com>:
>>> Hi,
>>>
>>> After more consideration, perhaps we should use the following
>>> component structure:
>>>
>>> frame - window border
>>> panel - layout manager with scroll bar support
>>> window - frame + panel
>>> label - text
>>> image - image
>>> button - button
>>> list - list box
>>> edit - multi-line edit box
>>> term - terminal emulator  (extends edit component)
>>> menu - menu list (extends list box)
>>
>> Also how is the menu shown?
>>
>> Currently the menu is implicitly shown if defined but with this
>> extended menu system you can create multiple "windows".
>>
>> There could be a menu with some magic ID that is shown automatically
>> if defined after config parsing ends.
>>
>> Another approach is adding a show command that shows a particular
>> element (with its subelements) as the main window on the screen, This
>> would be likely implicitly present in the edit command for the menu
>> items that have some action bound to them.
>>
>> To make the window management simple every time only a single window
>> would be shown - they could be pushed onto a window stack so that if a
>> popup (such as the action edit popup) is closed the previous window is
>> restored.
>
> Hi,
>
> We can have a menu tree like this:
>
> + menu
> {
>  + main
>  {
>    + item
>    {
>      class = "chainloader"
>      name = "Chainloader"
>      command = "chainloader +1\nboot"
>    }
>  }
>  + tools
>  {
>  }
> }
>
> The menuitem command adds to the main menu by default, but it could be
> overwritten with a option. In menu component, we uses an attribute to
> set the menu name.

This looks like one of us is speaking Chinese .. how does the answer
relate to the quoted text?

I mean in gfxterm you have a boot menu with items and stuff and if you
press the E key this is replaced with an editor, and if you press ESC
the editor is closed and the menu is restored, and if you press C it's
pretty much same as E except you do not get a window border .. so this
can be modeled as

 - grub opens a menu (a panel element either specified explicitly or
having a particular main menu id) after reading the config
 - the hotkey ( C or E ) opens a new window (terminal or text editor)
which is pushed on window stack becoming the top = displayed window
 - the ESC hotkey closes the window previously opened by C or E so the
previous window on the stack = the main menu becomes the top =
displayed window

There is nothing stopping you from opening menus other than the main
menu or putting two columns instead of one, ...

Thanks

Michal

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

[Bean]

On Thu, Sep 10, 2009 at 8:38 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> hello
>
> 2009/9/9 Bean <bean123ch@gmail.com>:
>> On Wed, Sep 9, 2009 at 6:53 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
>>> 2009/9/8 Bean <bean123ch@gmail.com>:
>>>> Hi,
>>>>
>>>> After more consideration, perhaps we should use the following
>>>> component structure:
>>>>
>>>> frame - window border
>>>> panel - layout manager with scroll bar support
>>>> window - frame + panel
>>>
>>> What has window that frame+panel does no have?
>>>
>>> I think it is reasonable to just put two elements when this
>>> functionality is wanted.
>>
>> Hi,
>>
>> Windows can also has a title bar. Although this function may not be
>> implemented in the first version, it's better to keep the component
>
> What for? It's of some use in complex multiwindow environments where
> users are hopelessly lost. We do not wan  to get there with grub (and
> cannot for lack of threading) so it is quite pointless to have a title
> bar.
>
> And in case you do want a titlebar for your window you can add a panel
> around it with a text label. With the added flexibility that you can
> change the directions in which elements are packed in the panel at
> whim even in a theme so you can get the title next to the window
> content (perhaps to stuff more menu items into a small widescreen).
>

Hi,

There are other uses for window. For example, you can move/resize the
window, or click a button to maximize/close it. Although this requires
mouse support, so perhaps this component can wait until later
versions.

>> there. And the frame+panel combo is often used, so having a window
>> component would make the config file cleaner.
>
> If you add a panel border there is much less need for yet another one.
>
> And the config is going to be repetitive whatever you do. Adding a
> keyword and a pair of bracers somewhere is nothing compared to the
> long kernel argument lists.
>
>>
>>>> label - text
>>>> image - image
>>>
>>> I don't think that image is a useful user-acessible component. Even if
>>> images are internally rendered differently from text there is no
>>> reason for image to be a separate component. Grub has no means of
>>> converting images to ascii art for displaying in text mode. Even if it
>>> did there is no guarantee that two images that looked distinct
>>> originally are converted to ascii art blobs that can be told apart.
>>>
>>> If you envision using ascii art a lot in grub then perhaps it should
>>> be implemented as a special graphics format that can be also displayed
>>> in text console. Still ascii art does not work on dumb terminals,
>>> braille terminals, etc.
>>>
>>> IMHO we should not encourage components that have only graphical (or
>>> semi-graphical) representation that cannot be represented as plain
>>> text. If an icon or image is wanted it should be packed into a label
>>> with a plaintext description. It is possible to hide the description
>>> when the element is shown on display that can render graphics (or use
>>> an empty description) but there should be no image-only component.
>>>
>>
>> Originally, I  add image so that component only implement one
>> function, for example, if we merge label and image, we need to use
>> switch statement on the attributes to know if it's a label or image.
>
> It's not a label or image, it's a label with an image (both optional,
> you can have anonymous items if you really want I guess). And this
> will be much more common than a frame with a panel once yous start
> with images. Putting a Tux (or Mandriva star logo) image next to each
> Linux kernel menu item would require either an element that can
> display an image with description or a three element combo panel {
> image{} text{} } for each item.
>

Oh, image plus text looks composite component to me, although if it's
used often enough, we can write a C component to handle this combo.

>>
>> But on the other hand, I believe background image is quite common and
>> could be used by other component, so why not just make background
>> image an optional parameter for all components. To have a plain image,
>> we can use a panel with the specific background.
>
> Yes, people will certainly want background images and decorations.
>
>>
>>>> button - button
>>>
>>> What's the difference between label and button?
>>> What would the button typically do?
>>
>> Button is a panel with text in the middle, it's quite common in dialog
>> boxes such as YES/NO/CANCE, so I guess it deserves its own component.
>
> I don't think so.
>
>>
>> On second through, this component should not be implemented in C,
>> perhaps we can add component tree so that users can write customized
>> component in config file, something like this:
>>
>> + component
>> {
>>  + button
>>  {
>>    + panel
>>    {
>>      + text
>>      {
>>        valign = "center"
>>        halign = "center"
>>        text = "$text"
>>      }
>>    }
>>  }
>>
>> Then we can create buttons like this:
>>
>> + button
>> {
>>  text = "hello"
>> }
>>
>> Although implementation is not trivial, so this may be come up in a
>> later version.
>
>
> Why not just
>
> label {
> class = button
> text = YES
> }
>
> style (class = button) {
>>        valign = "center"
>>        halign = "center"
> }
>

Right, for simple types like button, it could be merged with label.
But it'd still be useful to allow users to create new component type
in config file by customizing existing components. But this feature is
not easy to implement, it could be added in a later version.

>>
>>>
>>>> list - list box
>>>
>>> What's the difference between panel containing multiple labels and a list box?
>>>
>>
>> List box has actions like select an item, jump to next item. And it
>> could scroll the panel if we jump to items outside the viewport.
>
> This should be part of any panel. It should allow selecting any child
> that can get focus (is or contains a label with a bound action)
>
> If you get unexpectedly small screen space you should be able to
> scroll any panel that does not fit.
>
>>
>>>> edit - multi-line edit box
>>>
>>> Yes, this is actually useful compound element. A multiline edit is
>>> more that a bunch of single line edits stacked inside a panel.
>>>
>>> I guess it should be possible to have a single-line edit or password
>>> edit. Currently grub does not have passwords in gfxterm so no such
>>> thing is used but they are in planning.
>>> This is probably also possible by limiting the multiline edit to single line.
>>>
>>>> term - terminal emulator  (extends edit component)
>>>> menu - menu list (extends list box)
>>>
>>> How does it differ from a listbox?
>>
>> Menu has specific actions like reading the menu items from environment
>
> When this would be used?
>
>> variable, boot menu item, edit menu item.
>
> It should be possible to bind an action ( arbitrary editable list of
> grub commands ) to any label.
>
> It may be desirable to disable editing of some actions or have editing
> (or even starting) the action protected by password.
>
>>
>>> I would rather have as few elements as possible.
>>>
>>> This way the implementation of the elements should be smaller and
>>> easier to maintain.
>>>
>>> Styling the menu should be easier with fewer elements with fewer
>>> baroque properties and obscure limitations.
>>
>> Yep, perhaps some of the above component can be implemented as user
>> defined component in config file. The UI is quite straightforward,
>> just stack the components together, but action are a little tricky,
>> each component should have a set of default handler. Perhaps we need
>> to export some of the component functions to be used in config
>> scripts.
>
> What the default handler should be?
>
> In a GUI with panel and label elements (or similar) the panels should
> be able to switch between their children that can get focus, and the
> labels execute their bound action (if any).
>
> This means that a handler for executing, editing, and password
> protecting an action is needed for labels.
>
> Getting focus somewhere without a mouse can be tricky so I suggest
> replicating the functionality present in gfxterm at first: one menu
> that has focus initially and can be used to select boot commands.
>
> Either the menu that gets focus can be specified explicitly (and will
> be the only element usable except for hotkeys) or a more general
> solution that determines the correct item automatically can be
> implemented.
>
> To this end first the system should determine which elements can get
> focus when they are created. Labels without actions do not get focus.
> Labels with action and a hotkey normally do not need focus so they
> should not get it unless explicitly specified.
>
> If a panel contains a focusable label it can get focus, If it contains
> only one it cannot switch focus which is somewhat important.
>
> A vertically stacked panel (like the menu in gfxterm) that contains
> only elements that cannot switch focus (labels and single label
> panels) can handle up and down arrow keys (and perhaps pgup/pgdn) or
> equivalent by switching focus between its children. Optionally if a
> vertical panel that only contains horizontal panels it can still use
> the keys for vertical movement. And the other way around.
>
> A panel that contains multiple elements that can switch focus should
> handle tab key by switching to the next element if it is not on the
> last element (in which case it will let the parent panel to handle the
> key). If it also contains an element that cannot switch focus and
> focus is in that element it can handle directional keys but this
> situation is generally not desirable and should be prevented by
> building balanced element structure.
>
> Finally a focused label can handle Enter or Space or similar by
> executing its action (or asking a password first if required) and some
> hotkey like E by opening action editor.
>
> This way you should never notice any trickery with a simple menu like
> the one in gfxterm but should be able to get to any focusable element
> of any structure.
>

The above handling sounds good, but I'd prefer not to use fixed keys.
Each component can define certain actions, and we bind them to
specific key using the onkey handler.

>>>>
>>>> We should be able to construct more powerful component using the above
>>>> simple ones, I'm considering adding a dialog tree:
>>>>
>>>> + dialog
>>>> {
>>>>  + edit
>>>>  {
>>>>    + window
>>>>    {
>>>>      class = "edit"
>>>>      + edit
>>>>      {
>>>>      }
>>>>    }
>>>>  }
>>>>  + message
>>>>  {
>>>>    + window
>>>>     {
>>>>       class = "message"
>>>>       + label
>>>>       {
>>>>         text = $1
>>>>       }
>>>>     }
>>>>  }
>>>> }
>>>
>>> Couldn't this be done as a function in the support shell scripts that
>>> are used for generating the grub.cfg?
>>>
>>>>
>>>> Then we can use something like this to show a popup message dialog:
>>>>
>>>> popup message "Hello World"
>>>
>>> What would you report in these popups?
>>>
>>> Currently grub messages only happen outside of the menu while booting.
>>>
>>
>> For example, when user press F1, we can show a help box. Or if
>
> That sounds useful but I would probably make it a shell function in
> the library of functions that are used in grub.d like
>
> message ()
> {
> cat <<END
> + panel {
>  class = message
>  + label {
>   class = message_text
>   text = $1
>  }
>  + panel {
>  class = buttonbar
>  + label {
>   class = button,ok
>   text=OK
>  }
>  }
> }
> END
> }
>
> style (class = message) { direction = bottom }
> style (class = buttonbar) { direction = left } #stack buttons from the right

Yep, this would be useful. But using tree structure means we can reuse
the parser for component, otherwise we need to modified sh parser to
handle the new syntax. It's doable, but require more work, perhaps we
can delay it until later version.

>
>> something goes wrong, we popup a error message box to indicate what
>> happen.
>
> This would likely require quite a bit of changes in how errors are reported.
>

Module that take advantage of this feature need to call a function
explicitly, perhaps grub_show_error (s), then old code doesn't need to
be modified.

> This looks like one of us is speaking Chinese .. how does the answer
> relate to the quoted text?
>
> I mean in gfxterm you have a boot menu with items and stuff and if you
> press the E key this is replaced with an editor, and if you press ESC
> the editor is closed and the menu is restored, and if you press C it's
> pretty much same as E except you do not get a window border .. so this
> can be modeled as
>
>  - grub opens a menu (a panel element either specified explicitly or
> having a particular main menu id) after reading the config
>  - the hotkey ( C or E ) opens a new window (terminal or text editor)
> which is pushed on window stack becoming the top = displayed window
>  - the ESC hotkey closes the window previously opened by C or E so the
> previous window on the stack = the main menu becomes the top =
> displayed window
>
> There is nothing stopping you from opening menus other than the main
> menu or putting two columns instead of one, ...

Oh sorry, I misunderstand your previous post, window stack looks good to me.

-- 
Bean

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

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

[Michal Suchanek]

2009/9/10 Bean <bean123ch@gmail.com>:
> On Thu, Sep 10, 2009 at 8:38 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> hello
>>
>> 2009/9/9 Bean <bean123ch@gmail.com>:
>>> On Wed, Sep 9, 2009 at 6:53 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
>>>> 2009/9/8 Bean <bean123ch@gmail.com>:
>>>>> Hi,
>>>>>
>>>>> After more consideration, perhaps we should use the following
>>>>> component structure:
>>>>>
>>>>> frame - window border
>>>>> panel - layout manager with scroll bar support
>>>>> window - frame + panel
>>>>
>>>> What has window that frame+panel does no have?
>>>>
>>>> I think it is reasonable to just put two elements when this
>>>> functionality is wanted.
>>>
>>> Hi,
>>>
>>> Windows can also has a title bar. Although this function may not be
>>> implemented in the first version, it's better to keep the component
>>
>> What for? It's of some use in complex multiwindow environments where
>> users are hopelessly lost. We do not wan  to get there with grub (and
>> cannot for lack of threading) so it is quite pointless to have a title
>> bar.
>>
>> And in case you do want a titlebar for your window you can add a panel
>> around it with a text label. With the added flexibility that you can
>> change the directions in which elements are packed in the panel at
>> whim even in a theme so you can get the title next to the window
>> content (perhaps to stuff more menu items into a small widescreen).
>>
>
> Hi,
>
> There are other uses for window. For example, you can move/resize the
> window, or click a button to maximize/close it. Although this requires
> mouse support, so perhaps this component can wait until later
> versions.

I don't know why you would move or resize a window. If there is only
one window displayed it should get sized and placed reasonably from
the start. Since grub has no threading you cannot have something like
two applications running in parallel. At least we have nothing
remotely similar to that now and I do not know about any plans for
that either.

>
>>> there. And the frame+panel combo is often used, so having a window
>>> component would make the config file cleaner.
>>
>> If you add a panel border there is much less need for yet another one.
>>
>> And the config is going to be repetitive whatever you do. Adding a
>> keyword and a pair of bracers somewhere is nothing compared to the
>> long kernel argument lists.
>>
>>>
>>>>> label - text
>>>>> image - image
>>>>
>>>> I don't think that image is a useful user-acessible component. Even if
>>>> images are internally rendered differently from text there is no
>>>> reason for image to be a separate component. Grub has no means of
>>>> converting images to ascii art for displaying in text mode. Even if it
>>>> did there is no guarantee that two images that looked distinct
>>>> originally are converted to ascii art blobs that can be told apart.
>>>>
>>>> If you envision using ascii art a lot in grub then perhaps it should
>>>> be implemented as a special graphics format that can be also displayed
>>>> in text console. Still ascii art does not work on dumb terminals,
>>>> braille terminals, etc.
>>>>
>>>> IMHO we should not encourage components that have only graphical (or
>>>> semi-graphical) representation that cannot be represented as plain
>>>> text. If an icon or image is wanted it should be packed into a label
>>>> with a plaintext description. It is possible to hide the description
>>>> when the element is shown on display that can render graphics (or use
>>>> an empty description) but there should be no image-only component.
>>>>
>>>
>>> Originally, I  add image so that component only implement one
>>> function, for example, if we merge label and image, we need to use
>>> switch statement on the attributes to know if it's a label or image.
>>
>> It's not a label or image, it's a label with an image (both optional,
>> you can have anonymous items if you really want I guess). And this
>> will be much more common than a frame with a panel once yous start
>> with images. Putting a Tux (or Mandriva star logo) image next to each
>> Linux kernel menu item would require either an element that can
>> display an image with description or a three element combo panel {
>> image{} text{} } for each item.
>>
>
> Oh, image plus text looks composite component to me, although if it's
> used often enough, we can write a C component to handle this combo.

There are two reasons to make this the basic label component:

 - if you need just text the image is simply omitted at no cost to the user
 - if you want an image and there is only a component that displays an
image and text it should hint the user to also include a description
 - adding icons to boot menu items is probably going to be the most
common use of images so managing the compound in a single component
should ease writing config files
 - you can probably add the image later like

+ panel {
class = main
 + label {
   class = grub_title
   text = Grub $version
  }
 + panel {
  class = boot_menu
  + label {
   class = linux
   action {
    linux /boot/vmlinuz...
 ...

style (class = linux) {
  icon = Tux.png
  icon-position = left
}
>
>>>
>>> But on the other hand, I believe background image is quite common and
>>> could be used by other component, so why not just make background
>>> image an optional parameter for all components. To have a plain image,
>>> we can use a panel with the specific background.
>>
>> Yes, people will certainly want background images and decorations.
>>
>>>
>>>>> button - button
>>>>
>>>> What's the difference between label and button?
>>>> What would the button typically do?
>>>
>>> Button is a panel with text in the middle, it's quite common in dialog
>>> boxes such as YES/NO/CANCE, so I guess it deserves its own component.
>>
>> I don't think so.
>>
>>>
>>> On second through, this component should not be implemented in C,
>>> perhaps we can add component tree so that users can write customized
>>> component in config file, something like this:
>>>
>>> + component
>>> {
>>>  + button
>>>  {
>>>    + panel
>>>    {
>>>      + text
>>>      {
>>>        valign = "center"
>>>        halign = "center"
>>>        text = "$text"
>>>      }
>>>    }
>>>  }
>>>
>>> Then we can create buttons like this:
>>>
>>> + button
>>> {
>>>  text = "hello"
>>> }
>>>
>>> Although implementation is not trivial, so this may be come up in a
>>> later version.
>>
>>
>> Why not just
>>
>> label {
>> class = button
>> text = YES
>> }
>>
>> style (class = button) {
>>>        valign = "center"
>>>        halign = "center"
>> }
>>
>
> Right, for simple types like button, it could be merged with label.
> But it'd still be useful to allow users to create new component type
> in config file by customizing existing components. But this feature is
> not easy to implement, it could be added in a later version.

I think that styling based on some user-defined selectors (shown as
class in the mockups) gives pretty much all you can get this way
without scripting new components in lua or something.

Unfortunately the components written in C probably would not be very
extensible. If I decided I am bored with rectangular panels and wanted
a different shape it would be probably hard to write a new layout
manager for panel in lua and add it to the existing panel.

>
>>>
>>>>
>>>>> list - list box
>>>>
>>>> What's the difference between panel containing multiple labels and a list box?
>>>>
>>>
>>> List box has actions like select an item, jump to next item. And it
>>> could scroll the panel if we jump to items outside the viewport.
>>
>> This should be part of any panel. It should allow selecting any child
>> that can get focus (is or contains a label with a bound action)
>>
>> If you get unexpectedly small screen space you should be able to
>> scroll any panel that does not fit.
>>
>>>
>>>>> edit - multi-line edit box
>>>>
>>>> Yes, this is actually useful compound element. A multiline edit is
>>>> more that a bunch of single line edits stacked inside a panel.
>>>>
>>>> I guess it should be possible to have a single-line edit or password
>>>> edit. Currently grub does not have passwords in gfxterm so no such
>>>> thing is used but they are in planning.
>>>> This is probably also possible by limiting the multiline edit to single line.
>>>>
>>>>> term - terminal emulator  (extends edit component)
>>>>> menu - menu list (extends list box)
>>>>
>>>> How does it differ from a listbox?
>>>
>>> Menu has specific actions like reading the menu items from environment
>>
>> When this would be used?
>>
>>> variable, boot menu item, edit menu item.
>>
>> It should be possible to bind an action ( arbitrary editable list of
>> grub commands ) to any label.
>>
>> It may be desirable to disable editing of some actions or have editing
>> (or even starting) the action protected by password.
>>
>>>
>>>> I would rather have as few elements as possible.
>>>>
>>>> This way the implementation of the elements should be smaller and
>>>> easier to maintain.
>>>>
>>>> Styling the menu should be easier with fewer elements with fewer
>>>> baroque properties and obscure limitations.
>>>
>>> Yep, perhaps some of the above component can be implemented as user
>>> defined component in config file. The UI is quite straightforward,
>>> just stack the components together, but action are a little tricky,
>>> each component should have a set of default handler. Perhaps we need
>>> to export some of the component functions to be used in config
>>> scripts.
>>
>> What the default handler should be?
>>
>> In a GUI with panel and label elements (or similar) the panels should
>> be able to switch between their children that can get focus, and the
>> labels execute their bound action (if any).
>>
>> This means that a handler for executing, editing, and password
>> protecting an action is needed for labels.
>>
>> Getting focus somewhere without a mouse can be tricky so I suggest
>> replicating the functionality present in gfxterm at first: one menu
>> that has focus initially and can be used to select boot commands.
>>
>> Either the menu that gets focus can be specified explicitly (and will
>> be the only element usable except for hotkeys) or a more general
>> solution that determines the correct item automatically can be
>> implemented.
>>
>> To this end first the system should determine which elements can get
>> focus when they are created. Labels without actions do not get focus.
>> Labels with action and a hotkey normally do not need focus so they
>> should not get it unless explicitly specified.
>>
>> If a panel contains a focusable label it can get focus, If it contains
>> only one it cannot switch focus which is somewhat important.
>>
>> A vertically stacked panel (like the menu in gfxterm) that contains
>> only elements that cannot switch focus (labels and single label
>> panels) can handle up and down arrow keys (and perhaps pgup/pgdn) or
>> equivalent by switching focus between its children. Optionally if a
>> vertical panel that only contains horizontal panels it can still use
>> the keys for vertical movement. And the other way around.
>>
>> A panel that contains multiple elements that can switch focus should
>> handle tab key by switching to the next element if it is not on the
>> last element (in which case it will let the parent panel to handle the
>> key). If it also contains an element that cannot switch focus and
>> focus is in that element it can handle directional keys but this
>> situation is generally not desirable and should be prevented by
>> building balanced element structure.
>>
>> Finally a focused label can handle Enter or Space or similar by
>> executing its action (or asking a password first if required) and some
>> hotkey like E by opening action editor.
>>
>> This way you should never notice any trickery with a simple menu like
>> the one in gfxterm but should be able to get to any focusable element
>> of any structure.
>>
>
> The above handling sounds good, but I'd prefer not to use fixed keys.
> Each component can define certain actions, and we bind them to
> specific key using the onkey handler.

I am using the current key bindings in gfxterm to make this clear.
Obviously these can be changed but the default should mimic current
gfxterm to ease transition from older grub.

>
>>>>>
>>>>> We should be able to construct more powerful component using the above
>>>>> simple ones, I'm considering adding a dialog tree:
>>>>>
>>>>> + dialog
>>>>> {
>>>>>  + edit
>>>>>  {
>>>>>    + window
>>>>>    {
>>>>>      class = "edit"
>>>>>      + edit
>>>>>      {
>>>>>      }
>>>>>    }
>>>>>  }
>>>>>  + message
>>>>>  {
>>>>>    + window
>>>>>     {
>>>>>       class = "message"
>>>>>       + label
>>>>>       {
>>>>>         text = $1
>>>>>       }
>>>>>     }
>>>>>  }
>>>>> }
>>>>
>>>> Couldn't this be done as a function in the support shell scripts that
>>>> are used for generating the grub.cfg?
>>>>
>>>>>
>>>>> Then we can use something like this to show a popup message dialog:
>>>>>
>>>>> popup message "Hello World"
>>>>
>>>> What would you report in these popups?
>>>>
>>>> Currently grub messages only happen outside of the menu while booting.
>>>>
>>>
>>> For example, when user press F1, we can show a help box. Or if
>>
>> That sounds useful but I would probably make it a shell function in
>> the library of functions that are used in grub.d like
>>
>> message ()
>> {
>> cat <<END
>> + panel {
>>  class = message
>>  + label {
>>   class = message_text
>>   text = $1
>>  }
>>  + panel {
>>  class = buttonbar
>>  + label {
>>   class = button,ok
>>   text=OK
>>  }
>>  }
>> }
>> END
>> }
>>
>> style (class = message) { direction = bottom }
>> style (class = buttonbar) { direction = left } #stack buttons from the right
>
> Yep, this would be useful. But using tree structure means we can reuse
> the parser for component, otherwise we need to modified sh parser to
> handle the new syntax. It's doable, but require more work, perhaps we
> can delay it until later version.

We don't need a shell parser, it's in the shell already, and we cannot
modify it, it's outside of grub.

I do not get what you meant here.

The shell is already used to execute /etc/grub.d/* and
/usr/lib/grub/grub-mkconfig_lib and there are many utility functions
in /usr/lib/grub/grub-mkconfig_lib for creating grub.cfg snippets.

There is no need to make everything in grub if it's simple enough to
be written in a shell function outside of grub.

Thanks

Michal

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

[Bean]

On Thu, Sep 10, 2009 at 3:26 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> I don't know why you would move or resize a window. If there is only
> one window displayed it should get sized and placed reasonably from
> the start. Since grub has no threading you cannot have something like
> two applications running in parallel. At least we have nothing
> remotely similar to that now and I do not know about any plans for
> that either.

There could be more than one window, for example, we can have a menu
window and terminal window, user uses ctrl-tab to switch between them.
Only one of them receives input focus, so threading is not needed. And
it can also be used for small widgets like clock. Although some of
feature like the mouse support is not implemented yet, so windows is
not very useful at this point.

> There are two reasons to make this the basic label component:
>
>  - if you need just text the image is simply omitted at no cost to the user
>  - if you want an image and there is only a component that displays an
> image and text it should hint the user to also include a description
>  - adding icons to boot menu items is probably going to be the most
> common use of images so managing the compound in a single component
> should ease writing config files
>  - you can probably add the image later like
>
> + panel {
> class = main
>  + label {
>   class = grub_title
>   text = Grub $version
>  }
>  + panel {
>  class = boot_menu
>  + label {
>   class = linux
>   action {
>    linux /boot/vmlinuz...
>  ...
>
> style (class = linux) {
>  icon = Tux.png
>  icon-position = left
> }

I believe we have approached this in different direction. I'm more
inclined to create simple component first, then build complex ones
from it, while you like component that can handle many situation. The
end result would be the same, but I think my approach is more
extensible:

text - text only
image - image only
label - text plus image

For normal user, label would be enough, but if he wants to create
customized components in grub/lua script, it'd be useful to access
lower level components like text and image.

> I think that styling based on some user-defined selectors (shown as
> class in the mockups) gives pretty much all you can get this way
> without scripting new components in lua or something.
>
> Unfortunately the components written in C probably would not be very
> extensible. If I decided I am bored with rectangular panels and wanted
> a different shape it would be probably hard to write a new layout
> manager for panel in lua and add it to the existing panel.

The class method only works for one component, it won't work if it
involves more than one component. For example, we can define a confirm
dialog box with a panel, a label and the YES/NO button.

> I am using the current key bindings in gfxterm to make this clear.
> Obviously these can be changed but the default should mimic current
> gfxterm to ease transition from older grub.

Ok.

> We don't need a shell parser, it's in the shell already, and we cannot
> modify it, it's outside of grub.
>
> I do not get what you meant here.
>
> The shell is already used to execute /etc/grub.d/* and
> /usr/lib/grub/grub-mkconfig_lib and there are many utility functions
> in /usr/lib/grub/grub-mkconfig_lib for creating grub.cfg snippets.
>
> There is no need to make everything in grub if it's simple enough to
> be written in a shell function outside of grub.

Oh, I thought you mean the sh parser in grub.cfg, whose function is
quite limited.

-- 
Bean

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

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

[Michal Suchanek]

2009/9/10 Bean <bean123ch@gmail.com>:
> On Thu, Sep 10, 2009 at 3:26 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> I don't know why you would move or resize a window. If there is only
>> one window displayed it should get sized and placed reasonably from
>> the start. Since grub has no threading you cannot have something like
>> two applications running in parallel. At least we have nothing
>> remotely similar to that now and I do not know about any plans for
>> that either.
>
> There could be more than one window, for example, we can have a menu
> window and terminal window, user uses ctrl-tab to switch between them.
> Only one of them receives input focus, so threading is not needed. And
> it can also be used for small widgets like clock. Although some of
> feature like the mouse support is not implemented yet, so windows is
> not very useful at this point.

Why do you need two windows for that?

You can put a terminal and a menu into a single window. That's
actually what most terminal emulators do.

I don't think grub should start doing window management. It does not
share the screen with anything else, packing multiple elements loosely
so that they can be moved only wastes screen space and window
management adds complexity with no benefit.

>
>> There are two reasons to make this the basic label component:
>>
>>  - if you need just text the image is simply omitted at no cost to the user
>>  - if you want an image and there is only a component that displays an
>> image and text it should hint the user to also include a description
>>  - adding icons to boot menu items is probably going to be the most
>> common use of images so managing the compound in a single component
>> should ease writing config files
>>  - you can probably add the image later like
>>
>> + panel {
>> class = main
>>  + label {
>>   class = grub_title
>>   text = Grub $version
>>  }
>>  + panel {
>>  class = boot_menu
>>  + label {
>>   class = linux
>>   action {
>>    linux /boot/vmlinuz...
>>  ...
>>
>> style (class = linux) {
>>  icon = Tux.png
>>  icon-position = left
>> }
>
> I believe we have approached this in different direction. I'm more
> inclined to create simple component first, then build complex ones
> from it, while you like component that can handle many situation. The
> end result would be the same, but I think my approach is more
> extensible:
>
> text - text only
> image - image only
> label - text plus image
>
> For normal user, label would be enough, but if he wants to create
> customized components in grub/lua script, it'd be useful to access
> lower level components like text and image.

Yes, primitive drawing functions should be available in lua for
creating custom components. But that would not be a text component but
functions to draw text, images, etc.

Perhaps it would be a good idea to implement a sample component in lua
to find out what parts of the C components can be reused and should be
exported.

Creating components in advance only to be used as part of lua
scripting may be a case of premature optimization. At this point it is
not obvious if such components are helpful and what components would
be needed.

>
>> I think that styling based on some user-defined selectors (shown as
>> class in the mockups) gives pretty much all you can get this way
>> without scripting new components in lua or something.
>>
>> Unfortunately the components written in C probably would not be very
>> extensible. If I decided I am bored with rectangular panels and wanted
>> a different shape it would be probably hard to write a new layout
>> manager for panel in lua and add it to the existing panel.
>
> The class method only works for one component, it won't work if it
> involves more than one component. For example, we can define a confirm
> dialog box with a panel, a label and the YES/NO button.

It must work.

For a dialog like

+ panel {
  class = mydialog
  + label {
   class = text
    text = some message
  }
  + panel {
   class = buttonbar
   + label {
    class = button,yes
    text = YES
    action {
    ...
    }
    + label {
     class = button,no
     text = NO
     action {
     ...
     }
   }
 }
}

CSS selector allow something like

.mydialog panel .button

to select a button inside a panel inside a mydialog element.

Similarly X resources allow syntax like

*mydialog*button

to select any buttons in mydialog.

Without a mechanism like this any styling would be hardly possible at all.

Also if the dialog is not a fixed element but rather a compound that
is written into the grub.cfg by update-grub every subelement can be
styled separately with the most flexibility.

Compound components cause great troubles when they are presented as
one opaque element because changing all aspect of such complex element
requires huge number of properties (see the problem with the Mozilla
file upload form element - edit box + button)

Thanks

Michal

About menu interface discussion...

[Robert Millan]

I'd just like to mention that this isn't really good timing for such
discussion, and in fact I'm not following it.  I'm focused on the
1.97 release at this time.

This doesn't mean there's a problem with discussing a menu overhaul,
but if you do, keep in mind my lack of participation doesn't imply
implicit approval.

When the time is right, I'll be glad to talk about proposals like
this one.  In the meantime, my attention will be directed at things
like:

  - grub_vbe_bios_getset_dac_palette_width() regression (memory corruption
    bug).

  - Bugs in filesystems with 64-bit offsets.

which is what our downstream distributors are concerned with.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: About menu interface discussion...

[Lars Nooden]

Robert Millan wrote:
> I'd just like to mention that this isn't really good timing for such
> discussion ... keep in mind my lack of participation doesn't imply
> implicit approval.

+1

> When the time is right...

When is the anticipated release of 1.97?
("When it's time" is an answer, too)

If it's not too far in the distant future, the interface can be
addressed in earnest after the release.

Regards
-Lars

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

[Michal Suchanek]

Hello

I hope this long discussion has not put you off.

I personally would probably go with leaving gfxterm in place until a
better menu is really needed but having a nice customizable menu is
nice and will surely attract more potential grub users.

I want the new menu system to be as simple and extensible as possible
for several reasons.

First people would probably want to write themes for the menu to
change its look in new and unexpected ways. It has been the case with
both grub legacy and syslinux and hopefully by creatind a menu system
flexible enough we could prevent a grub2-with-fancy-graphics fork.

Second if we introduce some features and menu system components now it
will be hard to remove them later so I want to have as few components
as necessary initially and only add new ones if/when there are useful
features not covered by the initial components.

Lastly I will be likely also dealing with the new menu when it gets
into mainline grub so I would like it to be somewhat reasonable.

The problem I see now is that some selector for styling need to be designed.

This should help both people styling the menu and creating distinct
components from the basic ones in the standard menu.

The two systems that I know that have some decent selectors are

 - X resources

  This system has the deficiency that AFAIK each object can have at
most one class. Properties themselves are nodes in the class tree.
Parts if the path in the tree can be omitted.
  Given something like XTerm.vt100.foreground  properties that apply
include this full path, XTerm..foreground (name of one component
omitted) ..foreground (names of two components omitted), *foreground
(applies to any foreground), XTerm*foreground (would also apply to,
say XTerm.foreground)

 - CSS selectors

  These selectors can select by component type, component class, other
attributes, states (like hover, focused, etc), etc.
  Another interesting thing that you can do is styling :first-child.
  However, this is very limited in utility without generalizing to
arbitrary n-th child element and possibly odd/even/modN elements.
  The limitation of these selector is that you can only omit part of
path from the start
  .XTerm .vt100 { foreground = <something> } would refer to that
particular property as could probably something like
  .v100 {}
  window vt100 {}
  I am not sure something like
  .XTerm * {}
  would be valid in CSS

I would think that an option that combines the best of both is
something like X resource selectors with qualifiers that select class
or type or specify nth element.

For example

+ panel {
 class = main_menu
 + label {
   class = main,title # multiple classes
   text = GRUB $version
 }
 + panel {
   class = boot_menu,menu
   + label {
   ....
  }
}

style main_menu*boot_menu.~label {
  text-align: left;
  icon-position: left;
  background-color: blue;
  color: yellow;
}

style main_menu*boot_menu.~label:focused {
  background-color: yellow;
  color: blue;
}

# style the default item differently given default is the number of
the default item
style main_menu*boot_menu.~label[default] {
 color: red;
}

you could probably use

style main_menu*boot_menu. {
style main_menu*boot_menu.:focused {
style main_menu*boot_menu.[default] {

but not having any element specification at the end of the selector
would make it hard to read.

This should allow styling all element reasonably.

The remaining question is how the styles should be resolved in case
multiple selectors would apply to single element.

One simple way is to just process everything in order - that is set
the property at the time the element definition or style definitin is
read from the file.

This has the disadvantage that elements singled out earlier would be
overwritten by a later blanket style covering everything. The
advantage is that completely restyling some aspect of the menu is easy
- you specify a single style that resets all colours and build your
colouring on top of that.
In CSS this is somewhat problematic. The styles with more specific
selectors override styles with less specific selectors - overriding
earlier specific styles requires the !mportant keyword and there are
only two levels, overriding !important is not possible without
duplicating all declarations of the previous styles.

It seems that this is not a problem in X properties, though. This is
probably because unlike HTML+CSS X resources tend to have very few
generic defaults + some very application specific definitions that do
not apply elsewhere so people restyling their desktop only need to set
the properties they would need anyway if they started from scratch.

Given that in Grub we would probably want some initial style it is
probably better choice to override earlier styles with later styles
regardless of specificity. This would probably require walking the
component tree and (re-) set all components when styles are changed
but would not require storing styles separately outside of component
properties.

The most specific style approach probably works better with a separate
style store where each component looks for its style when it redraws
and finds the style with most specific selector for each property
(which can then be cached in its property values until styles change
for the next time).

Another somewhat peculiar issue are the elements that are not part of
user layout. These would be:

enter password box (the thing you would get by trying to run
password-protected action)
edit action box (the thing you get currently in boot menu by pressing e)
edit environment value box (would be useful to set a specific
environment variable without having to start console)

These would be toplelevel (fullscreen windows) created by a grub
command, not defined in the configuration file.
Perhaps their class property could be copied from the label that
executed them so that they can be styled specifically.

ie

+ label {
 text = Change graphics mode
 class = set_gfxmode
 action {
  edit-env gfxmode
  terminal_output gfxterm
 }
}

would create an "edit environment variable" toplevel with class set_gfxmode

Thanks

Michal

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

[Bean]

On Sun, Sep 13, 2009 at 7:26 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> Hello
>
> I hope this long discussion has not put you off.
>
> I personally would probably go with leaving gfxterm in place until a
> better menu is really needed but having a nice customizable menu is
> nice and will surely attract more potential grub users.
>
> I want the new menu system to be as simple and extensible as possible
> for several reasons.
>
> First people would probably want to write themes for the menu to
> change its look in new and unexpected ways. It has been the case with
> both grub legacy and syslinux and hopefully by creatind a menu system
> flexible enough we could prevent a grub2-with-fancy-graphics fork.
>
> Second if we introduce some features and menu system components now it
> will be hard to remove them later so I want to have as few components
> as necessary initially and only add new ones if/when there are useful
> features not covered by the initial components.
>
> Lastly I will be likely also dealing with the new menu when it gets
> into mainline grub so I would like it to be somewhat reasonable.
>
> The problem I see now is that some selector for styling need to be designed.
>
> This should help both people styling the menu and creating distinct
> components from the basic ones in the standard menu.
>
> The two systems that I know that have some decent selectors are
>
>  - X resources
>
>  This system has the deficiency that AFAIK each object can have at
> most one class. Properties themselves are nodes in the class tree.
> Parts if the path in the tree can be omitted.
>  Given something like XTerm.vt100.foreground  properties that apply
> include this full path, XTerm..foreground (name of one component
> omitted) ..foreground (names of two components omitted), *foreground
> (applies to any foreground), XTerm*foreground (would also apply to,
> say XTerm.foreground)
>
>  - CSS selectors
>
>  These selectors can select by component type, component class, other
> attributes, states (like hover, focused, etc), etc.
>  Another interesting thing that you can do is styling :first-child.
>  However, this is very limited in utility without generalizing to
> arbitrary n-th child element and possibly odd/even/modN elements.
>  The limitation of these selector is that you can only omit part of
> path from the start
>  .XTerm .vt100 { foreground = <something> } would refer to that
> particular property as could probably something like
>  .v100 {}
>  window vt100 {}
>  I am not sure something like
>  .XTerm * {}
>  would be valid in CSS
>
> I would think that an option that combines the best of both is
> something like X resource selectors with qualifiers that select class
> or type or specify nth element.
>
> For example
>
> + panel {
>  class = main_menu
>  + label {
>   class = main,title # multiple classes
>   text = GRUB $version
>  }
>  + panel {
>   class = boot_menu,menu
>   + label {
>   ....
>  }
> }
>
> style main_menu*boot_menu.~label {
>  text-align: left;
>  icon-position: left;
>  background-color: blue;
>  color: yellow;
> }
>
> style main_menu*boot_menu.~label:focused {
>  background-color: yellow;
>  color: blue;
> }
>
> # style the default item differently given default is the number of
> the default item
> style main_menu*boot_menu.~label[default] {
>  color: red;
> }
>
> you could probably use
>
> style main_menu*boot_menu. {
> style main_menu*boot_menu.:focused {
> style main_menu*boot_menu.[default] {
>
> but not having any element specification at the end of the selector
> would make it hard to read.
>
> This should allow styling all element reasonably.
>
> The remaining question is how the styles should be resolved in case
> multiple selectors would apply to single element.
>
> One simple way is to just process everything in order - that is set
> the property at the time the element definition or style definitin is
> read from the file.
>
> This has the disadvantage that elements singled out earlier would be
> overwritten by a later blanket style covering everything. The
> advantage is that completely restyling some aspect of the menu is easy
> - you specify a single style that resets all colours and build your
> colouring on top of that.
> In CSS this is somewhat problematic. The styles with more specific
> selectors override styles with less specific selectors - overriding
> earlier specific styles requires the !mportant keyword and there are
> only two levels, overriding !important is not possible without
> duplicating all declarations of the previous styles.
>
> It seems that this is not a problem in X properties, though. This is
> probably because unlike HTML+CSS X resources tend to have very few
> generic defaults + some very application specific definitions that do
> not apply elsewhere so people restyling their desktop only need to set
> the properties they would need anyway if they started from scratch.
>
> Given that in Grub we would probably want some initial style it is
> probably better choice to override earlier styles with later styles
> regardless of specificity. This would probably require walking the
> component tree and (re-) set all components when styles are changed
> but would not require storing styles separately outside of component
> properties.
>
> The most specific style approach probably works better with a separate
> style store where each component looks for its style when it redraws
> and finds the style with most specific selector for each property
> (which can then be cached in its property values until styles change
> for the next time).
>
> Another somewhat peculiar issue are the elements that are not part of
> user layout. These would be:
>
> enter password box (the thing you would get by trying to run
> password-protected action)
> edit action box (the thing you get currently in boot menu by pressing e)
> edit environment value box (would be useful to set a specific
> environment variable without having to start console)
>
> These would be toplelevel (fullscreen windows) created by a grub
> command, not defined in the configuration file.
> Perhaps their class property could be copied from the label that
> executed them so that they can be styled specifically.
>
> ie
>
> + label {
>  text = Change graphics mode
>  class = set_gfxmode
>  action {
>  edit-env gfxmode
>  terminal_output gfxterm
>  }
> }
>
> would create an "edit environment variable" toplevel with class set_gfxmode

Hi,

Thanks a lot for your advice, most of them looks good, although some
details may need adjustment.

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\\\" }\""
}

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

-- 
Bean

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

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

[Michal Suchanek]

2009/9/14 Bean <bean123ch@gmail.com>:
>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

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

[Bean]

On Mon, Sep 14, 2009 at 5:56 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/9/14 Bean <bean123ch@gmail.com>:
>>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/

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

[Michal Suchanek]

2009/9/14 Bean <bean123ch@gmail.com>:
> On Mon, Sep 14, 2009 at 5:56 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/9/14 Bean <bean123ch@gmail.com>:

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

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

[Bean]

On Tue, Sep 15, 2009 at 2:14 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/9/14 Bean <bean123ch@gmail.com>:
>> On Mon, Sep 14, 2009 at 5:56 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> 2009/9/14 Bean <bean123ch@gmail.com>:
>
>>>>
>>>> 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.

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

-- 
Bean

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

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

[Michal Suchanek]

2009/9/15 Bean <bean123ch@gmail.com>:
> On Tue, Sep 15, 2009 at 2:14 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/9/14 Bean <bean123ch@gmail.com>:
>>> On Mon, Sep 14, 2009 at 5:56 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> 2009/9/14 Bean <bean123ch@gmail.com>:
>>
>>>>>
>>>>> 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