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

[Michal Suchanek]

hello

2009/9/9 Bean <address@hidden>:
> On Wed, Sep 9, 2009 at 6:53 PM, Michal Suchanek<address@hidden> wrote:
>> 2009/9/8 Bean <address@hidden>:
>>> 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 <address@hidden>:
> On Wed, Sep 9, 2009 at 10:50 PM, Michal Suchanek<address@hidden> wrote:
>> 2009/9/8 Bean <address@hidden>:
>>> 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