Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/24 Bean <address@hidden>:
> On Thu, Sep 24, 2009 at 5:40 PM, Michal Suchanek <address@hidden> wrote:
>>>>
>>>> There is also a background glitch in graphics mode. In text mode the
>>>> background of the menu items is cyan but it is blue in graphics.
>>>
>>> It's actually the background image back.png, if you want to use color
>>> rect, change
>>>
>>> background = "/menu/back.png,,#808080/cyan"
>>>
>>> to
>>>
>>> background = ",#808080/cyan"
>>
>> It's background of the menu panel, the items still do have cyan
>> background so that should apply (and should make the text visible).
>
> Hi,
>
> Oh, background color is ignored in graphic mode text, as it can ruin
> the background image.

Isn't that what transparent background is for?


>
>>
>>>
>>>
>>>>
>>>> 2009/9/23 Bean <address@hidden>:
>>>>> Hi,
>>>>>
>>>>> Update:
>>>>> Add label widget
>>>>> Simple layout manager for panel widget.
>>>>>
>>>>> The resource file for new demo is uploaded at:
>>>>> http://grub4dos.sourceforge.net/menu.zip
>>>>>
>>>>> Here is the theme file for new demo:
>>>>>
>>>>> screen
>>>>> {
>>>>
>>>> This is an odd element. Can't this be another panel or just background
>>>> form the toplevel panel?
>>>>
>>>> It may be easier this way initially but getting the layout of the
>>>> inner pane right without a special element means that the layout is
>>>> actually usable at all levels.
>>>>
>>>> Also requiring a screen element makes it harder to just take a menu
>>>> and pack it inside another menu.
>>>
>>> The config file can store other information besides screen layout, for
>>> example styles. I use the screen node to locate the top widget.
>>
>> That should not be necessary. Either a particular panel is installed
>> as the top window explicitly (and this should be possible because
>> later it should be possible to replace it with another panel) or one
>> is selected based on some implicit rule.
>
> screen is special case as width/height need to be set to the size of
> screen, but panel doesn't have initial size. We can always add a panel

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?

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

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


>>>
>>>
>>> screen {
>>> ámenu {
>>> á ástart = "sub_menu/bb"
>>> á}
>>> }
>>>
>>> menu {
>>> áitem {
>>> á átitle = "aa"
>>> á ácommand = á..
>>> á}
>>> ámenu {
>>> á átitle = "sub_menu"
>>> á áitem {
>>> á á átitle = "bb"
>>> á á ácommand = á..
>>> á á}
>>> á áitem {
>>> á á átitle = "cc"
>>> á á ácommand = á..
>>> á á}
>>> á}
>>> }
>>>
>>> Then we can use <enter> and <escape> to walk the menu tree. menu
>>> widget would generate the corresponding label based on the current
>>> menu level.

You should be able to use enter and escape with 'popups' as well with
the added benefit that no special component is needed.

>>>
>>>>
>>>>> ßpanel
>>>>> ß{
>>>>> ß ßx = "5"
>>>>> ß ßy = "5"
>>>>
>>>> What is x and y? Isn't there a more descriptive name for this property?
>>>>
>>>> Why does a panel even need x and y?
>>>
>>> x, y is the top left coordination of the widget. x,y,width,height is
>>> used to defined the position of widget, although for label, it can be
>>> omit as panel can calculate it for them.
>>>
>>
>> This is not what layout should be about. Internally the position and
>> size of the element should be known but people are usually concerned
>> about the element being in the center of the screen, offset at least
>> some amount from each edge, etc.
>
> But sometimes we do need to set location manually. For example we may
> need to adjust the location of menu corresponds to the background
> image. IMO, layout manager is best used for widgets like label where
> location is not easy to calculate.

Location is almost never easy to calculate.
Further x,y,width,height are the low level measures that the drawing
code needs to know but they are almost always the wrong measures for
expressing the location.

If your background background has specific resolution and you measure
the offset and size of the terminal area you can equally well measure
the four magrins - top, left, bottom, right. You have to measure four
values either way.

However, if you want to leave some space around a panel then it cannot
be easily expressed as x,y, width and height. The panel may be drawn
on screens of different size, or it may be included in another panel.
The width changes but the border is the same in all cases. The
situation is similar when you want the panel centered.

I would encourage to use these properties that make combining elements
easier over the low-level width and height properties.

>
> And we can also use this feature to divide the screen into different
> blocks, like:
>
> panel
> {
>  panel
>  {
>    x = 0
>    y = 0
>    width = 100%
>    height = 30%
>  }
>  panel
>  {
>    x = 0
>    y = 30%
>    width = 100%
>    height = 30%
>  }
>  panel
>  {
>    x = 0
>    y = 60%
>    width = 100%
>    height = 40%
>  }
> }
>

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.

Thanks

Michal