[GITGRUB] New menu interface

[GITGRUB] New menu interface

[Bean]

Hi,

I am about to start a new branch on github for the new menu interface.
Here is the first draft of design.

The building block of menu interface is component. There are two basic
component, text and box, available both for text and graphics mode.
text is a single line of text, while box is a rectangle area with
background color, and may also have a background image. Complex
components build on other components. For example, a menu component
consist of window frame and menu body, menu body consist of multiple
text, and the window frame consist of up to nine box (upper left,
upper center, upper right, left, center, right, lower left, lower
center, lower right).

The configure file uses {} syntax to represent a tree structure, it
may look like this:

+ style {
  + window {
    + menu {
      bgcolor = #ffffff
      transparency = 80
    }
  }
  + text {
    + default {
      font = "fixed"
    }
    + header {
      font = "courier"
    }
  }
  + box {
    + screen {
      bgimage = "splash.png"
    }
  }
}

+ screen {
  + text {
    class = "header"
    x = 10
    y = 10
    text = "Welcome"
  }
  + menu {
    x = 30
    y = 30
    width = 100
    height = 100
  }
}

The style tree specify the properties of component class. The first
level is component name, and the second level is class name. screen
tree specify screen layout. This example shows three component,
screen, text and menu. The text component is of class "header", so it
inherits property font="courier". Menu is a composite component, it
use window component to draw the border, which is of class "menu", so
it inherit the properties bgcolor=#ffffff and transparency=80.

-- 
Bean

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

Re: [GITGRUB] New menu interface

[Michal Suchanek]

Hello

2009/9/2 Bean <bean123ch@gmail.com>:
...
>  + box {
>    + screen {
>      bgimage = "splash.png"
>    }
>  }
> }

Where would this image get displayed? It's highly unlikely it would
have the same resolution as the screen box.

>
> + screen {
>  + text {
>    class = "header"
>    x = 10
>    y = 10
>    text = "Welcome"
>  }
>  + menu {
>    x = 30
>    y = 30
>    width = 100
>    height = 100
>  }
> }

With this kind of placement (x, y) how do you get
 - a menu with fixed number of components that scales to make best use
of available screen space
 - a scrollable menu with fixed font size that accomodates as many
items on the screen as reasonably possible (within some layout
constraints such as text/menu borders)

In my view the typical requirements are
 - margins and borders to separate elements
 - alignment like left, right, center, decimal (could be probably used
for version as well)
 - relative alignment like below, right-of, .. or packing like
three-column, 2-span, etc.

Specifying pixel coordinates for each item separately is
counter-productive and typically not what you want.

Thanks

Michal

Re: [GITGRUB] New menu interface

[Bean]

On Wed, Sep 2, 2009 at 7:07 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
> Hello
>
> 2009/9/2 Bean <bean123ch@gmail.com>:
> ...
>>  + box {
>>    + screen {
>>      bgimage = "splash.png"
>>    }
>>  }
>> }
>
> Where would this image get displayed? It's highly unlikely it would
> have the same resolution as the screen box.

We have image scaling support (Colin's pending patch),  so the image
will fit screen automatically. if it's required,  we could also add
another option to use tiling instead of scaling.

>
>>
>> + screen {
>>  + text {
>>    class = "header"
>>    x = 10
>>    y = 10
>>    text = "Welcome"
>>  }
>>  + menu {
>>    x = 30
>>    y = 30
>>    width = 100
>>    height = 100
>>  }
>> }
>
> With this kind of placement (x, y) how do you get
>  - a menu with fixed number of components that scales to make best use
> of available screen space
>  - a scrollable menu with fixed font size that accomodates as many
> items on the screen as reasonably possible (within some layout
> constraints such as text/menu borders)
>
> In my view the typical requirements are
>  - margins and borders to separate elements
>  - alignment like left, right, center, decimal (could be probably used
> for version as well)
>  - relative alignment like below, right-of, .. or packing like
> three-column, 2-span, etc.
>
> Specifying pixel coordinates for each item separately is
> counter-productive and typically not what you want.

This feature looks good, but I think it'd be too complicated for the
initial version. IMO, we should have a working solution first, then
improve on it. To support screen relative position, we could use
something like this:

+ menu {
    x = 10%
    y = 10%
    width = 30%
    height = 30%
  }

The percentage are calculated using the width/height of parent component.

Later, we can add layout manager that calculate the position of
individual component.

-- 
Bean

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

Re: [GITGRUB] New menu interface

[Michal Suchanek]

2009/9/2 Bean <bean123ch@gmail.com>:
> On Wed, Sep 2, 2009 at 7:07 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
>> Hello
>>
>> 2009/9/2 Bean <bean123ch@gmail.com>:
>> ...
>>>  + box {
>>>    + screen {
>>>      bgimage = "splash.png"
>>>    }
>>>  }
>>> }
>>
>> Where would this image get displayed? It's highly unlikely it would
>> have the same resolution as the screen box.
>
> We have image scaling support (Colin's pending patch),  so the image
> will fit screen automatically. if it's required,  we could also add
> another option to use tiling instead of scaling.

How will it fit screen? What if the image is 4:3 and  the screen is
5:4 or widescreen?

>
>>
>>>
>>> + screen {
>>>  + text {
>>>    class = "header"
>>>    x = 10
>>>    y = 10
>>>    text = "Welcome"
>>>  }
>>>  + menu {
>>>    x = 30
>>>    y = 30
>>>    width = 100
>>>    height = 100
>>>  }
>>> }
>>
>> With this kind of placement (x, y) how do you get
>>  - a menu with fixed number of components that scales to make best use
>> of available screen space
>>  - a scrollable menu with fixed font size that accomodates as many
>> items on the screen as reasonably possible (within some layout
>> constraints such as text/menu borders)
>>
>> In my view the typical requirements are
>>  - margins and borders to separate elements
>>  - alignment like left, right, center, decimal (could be probably used
>> for version as well)
>>  - relative alignment like below, right-of, .. or packing like
>> three-column, 2-span, etc.
>>
>> Specifying pixel coordinates for each item separately is
>> counter-productive and typically not what you want.
>
> This feature looks good, but I think it'd be too complicated for the
> initial version. IMO, we should have a working solution first, then

IMHO we have a working solution now: gfxterm, and it's time to specify
what the next version is supposed to do and what is not required for
grub. Then it will be obvious where we can cut corners to make the
menu sufficient but not overly complex.

> improve on it. To support screen relative position, we could use
> something like this:
>
> + menu {
>    x = 10%
>    y = 10%
>    width = 30%
>    height = 30%
>  }
>
> The percentage are calculated using the width/height of parent component.
>
> Later, we can add layout manager that calculate the position of
> individual component.

Percentages are a good start. However, if you make your menu
percentage based adding new items or new menu areas is still
problematic.

Thanks

Michal

Re: [GITGRUB] New menu interface

[Bean]

On Wed, Sep 2, 2009 at 11:27 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
> How will it fit screen? What if the image is 4:3 and  the screen is
> 5:4 or widescreen?

It'd scale to fit the new proportion, although the image perhaps won't
look nice in this case. We could choose one of the following rendering
method based on option:

Center
Scaling (full)
Scaling (keep ratio)
Tiling

> Percentages are a good start. However, if you make your menu
> percentage based adding new items or new menu areas is still
> problematic.

Actually I've though of another representation, using the font metrics
as base unit,  something like this:

+ menu {
  x = 10%
  y = 10%
  width = 30c
  height = 30c
}


-- 
Bean

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

Re: [GITGRUB] New menu interface

[Michal Suchanek]

2009/9/2 Bean <bean123ch@gmail.com>:
> On Wed, Sep 2, 2009 at 11:27 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
>> How will it fit screen? What if the image is 4:3 and  the screen is
>> 5:4 or widescreen?
>
> It'd scale to fit the new proportion, although the image perhaps won't
> look nice in this case. We could choose one of the following rendering
> method based on option:
>
> Center
> Scaling (full)
> Scaling (keep ratio)
> Tiling

Other common uses are

Scaling (cover) - keep aspect but cover the whole area (with parts of
the picture sticking out of the viewport) - useful with a
non-intrusive background like a photo of fallen leaves or the like

Left, Right, TopLeft, BottomRight, ... - for side and corner decorations.

>
>> Percentages are a good start. However, if you make your menu
>> percentage based adding new items or new menu areas is still
>> problematic.
>
> Actually I've though of another representation, using the font metrics
> as base unit,  something like this:
>
> + menu {
>  x = 10%
>  y = 10%
>  width = 30c
>  height = 30c
> }

Does that c represent the width of the character "c"? What about
proportional fonts?

I think it is OK if the layout manager was in Lua if that makes
hacking on it easier but you still need the support functions for a
fully functional layout manager in C for that to work.

Thanks

Michal

Re: [GITGRUB] New menu interface

[Bean]

On Thu, Sep 3, 2009 at 1:25 AM, Michal Suchanek<hramrach@centrum.cz> wrote:
> 2009/9/2 Bean <bean123ch@gmail.com>:
>> On Wed, Sep 2, 2009 at 11:27 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
>>> How will it fit screen? What if the image is 4:3 and  the screen is
>>> 5:4 or widescreen?
>>
>> It'd scale to fit the new proportion, although the image perhaps won't
>> look nice in this case. We could choose one of the following rendering
>> method based on option:
>>
>> Center
>> Scaling (full)
>> Scaling (keep ratio)
>> Tiling
>
> Other common uses are
>
> Scaling (cover) - keep aspect but cover the whole area (with parts of
> the picture sticking out of the viewport) - useful with a
> non-intrusive background like a photo of fallen leaves or the like
>
> Left, Right, TopLeft, BottomRight, ... - for side and corner decorations.

Hi,

Sounds good, and it shouldn't be difficult to implement.

>
>>
>>> Percentages are a good start. However, if you make your menu
>>> percentage based adding new items or new menu areas is still
>>> problematic.
>>
>> Actually I've though of another representation, using the font metrics
>> as base unit,  something like this:
>>
>> + menu {
>>  x = 10%
>>  y = 10%
>>  width = 30c
>>  height = 30c
>> }
>
> Does that c represent the width of the character "c"? What about
> proportional fonts?

The suffix c means character. For proportional fonts, it's the average
width of font used by the current component.

>
> I think it is OK if the layout manager was in Lua if that makes
> hacking on it easier but you still need the support functions for a
> fully functional layout manager in C for that to work.

Yeah, I think it'd be better to implement to whole framework in C at
first. LUA could be used to write custom component that extends the
function of existing components.

-- 
Bean

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

Re: [GITGRUB] New menu interface

[Michal Suchanek]

2009/9/2 Bean <bean123ch@gmail.com>:
> On Thu, Sep 3, 2009 at 1:25 AM, Michal Suchanek<hramrach@centrum.cz> wrote:
>> 2009/9/2 Bean <bean123ch@gmail.com>:
>>> On Wed, Sep 2, 2009 at 11:27 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
>>>> How will it fit screen? What if the image is 4:3 and  the screen is
>>>> 5:4 or widescreen?
>>>
>>> It'd scale to fit the new proportion, although the image perhaps won't
>>> look nice in this case. We could choose one of the following rendering
>>> method based on option:
>>>
>>> Center
>>> Scaling (full)
>>> Scaling (keep ratio)
>>> Tiling
>>
>> Other common uses are
>>
>> Scaling (cover) - keep aspect but cover the whole area (with parts of
>> the picture sticking out of the viewport) - useful with a
>> non-intrusive background like a photo of fallen leaves or the like
>>
>> Left, Right, TopLeft, BottomRight, ... - for side and corner decorations.
>
> Hi,
>
> Sounds good, and it shouldn't be difficult to implement.
>
>>
>>>
>>>> Percentages are a good start. However, if you make your menu
>>>> percentage based adding new items or new menu areas is still
>>>> problematic.
>>>
>>> Actually I've though of another representation, using the font metrics
>>> as base unit,  something like this:
>>>
>>> + menu {
>>>  x = 10%
>>>  y = 10%
>>>  width = 30c
>>>  height = 30c
>>> }
>>
>> Does that c represent the width of the character "c"? What about
>> proportional fonts?
>
> The suffix c means character. For proportional fonts, it's the average
> width of font used by the current component.

Still why would you want an object about 30 characters wide? You
either want an object that can accommodate its content or an object
that fills available space. An object "about 30 characters wide" is
useless in my view.

If it's height you can be sure you can put 30 menu items in there then
(but then it would be in some units on fount height not width)

>
>>
>> I think it is OK if the layout manager was in Lua if that makes
>> hacking on it easier but you still need the support functions for a
>> fully functional layout manager in C for that to work.
>
> Yeah, I think it'd be better to implement to whole framework in C at
> first. LUA could be used to write custom component that extends the
> function of existing components.
>

Actually the code in video subsystem that is required for writing a
layout manager is already there or easy to add.

- get_viewport - get available area
- set_viewport - limit drawing to selected component
- get_text_width
- get_font_height - find out the size of a rectangle needed to draw a
specific string

What is needed is parser for some configuration format that can store
arbitrary attributes which can then be interpreted by the layout
manager.

Thanks

Michal

Re: [GITGRUB] New menu interface

[Bean]

On Thu, Sep 3, 2009 at 3:43 AM, Michal Suchanek<hramrach@centrum.cz> wrote:
> 2009/9/2 Bean <bean123ch@gmail.com>:
>> On Thu, Sep 3, 2009 at 1:25 AM, Michal Suchanek<hramrach@centrum.cz> wrote:
>>> 2009/9/2 Bean <bean123ch@gmail.com>:
>>>> On Wed, Sep 2, 2009 at 11:27 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
>>>>> How will it fit screen? What if the image is 4:3 and  the screen is
>>>>> 5:4 or widescreen?
>>>>
>>>> It'd scale to fit the new proportion, although the image perhaps won't
>>>> look nice in this case. We could choose one of the following rendering
>>>> method based on option:
>>>>
>>>> Center
>>>> Scaling (full)
>>>> Scaling (keep ratio)
>>>> Tiling
>>>
>>> Other common uses are
>>>
>>> Scaling (cover) - keep aspect but cover the whole area (with parts of
>>> the picture sticking out of the viewport) - useful with a
>>> non-intrusive background like a photo of fallen leaves or the like
>>>
>>> Left, Right, TopLeft, BottomRight, ... - for side and corner decorations.
>>
>> Hi,
>>
>> Sounds good, and it shouldn't be difficult to implement.
>>
>>>
>>>>
>>>>> Percentages are a good start. However, if you make your menu
>>>>> percentage based adding new items or new menu areas is still
>>>>> problematic.
>>>>
>>>> Actually I've though of another representation, using the font metrics
>>>> as base unit,  something like this:
>>>>
>>>> + menu {
>>>>  x = 10%
>>>>  y = 10%
>>>>  width = 30c
>>>>  height = 30c
>>>> }
>>>
>>> Does that c represent the width of the character "c"? What about
>>> proportional fonts?
>>
>> The suffix c means character. For proportional fonts, it's the average
>> width of font used by the current component.
>
> Still why would you want an object about 30 characters wide? You
> either want an object that can accommodate its content or an object
> that fills available space. An object "about 30 characters wide" is
> useless in my view.

Hi,

For example, we might want to limit the width of edit box to display
at most 30 characters, in this case 30c is quite useful.

And the c unit is usable in both text and graphic mode. If we write
y=2c, y is 2 character height, this looks acceptable in both text and
graphics mode, but y=2 is extremely narrow in graphic mode. In fact, c
is the unit used in the current gfxterm.

> If it's height you can be sure you can put 30 menu items in there then
> (but then it would be in some units on fount height not width)

For y and height property, c is calculated using font height instead of width.

>
>>
>>>
>>> I think it is OK if the layout manager was in Lua if that makes
>>> hacking on it easier but you still need the support functions for a
>>> fully functional layout manager in C for that to work.
>>
>> Yeah, I think it'd be better to implement to whole framework in C at
>> first. LUA could be used to write custom component that extends the
>> function of existing components.
>>
>
> Actually the code in video subsystem that is required for writing a
> layout manager is already there or easy to add.
>
> - get_viewport - get available area
> - set_viewport - limit drawing to selected component
> - get_text_width
> - get_font_height - find out the size of a rectangle needed to draw a
> specific string
>
> What is needed is parser for some configuration format that can store
> arbitrary attributes which can then be interpreted by the layout
> manager.

We can select the layout manager using layout property. Although for
simple interface, I don't think layout manager is necessary, as there
won't be too many components on screen.

-- 
Bean

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

Re: [GITGRUB] New menu interface

[Michal Suchanek]

2009/9/3 Bean <bean123ch@gmail.com>:
> On Thu, Sep 3, 2009 at 3:43 AM, Michal Suchanek<hramrach@centrum.cz> wrote:
>> 2009/9/2 Bean <bean123ch@gmail.com>:
>>> On Thu, Sep 3, 2009 at 1:25 AM, Michal Suchanek<hramrach@centrum.cz> wrote:
>>>> 2009/9/2 Bean <bean123ch@gmail.com>:
>>>>> On Wed, Sep 2, 2009 at 11:27 PM, Michal Suchanek<hramrach@centrum.cz> wrote:
>>>>>> How will it fit screen? What if the image is 4:3 and  the screen is
>>>>>> 5:4 or widescreen?
>>>>>
>>>>> It'd scale to fit the new proportion, although the image perhaps won't
>>>>> look nice in this case. We could choose one of the following rendering
>>>>> method based on option:
>>>>>
>>>>> Center
>>>>> Scaling (full)
>>>>> Scaling (keep ratio)
>>>>> Tiling
>>>>
>>>> Other common uses are
>>>>
>>>> Scaling (cover) - keep aspect but cover the whole area (with parts of
>>>> the picture sticking out of the viewport) - useful with a
>>>> non-intrusive background like a photo of fallen leaves or the like
>>>>
>>>> Left, Right, TopLeft, BottomRight, ... - for side and corner decorations.
>>>
>>> Hi,
>>>
>>> Sounds good, and it shouldn't be difficult to implement.
>>>
>>>>
>>>>>
>>>>>> Percentages are a good start. However, if you make your menu
>>>>>> percentage based adding new items or new menu areas is still
>>>>>> problematic.
>>>>>
>>>>> Actually I've though of another representation, using the font metrics
>>>>> as base unit,  something like this:
>>>>>
>>>>> + menu {
>>>>>  x = 10%
>>>>>  y = 10%
>>>>>  width = 30c
>>>>>  height = 30c
>>>>> }
>>>>
>>>> Does that c represent the width of the character "c"? What about
>>>> proportional fonts?
>>>
>>> The suffix c means character. For proportional fonts, it's the average
>>> width of font used by the current component.
>>
>> Still why would you want an object about 30 characters wide? You
>> either want an object that can accommodate its content or an object
>> that fills available space. An object "about 30 characters wide" is
>> useless in my view.
>
> Hi,
>
> For example, we might want to limit the width of edit box to display
> at most 30 characters, in this case 30c is quite useful.
>
> And the c unit is usable in both text and graphic mode. If we write
> y=2c, y is 2 character height, this looks acceptable in both text and
> graphics mode, but y=2 is extremely narrow in graphic mode. In fact, c
> is the unit used in the current gfxterm.
>
>> If it's height you can be sure you can put 30 menu items in there then
>> (but then it would be in some units on fount height not width)
>
> For y and height property, c is calculated using font height instead of width.
>
>>
>>>
>>>>
>>>> I think it is OK if the layout manager was in Lua if that makes
>>>> hacking on it easier but you still need the support functions for a
>>>> fully functional layout manager in C for that to work.
>>>
>>> Yeah, I think it'd be better to implement to whole framework in C at
>>> first. LUA could be used to write custom component that extends the
>>> function of existing components.
>>>
>>
>> Actually the code in video subsystem that is required for writing a
>> layout manager is already there or easy to add.
>>
>> - get_viewport - get available area
>> - set_viewport - limit drawing to selected component
>> - get_text_width
>> - get_font_height - find out the size of a rectangle needed to draw a
>> specific string
>>
>> What is needed is parser for some configuration format that can store
>> arbitrary attributes which can then be interpreted by the layout
>> manager.
>
> We can select the layout manager using layout property. Although for
> simple interface, I don't think layout manager is necessary, as there
> won't be too many components on screen.

And how would you place the menu items then? At random?

Thanks

Michal

Re: [GITGRUB] New menu interface

[Bean]

On Thu, Sep 3, 2009 at 4:41 PM, Michal
> And how would you place the menu items then? At random?

Hi,

First we can implement the classic menu, which is basically multi-line
text box, one item per line. Later we could add more style, perhaps by
inserting a panel component that control the layout. For example, we
can have iconic mode that each item is represented by an icon.

-- 
Bean

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

Re: [GITGRUB] New menu interface

[Michal Suchanek]

2009/9/3 Bean <bean123ch@gmail.com>:
> On Thu, Sep 3, 2009 at 4:41 PM, Michal
>> And how would you place the menu items then? At random?
>
> Hi,
>
> First we can implement the classic menu, which is basically multi-line
> text box, one item per line. Later we could add more style, perhaps by
> inserting a panel component that control the layout. For example, we
> can have iconic mode that each item is represented by an icon.
>

I guess this can be generalized into two components:

 - label - can have a background image, icon, text
    - can be active (= have an associated list of commands) or not
 - split - can contain one(?) two or more items (splits, labels)
sorted vertically or horizontally
    - should give focus to the first child that contains an active item
    - should allow flexible sizing and styling of the cells (borders,
margins, padding, minimum size, upscaling, ...)
    - should allow a variant that scrolls in the direction in which
the cells are sorted (with paging or slower scrolling, possibility to
loop from end to start)

Thanks

Michal