Re: [GITGRUB] New menu interface (implementation)

[Bean <bean123ch@gmail.com>]

On Fri, Sep 25, 2009 at 6:00 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> Certainly an element that does not have any parent is special.
> Inventing a new element only for the purpose of not having a parent
> seems over the board, though.
>
> There is certainly some check necessary for this situation but there
> is no need to force the user to implement the check in the
> configuration. What if the screen element is omitted and a panel or
> label is created without any enclosing screen? Would it fail in some
> way ? Crash even?

Hi,

Actually the config file format is designed to work with things other
than graphic menu. Tree structure is quite common and can be used by
other modules. Currently the loading is separated into two steps,
first loadcfg /menu/theme.txt to load the config tree, and menutest
search the config tree for a screen root node and interpret its
children as widgets. If there are more than one screen node, the
content is merged together.

Another example for possible usage of tree structure is pxe config, we
can load different config file based on current ip/mac address. So a
config file may look like this:

screen
{
  panel {}
  panel {}
}

pxe
{
  config = "a1.cfg"
  192.168.2
  {
    config = "a2.cfg"
    10 { config = "a3.cfg" }
    20 { config = "a4.cfg" }
  }
}

graphic menu only uses the screen tree, it won't conflict with pxe module.

This is somewhat similar to the structure of xorg.conf. It has many
sections like "Files", "InputDevice", "Device", "Screen". Different
module would inspect the sections it needs to find config information.

>
>> to cover the screen:
>>
>> screen
>> {
>>  panel
>>  {
>>    x = 0
>>    y = 0
>>    width = 100%
>>    height = 100%
>>  }
>> }
>>
>>>
>>>>
>>>> As for menu, it's better to move it to a different tree, and reference
>>>> it in the menu widget, perhaps something like this:
>>>
>>> What is a menu widget, and how does it relate to the other menu widget(s)?
>>>
>>> I do not see the connection.
>>>
>>> I also do not see why the panel cannot be specified completely at the
>>> very start.
>>>
>>> If need be it could be done like
>>>
>>> panel top_menu{
>>> }
>>>
>>> # add to the panel
>>> panel top_menu{
>>> #these don't have a name
>>> álabel {
>>> átext = Ubuntu Linux
>>> áIcon = ubuntu.png
>>> }}
>>>
>>> panel top_menu{
>>> álabel {
>>> átext = Debian GNU/Linux
>>> áicon = debian.png
>>> }}
>>>
>>> show top_menu
>>>
>>> Adding to an already created object should be possible
>>> programatically, and it is possible even in configuration. However,
>>> this method is quite error-prone in case you mistype the element name.
>>>
>>> Defining the element tree all at once either succeeds or fails visibly.
>>>
>>
>> Consider submenu, for example, in the first level, it shows three
>> label aa, bb, cc, after clicking aa, it change to label dd, ee,ff. In
>> this case, label can be set directly in panel, otherwise we need
>> complex mechanism to add/remove them on the air.
>>
>> menu is a special widget that handles these for us. It reads the menu
>> from another place and generate the labels inside a panel.
>>
>
> I don't see submenus as a vital part of the system.
>
> If you start with submenus you have to solve the problem of opening a
> submenu so that it fits on the screen and does not obscure the item
> with which you activated it so that you know what you are doing. All
> desktops I have seen so far fail miserably at this task and sometimes
> manage to get around their failure with mouse navigation, sometimes
> not.

We can use in-place replacement, the sub menu would occupied space of
original menu, This would avoid popups.

>
> A very good replacement for submenu is the option to make another
> panel the toplevel panel.
> This mechanism can be used for other tasks as well (ie messages, help
> texts). The same mechanisms that works for message should work for
> submenu.
>
> If you want something more cool consider
>
> panel main {
>  direction = horizontal
>  panel distro_choice {
>  direction =vertical
>  label {
>   text = Debian GNU/Linux
>   action {
>    # a simple general command is needed to manipulate the component tree
>    parent[2] = debian
>   }
>  }
>  label {
>   text = Gentoo Linux
>   action {
>    parent[2] = gentoo
>   }
>  }
>  }
>  panel debian {}
> }
>
> panel debian {
>  direction = vertical
>  label {
>  text = Debian GNU/Linux kernel version 2.6.30
>  action {
>   ...
>
> panel gentoo
>  direction = vertical
>  label {
>   text = Gentoo Linux kernel version 2.6.31
>  ...

Actually I'd prefer to separate model and view. We can uses two config
sections, menu section define the menu content, and a menu widget
loads them and display the labels, something like this:

# screen section
screen
{
  panel
  {
    menu {}
  }
}

# menu section
menu
{
  "Boot Windows"
  {
    class = windows
    command = "chainload +1\nboot"
  }
  "Tools"
  {
    "Shutdown"
    {
      class = tool
      command = "halt"
    }
    "Reboot"
     {
       class = tool
       command = "reboot"
     }
  }
}

The theme file is provided system wide, but users have to fill in the
menu content, it's better to keep it as simple as possible, also the
structure of menu is not depended on the gui system, we can change the
widget interface without requires users to change the menu section.

>
> You should not need to specify anything in this case. The space should
> be divided by the toplevel panel, and you may possibly tune one or two
> values.
>
> panel {
>  direction = vertical
>  panel {}
>  panel ()
>  panel {}
> }
>
> should suffice to divide the screen in thirds.
>
> They would probably not be exact thirds, if one of the panels has more
> content it should get more space but that's usually what you want.

I'm currently working on a new layout manager uses the following
properties to control the position of children widgets:

max_columns - maximum number of widgets per row (default 1)
hspace - minimum horizontal space between widgets
vspace - minimum vertical space between widgets
halign - horizontal alignment, can be left, center and right
valign - vertical alignment, can be top, center and bottom

-- 
Bean

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