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

[Bean]

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