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

[Michal Suchanek]

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.

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