Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/25 Bean <address@hidden>:
> On Fri, Sep 25, 2009 at 6:00 AM, Michal Suchanek <address@hidden> 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.

That's also a possibility. It allows displaying arbitrarily nested
menus without switching the layout.
I'm not sure this is a good thing. I would prefer if people who want
to have submenus designed them as separate screens with their own
layout. This should allow easy integration of whole a menu from a
different system and it should help with displaying submenus with huge
amount of choices like "select language" submenu.

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

There are a few problems here.

Firstly the menu is separated in model and view but the rest of the
components are not. If the rest does contain something important (like
a hotkey that pops up a panel with a help text) you have to repeat
that in each view that contains the menu. Partial separation makes the
system more confusing in my view.

Second if the separation leads to users creating many levels of
submenus then I would say it does not help usability of the system.

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

Normally the users don't fill the menu either. It's generated by the
grub.d scripts.

The structure of the menu itself is not dependent on the layout in either case.
The (sub)menu is just a list of labels, the surrounding elements can
be generated as header and footer by the script.

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

If I understand it correctly this means that a panel is a bunch of
cells which are laid out horizontally and at some random point (but at
most after max_columns cells) a row break is inserted and the later
cells start in a new row.

I would prefer a more deterministic approach: the panel is either one
column or one row (vertical or horizontal).
This should cover the common cases, real tables are seldom needed.


> hspace - minimum horizontal space between widgets
> vspace - minimum vertical space between widgets

Then this is the space between widgets, and only one is needed.

> halign - horizontal alignment, can be left, center and right
> valign - vertical alignment, can be top, center and bottom
>

Thanks

Michal