[GITGRUB] New menu interface (implementation)

[GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Now that the basic architecture has been decided, I start to work on
the actual coding. The code will be pushed to the menu branch of my
gitbub: repo: http://github.com/bean123/grub/.

First version is done, this implements the low level region API, no
component yet, but you can construct the ui manually, I've added a
menutest command to run some test. It can be started in grub.cfg like
this (should be run in console mode);

set gfxmode="640x480"
loadfont /unifont.pf2
ismod vbe
insmod png
menutest

It runs four tests, it would pause after each test, press any key to continue.

1, It starts with text mode with three rects, the second rect have 3
texts, but the last one is outside the view port and therefore not
visible.
2. It moves the second rect to the top and change the view port, now
the third text is visible but the first is hidden.

3-4 rerun the following test in graphic mode. If /r1.png, /r2.png, or
/r3.png exists, the image will replace the corresponding rect box.

BTW, I've disabled double buffer temperately for testing purpose. The
new algorithm ensures that only the necessary region would be updated,
the screen shouldn't blink even without double buffer support.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Merge grub_menu_region_create_rect into
grub_menu_region_create_bitmap, it first tries to load the bitmap, if
it fails, fallback to rect. To create pure rect, just set the filename
to NULL.

Adjust video fb function, exports grub_video_fbfill and
grub_video_fbblit as they're useful for bitmap to bitmap blit.

Extends bitmap scaling support, here is some sample code from menu_test.c:

r3 = grub_menu_region_create_bitmap (w, h, "/r3.png",
				       GRUB_VIDEO_BITMAP_SCALE_TYPE_TILING,
				       get_color ("red", 1), ' ');

It supports the following scaling type:

GRUB_VIDEO_BITMAP_SCALE_TYPE_NORMAL
Scale image to dest size

GRUB_VIDEO_BITMAP_SCALE_TYPE_CENTER
No scaling, draw the image at the center of dest. could leave blanks
or truncate the image.

GRUB_VIDEO_BITMAP_SCALE_TYPE_TILING
No scaling, fill the whole dest area with tiling.

GRUB_VIDEO_BITMAP_SCALE_TYPE_MINFIT
Keep ratio scaling, it ensures the whole image is displayed (could
leave blanks at the margin)

GRUB_VIDEO_BITMAP_SCALE_TYPE_MAXFIT
Keep ratio scaling, no blanks at the margin, but the image could be truncated.

It can optionally OR with a constant that indicate the scaling
algorithm, values are:


GRUB_VIDEO_BITMAP_SCALE_METHOD_FASTEST (default)
GRUB_VIDEO_BITMAP_SCALE_METHOD_BEST
GRUB_VIDEO_BITMAP_SCALE_METHOD_NEAREST
GRUB_VIDEO_BITMAP_SCALE_METHOD_BILINEAR	

---
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

Hello

2009/9/16 Bean <bean123ch@gmail.com>:

> set gfxmode="640x480"
> loadfont /unifont.pf2
> ismod vbe
> insmod png
> menutest
>
> It runs four tests, it would pause after each test, press any key to continue.
>
> 1, It starts with text mode with three rects, the second rect have 3
> texts, but the last one is outside the view port and therefore not
> visible.
> 2. It moves the second rect to the top and change the view port, now
> the third text is visible but the first is hidden.
>
> 3-4 rerun the following test in graphic mode. If /r1.png, /r2.png, or
> /r3.png exists, the image will replace the corresponding rect box.
>

Is it possible to change the demo so that the second rectangle does
not get to top?

To me it is not obvious where it is raised.

If it is not possible it's fine with me, I do not think that
overlapping elements have to be supported but if they are not the demo
should look different, right?

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

Hello

why does the menu system have a glyph drawing function?

Is the one in font.c not suitable?

Why are there two methods for returning text width and height, one in
gfx_region in pixels, the other in text_region in characters? Does
size in characters make any sense? There might be proportional fonts
or at least fonts of different size in the future.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[richardvoigt]

On Sat, Sep 19, 2009 at 1:45 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> Hello
>
> why does the menu system have a glyph drawing function?
>
> Is the one in font.c not suitable?
>
> Why are there two methods for returning text width and height, one in
> gfx_region in pixels, the other in text_region in characters? Does
> size in characters make any sense? There might be proportional fonts
> or at least fonts of different size in the future.

Pixels and proportional fonts are meaningless to a serial console.

>
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Sat, Sep 19, 2009 at 10:38 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> Hello
>
> 2009/9/16 Bean <bean123ch@gmail.com>:
>
>> set gfxmode="640x480"
>> loadfont /unifont.pf2
>> ismod vbe
>> insmod png
>> menutest
>>
>> It runs four tests, it would pause after each test, press any key to continue.
>>
>> 1, It starts with text mode with three rects, the second rect have 3
>> texts, but the last one is outside the view port and therefore not
>> visible.
>> 2. It moves the second rect to the top and change the view port, now
>> the third text is visible but the first is hidden.
>>
>> 3-4 rerun the following test in graphic mode. If /r1.png, /r2.png, or
>> /r3.png exists, the image will replace the corresponding rect box.
>>
>
> Is it possible to change the demo so that the second rectangle does
> not get to top?
>
> To me it is not obvious where it is raised.
>
> If it is not possible it's fine with me, I do not think that
> overlapping elements have to be supported but if they are not the demo
> should look different, right?

Hi,

The second rectangle is raised as we update it. Normally this is what
we want as the current selected item should be raised to top. If you
want to keep the third rect on top, just update it as well:

  grub_menu_region_update (&head, r2, 0, 0, r2->common.width,
r2->common.height);
  grub_menu_region_update (&head, r3, 0, 0, r3->common.width,
r3->common.height);
  grub_menu_region_apply_update (head);

> why does the menu system have a glyph drawing function?

> Is the one in font.c not suitable?

The one in font.c is not usable, as it draws the whole glyph, but in
the menu system, sometimes we only want to update a portion of it.

> Why are there two methods for returning text width and height, one in
> gfx_region in pixels, the other in text_region in characters? Does
> size in characters make any sense? There might be proportional fonts
> or at least fonts of different size in the future.

For example, we need to find out the length of string "HELLO" so that
we can align it to the center of screen. In graphic mode, this would
be the pixel width, but in text mode, it's the number of characters,
5.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/19 Bean <bean123ch@gmail.com>:
> On Sat, Sep 19, 2009 at 10:38 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> Hello
>>
>> 2009/9/16 Bean <bean123ch@gmail.com>:
>>
>>> set gfxmode="640x480"
>>> loadfont /unifont.pf2
>>> ismod vbe
>>> insmod png
>>> menutest
>>>
>>> It runs four tests, it would pause after each test, press any key to continue.
>>>
>>> 1, It starts with text mode with three rects, the second rect have 3
>>> texts, but the last one is outside the view port and therefore not
>>> visible.
>>> 2. It moves the second rect to the top and change the view port, now
>>> the third text is visible but the first is hidden.
>>>
>>> 3-4 rerun the following test in graphic mode. If /r1.png, /r2.png, or
>>> /r3.png exists, the image will replace the corresponding rect box.
>>>
>>
>> Is it possible to change the demo so that the second rectangle does
>> not get to top?
>>
>> To me it is not obvious where it is raised.
>>
>> If it is not possible it's fine with me, I do not think that
>> overlapping elements have to be supported but if they are not the demo
>> should look different, right?
>
> Hi,
>
> The second rectangle is raised as we update it. Normally this is what
> we want as the current selected item should be raised to top. If you
> want to keep the third rect on top, just update it as well:
>
>  grub_menu_region_update (&head, r2, 0, 0, r2->common.width,
> r2->common.height);
>  grub_menu_region_update (&head, r3, 0, 0, r3->common.width,
> r3->common.height);
>  grub_menu_region_apply_update (head);
>
>> why does the menu system have a glyph drawing function?
>
>> Is the one in font.c not suitable?
>
> The one in font.c is not usable, as it draws the whole glyph, but in
> the menu system, sometimes we only want to update a portion of it.

Couldn't you use viewport on the target for this?

This would be a problem if you allowed overlapping but since you do
not all regions are rectangular and setting up the viewport is easy.

>
>> Why are there two methods for returning text width and height, one in
>> gfx_region in pixels, the other in text_region in characters? Does
>> size in characters make any sense? There might be proportional fonts
>> or at least fonts of different size in the future.
>
> For example, we need to find out the length of string "HELLO" so that
> we can align it to the center of screen. In graphic mode, this would
> be the pixel width, but in text mode, it's the number of characters,
> 5.

So the text region is intended for drawing on text screen and the
graphics region on graphics screen. I assume the check for pure text
mode is there to choose which one is used.

However, wouldn't this switch in coordinate system complicate further
extending of the menu system with additional components? With these
different coordinates every compound component would likely have to
check which kind of rectangle is currently in use.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/19 Bean <bean123ch@gmail.com>:
> On Sat, Sep 19, 2009 at 10:38 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> Hello
>>
>> 2009/9/16 Bean <bean123ch@gmail.com>:
>>
>>> set gfxmode="640x480"
>>> loadfont /unifont.pf2
>>> ismod vbe
>>> insmod png
>>> menutest
>>>
>>> It runs four tests, it would pause after each test, press any key to continue.
>>>
>>> 1, It starts with text mode with three rects, the second rect have 3
>>> texts, but the last one is outside the view port and therefore not
>>> visible.
>>> 2. It moves the second rect to the top and change the view port, now
>>> the third text is visible but the first is hidden.
>>>
>>> 3-4 rerun the following test in graphic mode. If /r1.png, /r2.png, or
>>> /r3.png exists, the image will replace the corresponding rect box.
>>>
>>
>> Is it possible to change the demo so that the second rectangle does
>> not get to top?
>>
>> To me it is not obvious where it is raised.
>>
>> If it is not possible it's fine with me, I do not think that
>> overlapping elements have to be supported but if they are not the demo
>> should look different, right?
>
> Hi,
>
> The second rectangle is raised as we update it. Normally this is what
> we want as the current selected item should be raised to top. If you
> want to keep the third rect on top, just update it as well:
>
>  grub_menu_region_update (&head, r2, 0, 0, r2->common.width,
> r2->common.height);
>  grub_menu_region_update (&head, r3, 0, 0, r3->common.width,
> r3->common.height);
>  grub_menu_region_apply_update (head);
>
>> why does the menu system have a glyph drawing function?
>
>> Is the one in font.c not suitable?
>
> The one in font.c is not usable, as it draws the whole glyph, but in
> the menu system, sometimes we only want to update a portion of it.

Couldn't you use viewport on the target for this?

This would be a problem if you allowed overlapping but since you do
not all regions are rectangular and setting up the viewport is easy.

>
>> Why are there two methods for returning text width and height, one in
>> gfx_region in pixels, the other in text_region in characters? Does
>> size in characters make any sense? There might be proportional fonts
>> or at least fonts of different size in the future.
>
> For example, we need to find out the length of string "HELLO" so that
> we can align it to the center of screen. In graphic mode, this would
> be the pixel width, but in text mode, it's the number of characters,
> 5.

So the text region is intended for drawing on text screen and the
graphics region on graphics screen. I assume the check for pure text
mode is there to choose which one is used.

However, wouldn't this switch in coordinate system complicate further
extending of the menu system with additional components?

With these different coordinates every compound component would likely
have to check which kind of rectangle is currently in use.

Still it might work - borders have to be drawn differently, pictures
currently don't work, and alignment should work with any units (and
it's easier to see rounding errors if the units are large).

There is slight issue with element placement, though, If somebody uses
pixel coordinates for placing elements then the offsets will suddenly
become huge in text mode. Shouldn't the layouts be more portable?

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/19 richardvoigt@gmail.com <richardvoigt@gmail.com>:
> On Sat, Sep 19, 2009 at 1:45 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> Hello
>>
>> why does the menu system have a glyph drawing function?
>>
>> Is the one in font.c not suitable?
>>
>> Why are there two methods for returning text width and height, one in
>> gfx_region in pixels, the other in text_region in characters? Does
>> size in characters make any sense? There might be proportional fonts
>> or at least fonts of different size in the future.
>
> Pixels and proportional fonts are meaningless to a serial console.
>
So is element placement.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Sun, Sep 20, 2009 at 4:30 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>
> So the text region is intended for drawing on text screen and the
> graphics region on graphics screen. I assume the check for pure text
> mode is there to choose which one is used.
>
> However, wouldn't this switch in coordinate system complicate further
> extending of the menu system with additional components?
>
> With these different coordinates every compound component would likely
> have to check which kind of rectangle is currently in use.
>
> Still it might work - borders have to be drawn differently, pictures
> currently don't work, and alignment should work with any units (and
> it's easier to see rounding errors if the units are large).
>
> There is slight issue with element placement, though, If somebody uses
> pixel coordinates for placing elements then the offsets will suddenly
> become huge in text mode. Shouldn't the layouts be more portable?

Hi,

I'm thinking about using the "c" unit as default, as it's usable in
both text and graphic mode, this would help to create portable config
file. If user really want to use pixel unit, he can add "p" suffix,
such as 100p.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[richardvoigt]

On Sun, Sep 20, 2009 at 3:31 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/9/19 richardvoigt@gmail.com <richardvoigt@gmail.com>:
>> On Sat, Sep 19, 2009 at 1:45 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> Hello
>>>
>>> why does the menu system have a glyph drawing function?
>>>
>>> Is the one in font.c not suitable?
>>>
>>> Why are there two methods for returning text width and height, one in
>>> gfx_region in pixels, the other in text_region in characters? Does
>>> size in characters make any sense? There might be proportional fonts
>>> or at least fonts of different size in the future.
>>
>> Pixels and proportional fonts are meaningless to a serial console.
>>
> So is element placement.

I know of multiple systems that support multiple columns, status bar,
menu bar, popup dialogs, etc in text mode over a serial connection.
If those things are considered out of scope for a bootloader, I'd tend
to agree.  But people seem to be defining rich interfaces for grub and
to do so requires the ability to measure sizes in characters.

>
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/20 Bean <bean123ch@gmail.com>:
> On Sun, Sep 20, 2009 at 4:30 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>
>> So the text region is intended for drawing on text screen and the
>> graphics region on graphics screen. I assume the check for pure text
>> mode is there to choose which one is used.
>>
>> However, wouldn't this switch in coordinate system complicate further
>> extending of the menu system with additional components?
>>
>> With these different coordinates every compound component would likely
>> have to check which kind of rectangle is currently in use.
>>
>> Still it might work - borders have to be drawn differently, pictures
>> currently don't work, and alignment should work with any units (and
>> it's easier to see rounding errors if the units are large).
>>
>> There is slight issue with element placement, though, If somebody uses
>> pixel coordinates for placing elements then the offsets will suddenly
>> become huge in text mode. Shouldn't the layouts be more portable?
>
> Hi,
>
> I'm thinking about using the "c" unit as default, as it's usable in
> both text and graphic mode, this would help to create portable config
> file. If user really want to use pixel unit, he can add "p" suffix,
> such as 100p.

What does c mean in graphics mode? I can see that in text mode it's
one character cell in either direction but there is no such thing in
graphics mode be cause different fonts and even different letters of
the same font have different character cells.

What would be especially confusing when using such a unit is that most
fonts (except perhaps CJK) have different character width and height
so does this mean the average (maximum, ,,) width of a character,
height of a character, or a different thing depending on the direction
in which the unit is used (vertical, horizontal)?

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/20 richardvoigt@gmail.com <richardvoigt@gmail.com>:
> On Sun, Sep 20, 2009 at 3:31 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/9/19 richardvoigt@gmail.com <richardvoigt@gmail.com>:
>>> On Sat, Sep 19, 2009 at 1:45 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> Hello
>>>>
>>>> why does the menu system have a glyph drawing function?
>>>>
>>>> Is the one in font.c not suitable?
>>>>
>>>> Why are there two methods for returning text width and height, one in
>>>> gfx_region in pixels, the other in text_region in characters? Does
>>>> size in characters make any sense? There might be proportional fonts
>>>> or at least fonts of different size in the future.
>>>
>>> Pixels and proportional fonts are meaningless to a serial console.
>>>
>> So is element placement.
>
> I know of multiple systems that support multiple columns, status bar,
> menu bar, popup dialogs, etc in text mode over a serial connection.
> If those things are considered out of scope for a bootloader, I'd tend
> to agree.  But people seem to be defining rich interfaces for grub and
> to do so requires the ability to measure sizes in characters.
>

Certainly, the Linux console also emulates what once used to be a
serial terminal.
The problem is that there are many types of different terminals and
terminal emulators which makes this somewhat difficult.

For this to work we would need

1) something like curses and its terminfo database in grub
2) know which terminal is connected to grub

Since (2) cannot be reliably determined by grub we must support the
case when the terminal is unknown and only very simple formatting can
be used (dumb terminal). It may be nice to use something like curses
when the user does configure the terminal type but I think this would
be very rare use and need not be part of the menu system initially. It
should be easy to adapt the code that deals with text mode for this
case if desired.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Mon, Sep 21, 2009 at 5:16 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/9/20 Bean <bean123ch@gmail.com>:
>> On Sun, Sep 20, 2009 at 4:30 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>
>>> So the text region is intended for drawing on text screen and the
>>> graphics region on graphics screen. I assume the check for pure text
>>> mode is there to choose which one is used.
>>>
>>> However, wouldn't this switch in coordinate system complicate further
>>> extending of the menu system with additional components?
>>>
>>> With these different coordinates every compound component would likely
>>> have to check which kind of rectangle is currently in use.
>>>
>>> Still it might work - borders have to be drawn differently, pictures
>>> currently don't work, and alignment should work with any units (and
>>> it's easier to see rounding errors if the units are large).
>>>
>>> There is slight issue with element placement, though, If somebody uses
>>> pixel coordinates for placing elements then the offsets will suddenly
>>> become huge in text mode. Shouldn't the layouts be more portable?
>>
>> Hi,
>>
>> I'm thinking about using the "c" unit as default, as it's usable in
>> both text and graphic mode, this would help to create portable config
>> file. If user really want to use pixel unit, he can add "p" suffix,
>> such as 100p.
>
> What does c mean in graphics mode? I can see that in text mode it's
> one character cell in either direction but there is no such thing in
> graphics mode be cause different fonts and even different letters of
> the same font have different character cells.
>
> What would be especially confusing when using such a unit is that most
> fonts (except perhaps CJK) have different character width and height
> so does this mean the average (maximum, ,,) width of a character,
> height of a character, or a different thing depending on the direction
> in which the unit is used (vertical, horizontal)?

Hi,

In graphic mode, 'c' unit is the width/height of the reference
character ( I use 'O' as reference character in menu_test.c) using
system default font, this ensure that 1c is always the same size in
the current system.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/21 Bean <bean123ch@gmail.com>:
> On Mon, Sep 21, 2009 at 5:16 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/9/20 Bean <bean123ch@gmail.com>:
>>> On Sun, Sep 20, 2009 at 4:30 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>
>>>> So the text region is intended for drawing on text screen and the
>>>> graphics region on graphics screen. I assume the check for pure text
>>>> mode is there to choose which one is used.
>>>>
>>>> However, wouldn't this switch in coordinate system complicate further
>>>> extending of the menu system with additional components?
>>>>
>>>> With these different coordinates every compound component would likely
>>>> have to check which kind of rectangle is currently in use.
>>>>
>>>> Still it might work - borders have to be drawn differently, pictures
>>>> currently don't work, and alignment should work with any units (and
>>>> it's easier to see rounding errors if the units are large).
>>>>
>>>> There is slight issue with element placement, though, If somebody uses
>>>> pixel coordinates for placing elements then the offsets will suddenly
>>>> become huge in text mode. Shouldn't the layouts be more portable?
>>>
>>> Hi,
>>>
>>> I'm thinking about using the "c" unit as default, as it's usable in
>>> both text and graphic mode, this would help to create portable config
>>> file. If user really want to use pixel unit, he can add "p" suffix,
>>> such as 100p.
>>
>> What does c mean in graphics mode? I can see that in text mode it's
>> one character cell in either direction but there is no such thing in
>> graphics mode be cause different fonts and even different letters of
>> the same font have different character cells.
>>
>> What would be especially confusing when using such a unit is that most
>> fonts (except perhaps CJK) have different character width and height
>> so does this mean the average (maximum, ,,) width of a character,
>> height of a character, or a different thing depending on the direction
>> in which the unit is used (vertical, horizontal)?
>
> Hi,
>
> In graphic mode, 'c' unit is the width/height of the reference
> character ( I use 'O' as reference character in menu_test.c) using
> system default font, this ensure that 1c is always the same size in
> the current system.

IIRC traditionally X is used for height and m for width.

Either way it is a unit that is not the same when measured vertically
and horizontally, and it is not possible to draw a square using this
unit.

Also when you want to make a box that accomodates n lines of text you
need a unit for line-height. That is, you need to take into account
the maximum rise of characters like ÅÕṌṎ, and maximum fall of
characters like ᶘɀ and also include some space between the lines so
that they do not merge visually.

I guess it would be quite common to either display a box that can
accommodate a piece of text or a box that fits the most lines of text
possible in a given space so it would be useful to have units for
that.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Wed, Sep 23, 2009 at 7:29 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> IIRC traditionally X is used for height and m for width.
>
> Either way it is a unit that is not the same when measured vertically
> and horizontally, and it is not possible to draw a square using this
> unit.
>
> Also when you want to make a box that accomodates n lines of text you
> need a unit for line-height. That is, you need to take into account
> the maximum rise of characters like ÅÕṌṎ, and maximum fall of
> characters like ᶘɀ and also include some space between the lines so
> that they do not merge visually.
>
> I guess it would be quite common to either display a box that can
> accommodate a piece of text or a box that fits the most lines of text
> possible in a given space so it would be useful to have units for
> that.

Hi,

Height includes ascent, descent and leading, the value is the same for
all characters, we only need to choose the reference character for
width calculation.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:
Add widget infrastructure, currently only implement two widget, screen
and panel.
Support loading from theme file.

I've packed the resource and upload it at:

http://grub4dos.sourceforge.net/menu.zip

To use it, unzip to /menu and add the following line in grub.cfg:

. /menu/menu.cfg

Select "text mode" or "graphic mode", it would draw the menu based on
config file, press any key and it returns to grub menu.

Here is the sample theme file:

screen
{
  panel
  {
    x = "5"
    y = "5"
    width = "-5"
    height = "-5"

    top_left = "/menu/menu_tl.png,,black/cyan/#0x250F"
    top = "/menu/menu_t.png,tiling,black/cyan/#0x2501"
    top_right = "/menu/menu_tr.png,,black/cyan/#0x2513"
    left = "/menu/menu_l.png,tiling,black/cyan/#0x2503"
    right = "/menu/menu_r.png,tiling,black/cyan/#0x2503"
    bottom_left = "/menu/menu_bl.png,,black/cyan/#0x2517"
    bottom = "/menu/menu_b.png,tiling,black/cyan/#0x2501"
    bottom_right = "/menu/menu_br.png,tiling,black/cyan/#0x251B"

    background = "/menu/back.png,,#808080/cyan"

    panel
    {
      x = 1
      y = 1
      width = -1
      height = 2
      background = ",blue"
    }
  }
}

The most complex property is the background image, for example:

top = "/menu/menu_t.png,tiling,black/cyan/#0x2501"

/menu/menu_t.png - image
tiling - scaling method (can be empty, center, tiling, minfit, maxfit)
black/cyan/#0x2501 - color, the full format is something like this:

#808080/black/cyan/A

#808080 - color in graphic mode
black - foreground in text mode
cyan - background in text mode
A - fill char in text mode

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

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
{
  panel
  {
    x = "5"
    y = "5"

    top_left = "/menu/menu_tl.png,,black/cyan/#0x250F"
    top = "/menu/menu_t.png,tiling,black/cyan/#0x2501"
    top_right = "/menu/menu_tr.png,,black/cyan/#0x2513"
    left = "/menu/menu_l.png,tiling,black/cyan/#0x2503"
    right = "/menu/menu_r.png,tiling,black/cyan/#0x2503"
    bottom_left = "/menu/menu_bl.png,,black/cyan/#0x2517"
    bottom = "/menu/menu_b.png,tiling,black/cyan/#0x2501"
    bottom_right = "/menu/menu_br.png,tiling,black/cyan/#0x251B"

    background = "/menu/back.png,,#808080/cyan"

    label
    {
      color = "black/cyan"
      image = "/menu/debian.png,,blue"
      title = "Hello Debian"
      spacing = 1
    }
    label
    {
      color = "yellow/cyan"
      image = "/menu/ubuntu.png,,blue"
      title = "Hello Ubuntui (long)"
      spacing = 1
    }
    label
    {
      color = "blue/cyan"
      image = "/menu/gentoo.png,,blue"
      title = "Hello Gentoo"
      spacing = 1
    }
  }
}

The x/y/width/height property is not set in label widget, they'll be
calculated automatically by panel. The width/height property of panel
is also skipped, which means using the minimum width/height that
contains child widgets.

The full properties of these widgets are:

screen:
background - background image

panel:
background - background image
top_left. top, top_right, left, right, bottom_left, bottom,
bottom_right - image for borders

label
font - font name
color - font color
image - icon image
title - title text
spacing - space between image and title

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

Hello,

Thanks for this menu preview looks very good.

I guess it could use more padding but if that can be added in the
style there is no problem with that.

There is also an odd column with blue background in text mode. Is that
replacement for the icons? I guess they should not be displayed if it
is not possible to render them.

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.

2009/9/23 Bean <bean123ch@gmail.com>:
> 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.

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

Typically it needs something like margin or border or padding to get
some offset between the inner elements and the outside.

This also reminds me that there is nice way of handling pixels in text
mode - just ignore them. That places the menu inside something like
this

http://www.gnome-look.org/CONTENT/content-files/84298-terminal.jpg

would also look reasonably in text where the image is not displayed.

>
>    top_left = "/menu/menu_tl.png,,black/cyan/#0x250F"
>    top = "/menu/menu_t.png,tiling,black/cyan/#0x2501"
>    top_right = "/menu/menu_tr.png,,black/cyan/#0x2513"
>    left = "/menu/menu_l.png,tiling,black/cyan/#0x2503"
>    right = "/menu/menu_r.png,tiling,black/cyan/#0x2503"
>    bottom_left = "/menu/menu_bl.png,,black/cyan/#0x2517"
>    bottom = "/menu/menu_b.png,tiling,black/cyan/#0x2501"
>    bottom_right = "/menu/menu_br.png,tiling,black/cyan/#0x251B"
>
>    background = "/menu/back.png,,#808080/cyan"
>
>    label
>    {
>      color = "black/cyan"
>      image = "/menu/debian.png,,blue"
>      title = "Hello Debian"
>      spacing = 1
>    }
>    label
>    {
>      color = "yellow/cyan"
>      image = "/menu/ubuntu.png,,blue"
>      title = "Hello Ubuntui (long)"
>      spacing = 1
>    }
>    label
>    {
>      color = "blue/cyan"
>      image = "/menu/gentoo.png,,blue"
>      title = "Hello Gentoo"
>      spacing = 1
>    }
>  }
> }
>
> The x/y/width/height property is not set in label widget, they'll be
> calculated automatically by panel. The width/height property of panel
> is also skipped, which means using the minimum width/height that
> contains child widgets.
>
> The full properties of these widgets are:
>
> screen:
> background - background image
>
> panel:
> background - background image
> top_left. top, top_right, left, right, bottom_left, bottom,
> bottom_right - image for borders

Are these meant to be borders only?

I guess people who use something like

http://openclipart.org/people/Anonymous/Anonymous_celtic_vine_corner.svg

won't want the whole menu offset by the size of the image.

Is it possible to set a border without supplying these images?


>
> label
> font - font name
> color - font color
> image - icon image
> title - title text
> spacing - space between image and title

I guess it would be better to change the naming a bit.
I would use 'text' rather than 'title'. The label can be used even for
plain text, not only huge captions (and there is no choice actually
because we have only a single plain font).

'spacing' should not be used alone. There is font spacing, line
spacing, the padding between contained elements, the padding the
padding between the contained elements and the border....
Each should be possible to set by a property so there is clearly more
than one spacing.


Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Sep 24, 2009 at 3:20 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> Hello,
>
> Thanks for this menu preview looks very good.
>
> I guess it could use more padding but if that can be added in the
> style there is no problem with that.
>
> There is also an odd column with blue background in text mode. Is that
> replacement for the icons? I guess they should not be displayed if it
> is not possible to render them.

Hi,

The default handling for bitmap is to replace it with rect if it can't
be displayed (text mode or file not found), although I can just skip
it for the image in label widget.

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


>
> 2009/9/23 Bean <bean123ch@gmail.com>:
>> 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.

As for menu, it's better to move it to a different tree, and reference
it in the menu widget, perhaps something like this:


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.

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

>
> Typically it needs something like margin or border or padding to get
> some offset between the inner elements and the outside.
>
> This also reminds me that there is nice way of handling pixels in text
> mode - just ignore them. That places the menu inside something like
> this
>
> http://www.gnome-look.org/CONTENT/content-files/84298-terminal.jpg
>
> would also look reasonably in text where the image is not displayed.
>

But sometimes we also need border in text mode, currently it would
show bitmap in graphic mode, and a ascii box in text mode.

>>
>>    top_left = "/menu/menu_tl.png,,black/cyan/#0x250F"
>>    top = "/menu/menu_t.png,tiling,black/cyan/#0x2501"
>>    top_right = "/menu/menu_tr.png,,black/cyan/#0x2513"
>>    left = "/menu/menu_l.png,tiling,black/cyan/#0x2503"
>>    right = "/menu/menu_r.png,tiling,black/cyan/#0x2503"
>>    bottom_left = "/menu/menu_bl.png,,black/cyan/#0x2517"
>>    bottom = "/menu/menu_b.png,tiling,black/cyan/#0x2501"
>>    bottom_right = "/menu/menu_br.png,tiling,black/cyan/#0x251B"
>>
>>    background = "/menu/back.png,,#808080/cyan"
>>
>>    label
>>    {
>>      color = "black/cyan"
>>      image = "/menu/debian.png,,blue"
>>      title = "Hello Debian"
>>      spacing = 1
>>    }
>>    label
>>    {
>>      color = "yellow/cyan"
>>      image = "/menu/ubuntu.png,,blue"
>>      title = "Hello Ubuntui (long)"
>>      spacing = 1
>>    }
>>    label
>>    {
>>      color = "blue/cyan"
>>      image = "/menu/gentoo.png,,blue"
>>      title = "Hello Gentoo"
>>      spacing = 1
>>    }
>>  }
>> }
>>
>> The x/y/width/height property is not set in label widget, they'll be
>> calculated automatically by panel. The width/height property of panel
>> is also skipped, which means using the minimum width/height that
>> contains child widgets.
>>
>> The full properties of these widgets are:
>>
>> screen:
>> background - background image
>>
>> panel:
>> background - background image
>> top_left. top, top_right, left, right, bottom_left, bottom,
>> bottom_right - image for borders
>
> Are these meant to be borders only?
>
> I guess people who use something like
>
> http://openclipart.org/people/Anonymous/Anonymous_celtic_vine_corner.svg
>
> won't want the whole menu offset by the size of the image.
>
> Is it possible to set a border without supplying these images?

For those image, just use it as background image. Perhaps sometime like this:

panel
{
  background = "image.png"
  panel
  {
    x = 10%
    y = 10%
    width = -0
    height = -0
    ..
}

>
>
>>
>> label
>> font - font name
>> color - font color
>> image - icon image
>> title - title text
>> spacing - space between image and title
>
> I guess it would be better to change the naming a bit.
> I would use 'text' rather than 'title'. The label can be used even for
> plain text, not only huge captions (and there is no choice actually
> because we have only a single plain font).
>
> 'spacing' should not be used alone. There is font spacing, line
> spacing, the padding between contained elements, the padding the
> padding between the contained elements and the border....
> Each should be possible to set by a property so there is clearly more
> than one spacing.

Right, the naming need some tuning.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/24 Bean <bean123ch@gmail.com>:
> On Thu, Sep 24, 2009 at 3:20 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> Hello,
>>
>> Thanks for this menu preview looks very good.
>>
>> I guess it could use more padding but if that can be added in the
>> style there is no problem with that.
>>
>> There is also an odd column with blue background in text mode. Is that
>> replacement for the icons? I guess they should not be displayed if it
>> is not possible to render them.
>
> Hi,
>
> The default handling for bitmap is to replace it with rect if it can't
> be displayed (text mode or file not found), although I can just skip
> it for the image in label widget.

Since there should be no element that shows only bitmap it can be
simply omitted.

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

>
>
>>
>> 2009/9/23 Bean <bean123ch@gmail.com>:
>>> 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.

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

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


>> Typically it needs something like margin or border or padding to get
>> some offset between the inner elements and the outside.
>>
>> This also reminds me that there is nice way of handling pixels in text
>> mode - just ignore them. That places the menu inside something like
>> this
>>
>> http://www.gnome-look.org/CONTENT/content-files/84298-terminal.jpg
>>
>> would also look reasonably in text where the image is not displayed.
>>
>
> But sometimes we also need border in text mode, currently it would
> show bitmap in graphic mode, and a ascii box in text mode.

This is somewhat problematic. What if I have a border in the
background bitmap already but want to show a border in text mode. How
does this work if I set the border bitmap only for some directions
(incomplete border) ?


>
>>>
>>> á átop_left = "/menu/menu_tl.png,,black/cyan/#0x250F"
>>> á átop = "/menu/menu_t.png,tiling,black/cyan/#0x2501"
>>> á átop_right = "/menu/menu_tr.png,,black/cyan/#0x2513"
>>> á áleft = "/menu/menu_l.png,tiling,black/cyan/#0x2503"
>>> á áright = "/menu/menu_r.png,tiling,black/cyan/#0x2503"
>>> á ábottom_left = "/menu/menu_bl.png,,black/cyan/#0x2517"
>>> á ábottom = "/menu/menu_b.png,tiling,black/cyan/#0x2501"
>>> á ábottom_right = "/menu/menu_br.png,tiling,black/cyan/#0x251B"
>>>
>>> á ábackground = "/menu/back.png,,#808080/cyan"
>>>
>>> á álabel
>>> á á{
>>> á á ácolor = "black/cyan"
>>> á á áimage = "/menu/debian.png,,blue"
>>> á á átitle = "Hello Debian"
>>> á á áspacing = 1
>>> á á}
>>> á álabel
>>> á á{
>>> á á ácolor = "yellow/cyan"
>>> á á áimage = "/menu/ubuntu.png,,blue"
>>> á á átitle = "Hello Ubuntui (long)"
>>> á á áspacing = 1
>>> á á}
>>> á álabel
>>> á á{
>>> á á ácolor = "blue/cyan"
>>> á á áimage = "/menu/gentoo.png,,blue"
>>> á á átitle = "Hello Gentoo"
>>> á á áspacing = 1
>>> á á}
>>> á}
>>> }
>>>
>>> The x/y/width/height property is not set in label widget, they'll be
>>> calculated automatically by panel. The width/height property of panel
>>> is also skipped, which means using the minimum width/height that
>>> contains child widgets.
>>>
>>> The full properties of these widgets are:
>>>
>>> screen:
>>> background - background image
>>>
>>> panel:
>>> background - background image
>>> top_left. top, top_right, left, right, bottom_left, bottom,
>>> bottom_right - image for borders
>>
>> Are these meant to be borders only?
>>
>> I guess people who use something like
>>
>> http://openclipart.org/people/Anonymous/Anonymous_celtic_vine_corner.svg
>>
>> won't want the whole menu offset by the size of the image.
>>
>> Is it possible to set a border without supplying these images?
>
> For those image, just use it as background image. Perhaps sometime like this:
>
> panel
> {
>  background = "image.png"
>  panel
>  {
>    x = 10%
>    y = 10%
>    width = -0
>    height = -0
>    ..
> }

That would work for single decoration. However, if I have such
decoration for multiple locations (ie top right and bottom left) I
would have to compose them into a single image and scale them which is
doable but not nice, especially because scaling is slow and ugly.

Also in some cases the border bitmap is meant to be mostly background
(ie it contains the border and a large gradient that only slightly
differs from the background colour).

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Sep 24, 2009 at 5:40 PM, Michal Suchanek <hramrach@centrum.cz> 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.

>
>>
>>
>>>
>>> 2009/9/23 Bean <bean123ch@gmail.com>:
>>>> 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
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.

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

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%
  }
}

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/24 Bean <bean123ch@gmail.com>:
> On Thu, Sep 24, 2009 at 5:40 PM, Michal Suchanek <hramrach@centrum.cz> 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 <bean123ch@gmail.com>:
>>>>> 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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

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/

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/25 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.

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Fri, Sep 25, 2009 at 5:00 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 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.

Hi,

But max_columns can cover both case,

max_columns = 1
one column

max_columns = 1000  (or any big number)
one row, we could also use special number -1 to indicate infinite
number of widgets.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/25 Bean <bean123ch@gmail.com>:
> On Fri, Sep 25, 2009 at 5:00 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 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.
>
> Hi,
>
> But max_columns can cover both case,
>
> max_columns = 1
> one column
>
> max_columns = 1000  (or any big number)
> one row, we could also use special number -1 to indicate infinite
> number of widgets.
>

OK, it does but it is quite confusing way of achieving that.

What do the other possible values give you, though?

If I set max_colums to 3 then I get rows of 1-3 cells,
non-deterministically. I can't say  in what row or column a particular
cell will be. Is such layout useful for anything?

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Fri, Sep 25, 2009 at 5:46 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/9/25 Bean <bean123ch@gmail.com>:
>> On Fri, Sep 25, 2009 at 5:00 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> 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.
>>
>> Hi,
>>
>> But max_columns can cover both case,
>>
>> max_columns = 1
>> one column
>>
>> max_columns = 1000  (or any big number)
>> one row, we could also use special number -1 to indicate infinite
>> number of widgets.
>>
>
> OK, it does but it is quite confusing way of achieving that.
>
> What do the other possible values give you, though?
>
> If I set max_colums to 3 then I get rows of 1-3 cells,
> non-deterministically. I can't say  in what row or column a particular
> cell will be. Is such layout useful for anything?

Hi,

If max_columns = 3, then every row has three widgets, except for the
last one, which can have 1 or 2 widgets. We can draw n * 3 tables with
it.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/25 Bean <bean123ch@gmail.com>:
> On Fri, Sep 25, 2009 at 5:46 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/9/25 Bean <bean123ch@gmail.com>:
>>> On Fri, Sep 25, 2009 at 5:00 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> 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.
>>>
>>> Hi,
>>>
>>> But max_columns can cover both case,
>>>
>>> max_columns = 1
>>> one column
>>>
>>> max_columns = 1000  (or any big number)
>>> one row, we could also use special number -1 to indicate infinite
>>> number of widgets.
>>>
>>
>> OK, it does but it is quite confusing way of achieving that.
>>
>> What do the other possible values give you, though?
>>
>> If I set max_colums to 3 then I get rows of 1-3 cells,
>> non-deterministically. I can't say  in what row or column a particular
>> cell will be. Is such layout useful for anything?
>
> Hi,
>
> If max_columns = 3, then every row has three widgets, except for the
> last one, which can have 1 or 2 widgets. We can draw n * 3 tables with
> it.
>

Then it should perhaps be called simply columns.

However, if you start with tables people will start with why doesn't
this have colspan/rowspan.

And I really can't imagine using tables in the boot menu. What for?

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Fri, Sep 25, 2009 at 6:13 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/9/25 Bean <bean123ch@gmail.com>:
>> On Fri, Sep 25, 2009 at 5:46 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> 2009/9/25 Bean <bean123ch@gmail.com>:
>>>> On Fri, Sep 25, 2009 at 5:00 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>> 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.
>>>>
>>>> Hi,
>>>>
>>>> But max_columns can cover both case,
>>>>
>>>> max_columns = 1
>>>> one column
>>>>
>>>> max_columns = 1000  (or any big number)
>>>> one row, we could also use special number -1 to indicate infinite
>>>> number of widgets.
>>>>
>>>
>>> OK, it does but it is quite confusing way of achieving that.
>>>
>>> What do the other possible values give you, though?
>>>
>>> If I set max_colums to 3 then I get rows of 1-3 cells,
>>> non-deterministically. I can't say  in what row or column a particular
>>> cell will be. Is such layout useful for anything?
>>
>> Hi,
>>
>> If max_columns = 3, then every row has three widgets, except for the
>> last one, which can have 1 or 2 widgets. We can draw n * 3 tables with
>> it.
>>
>
> Then it should perhaps be called simply columns.
>
> However, if you start with tables people will start with why doesn't
> this have colspan/rowspan.
>
> And I really can't imagine using tables in the boot menu. What for?

Hi,

For example, we can use large icon to represent boot item, like those
in rEFIt. In this case, we might want to limit the items per line so
that the menu won't get too width. In this case, we can set something
like max_columns = 5. If it has more than 5 icons, it would start in
the second row.


-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/25 Bean <bean123ch@gmail.com>:
> On Fri, Sep 25, 2009 at 6:13 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/9/25 Bean <bean123ch@gmail.com>:
>>> On Fri, Sep 25, 2009 at 5:46 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> 2009/9/25 Bean <bean123ch@gmail.com>:
>>>>> On Fri, Sep 25, 2009 at 5:00 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>>> 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.
>>>>>
>>>>> Hi,
>>>>>
>>>>> But max_columns can cover both case,
>>>>>
>>>>> max_columns = 1
>>>>> one column
>>>>>
>>>>> max_columns = 1000  (or any big number)
>>>>> one row, we could also use special number -1 to indicate infinite
>>>>> number of widgets.
>>>>>
>>>>
>>>> OK, it does but it is quite confusing way of achieving that.
>>>>
>>>> What do the other possible values give you, though?
>>>>
>>>> If I set max_colums to 3 then I get rows of 1-3 cells,
>>>> non-deterministically. I can't say  in what row or column a particular
>>>> cell will be. Is such layout useful for anything?
>>>
>>> Hi,
>>>
>>> If max_columns = 3, then every row has three widgets, except for the
>>> last one, which can have 1 or 2 widgets. We can draw n * 3 tables with
>>> it.
>>>
>>
>> Then it should perhaps be called simply columns.
>>
>> However, if you start with tables people will start with why doesn't
>> this have colspan/rowspan.
>>
>> And I really can't imagine using tables in the boot menu. What for?
>
> Hi,
>
> For example, we can use large icon to represent boot item, like those
> in rEFIt. In this case, we might want to limit the items per line so
> that the menu won't get too width. In this case, we can set something
> like max_columns = 5. If it has more than 5 icons, it would start in
> the second row.

Note that rEFIt does not wrap the icons, it scrolls them if there are
too many. And there is good reason for that, navigating a table is
quite tedious, and when a new item is added in the middle the table
shifts in ways which make it hard to find previously existing items.

It does, however, have tow separate strips of icons. One strip are
tool icons, the larger one are the automatically gathered OS icons.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Some adjustment to data representation. For example:

background = "/splash.png"

means loads splash.png, no extra handling if loading fails (text mode
or file not found)

background = "/splash.png,,blue"

means loads splash.png, if it fails, replace it with rect that has
blue background

Add new number format to specify size for both graphic and text mode:

space = 10/0

10 pixel in graphic text, 0 in text mode

New layout manger, it support the following parameters:

columns
valign
halign
width
height
vspace
hspace
vmargin
hmargin

width/height is the size of widget, if it's not set, the size is
calculated automatically using the size of child widgets

vmargin, hmargin is the distance between horizontal and vertical
border, positive value is from left/top, while negative value is from
right/bottom, for example:

panel
{
  vmargin = -0
  hmargin = -0
}

places the panel in the bottom right corner.

Here is a sample config file that shows different valign/halign
combination, the image file is inside the previous menu.zip.

screen
{
  halign = "center"
  valign = "center"
  columns = 3
  background = "/menu/back.png"

  panel
  {
    background = ",blue"
    hspace = 10/0
    vspace = 5/0
    halign = left
    valign = top
    width = 28%
    height = 28%
    label
    {
      color = "light-red/cyan"
      text = "AA"
      space = 1
    }
    label
    {
      color = "yellow/cyan"
      text = "BBBBBB"
      space = 1
    }
    label
    {
      color = "light-magenta/cyan"
      text = "CCCC"
      space = 1
    }
  }

  panel
  {
    background = ",blue"
    hspace = 10/0
    vspace = 5/0
    halign = center
    valign = top
    width = 28%
    height = 28%
    label
    {
      color = "light-red/cyan"
      text = "AA"
      space = 1
    }
    label
    {
      color = "yellow/cyan"
      text = "BBBBBB"
      space = 1
    }
    label
    {
      color = "light-magenta/cyan"
      text = "CCCC"
      space = 1
    }
  }

  panel
  {
    background = ",blue"
    hspace = 10/0
    vspace = 5/0
    halign = right
    valign = top
    width = 28%
    height = 28%
    label
    {
      color = "light-red/cyan"
      text = "AA"
      space = 1
    }
    label
    {
      color = "yellow/cyan"
      text = "BBBBBB"
      space = 1
    }
    label
    {
      color = "light-magenta/cyan"
      text = "CCCC"
      space = 1
    }
  }

  panel
  {
    background = ",blue"
    hspace = 10/0
    vspace = 5/0
    halign = left
    valign = center
    width = 28%
    height = 28%
    label
    {
      color = "light-red/cyan"
      text = "AA"
      space = 1
    }
    label
    {
      color = "yellow/cyan"
      text = "BBBBBB"
      space = 1
    }
    label
    {
      color = "light-magenta/cyan"
      text = "CCCC"
      space = 1
    }
  }

  panel
  {
    background = ",blue"
    hspace = 10/0
    vspace = 5/0
    halign = center
    valign = center
    width = 28%
    height = 28%
    label
    {
      color = "light-red/cyan"
      text = "AA"
      space = 1
    }
    label
    {
      color = "yellow/cyan"
      text = "BBBBBB"
      space = 1
    }
    label
    {
      color = "light-magenta/cyan"
      text = "CCCC"
      space = 1
    }
  }
  panel
  {
    background = ",blue"
    hspace = 10/0
    vspace = 5/0
    halign = right
    valign = center
    width = 28%
    height = 28%
    label
    {
      color = "light-red/cyan"
      text = "AA"
      space = 1
    }
    label
    {
      color = "yellow/cyan"
      text = "BBBBBB"
      space = 1
    }
    label
    {
      color = "light-magenta/cyan"
      text = "CCCC"
      space = 1
    }
  }

  panel
  {
    background = ",blue"
    hspace = 10/0
    vspace = 5/0
    halign = left
    valign = bottom
    width = 28%
    height = 28%
    label
    {
      color = "light-red/cyan"
      text = "AA"
      space = 1
    }
    label
    {
      color = "yellow/cyan"
      text = "BBBBBB"
      space = 1
    }
    label
    {
      color = "light-magenta/cyan"
      text = "CCCC"
      space = 1
    }
  }

  panel
  {
    background = ",blue"
    hspace = 10/0
    vspace = 5/0
    halign = center
    valign = bottom
    width = 28%
    height = 28%
    label
    {
      color = "light-red/cyan"
      text = "AA"
      space = 1
    }
    label
    {
      color = "yellow/cyan"
      text = "BBBBBB"
      space = 1
    }
    label
    {
      color = "light-magenta/cyan"
      text = "CCCC"
      space = 1
    }
  }

  panel
  {
    top_left = "/menu/menu_tl.png,,black/cyan/#0x250F"
    top = "/menu/menu_t.png,tiling,black/cyan/#0x2501"
    top_right = "/menu/menu_tr.png,,black/cyan/#0x2513"
    left = "/menu/menu_l.png,tiling,black/cyan/#0x2503"
    right = "/menu/menu_r.png,tiling,black/cyan/#0x2503"
    bottom_left = "/menu/menu_bl.png,,black/cyan/#0x2517"
    bottom = "/menu/menu_b.png,tiling,black/cyan/#0x2501"
    bottom_right = "/menu/menu_br.png,tiling,black/cyan/#0x251B"

    background = ",blue"
    hspace = 10/0
    vspace = 5/0
    halign = right
    valign = bottom
    hmargin = -0
    vmargin = -0
    label
    {
      color = "light-red/cyan"
      text = "AA"
      space = 1
    }
    label
    {
      color = "yellow/cyan"
      text = "BBBBBB"
      space = 1
    }
    label
    {
      color = "light-magenta/cyan"
      text = "CCCC"
      space = 1
    }
  }
}


-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

Hello

2009/9/25 Bean <bean123ch@gmail.com>:
> Hi,
>
> Update:
>
> Some adjustment to data representation. For example:
>
> background = "/splash.png"
>
> means loads splash.png, no extra handling if loading fails (text mode
> or file not found)
>
> background = "/splash.png,,blue"
>
> means loads splash.png, if it fails, replace it with rect that has
> blue background

This sounds reasonable for a background image. The background can be
also used for transparent parts of the image. For a label icon the
background should be probably taken from the label, including
transparent background or image background. If the icon fails to load
the size is zero unless explicitly scaled.

>
> Add new number format to specify size for both graphic and text mode:
>
> space = 10/0

I would prefer if the spacing would not need to be specified
separately for text mode and graphics mode.

I hope I can get to creating some layout mockups so that we can see if
that is feasible.

>
> 10 pixel in graphic text, 0 in text mode
>
> New layout manger, it support the following parameters:
>
> columns
> valign
> halign
> width
> height
> vspace
> hspace
> vmargin
> hmargin
>
> width/height is the size of widget, if it's not set, the size is
> calculated automatically using the size of child widgets

For sizing two modes are useful: the minimum sizing that assigns the
size required to display all content and the maximum sizing that
expands the widget as much as possible. If width = 100% means that any
siblings are not displayed because the widget occupies exactly the
available space then a different notation would be useful for taking a
share of the available width.

>
> vmargin, hmargin is the distance between horizontal and vertical
> border, positive value is from left/top, while negative value is from
> right/bottom, for example:
>
> panel
> {
>  vmargin = -0
>  hmargin = -0
> }
>
> places the panel in the bottom right corner.

How does this resolve the problem of setting the top, left, bottom and
right margin without knowing the size (width, height) of the panel?

I know that when panel is drawn the size is known but the size might
not be known when the configuration is written (different screen sizes
or label lengths). Setting the size (width, height) might be
appropriate in some cases but in most it should be calculated
automatically so that the layout fits in the available space.

I might want a bit of space (like 0.5 em or 0.5c) around a label so
that the label text is not sticking to the border as it was in the
last demo.

If I have a background picture over which I want to draw the menu and
it has a designated area for this I can either measure the menu
position as x,y,width, height or as top, left, bottom, right. The
latter has the advantage that if I decide to allow scaling the picture
I can measure the margin in % and the rounding error for each border
is the same. For x,y,width,height the rounding error of the bottom
corner is twice as large.

In the general case I would want to avoid the menu sticking to the
border of the screen which again calls for a margin.

>
> Here is a sample config file that shows different valign/halign
> combination, the image file is inside the previous menu.zip.
>
> screen
> {
>  halign = "center"
>  valign = "center"
>  columns = 3

This is not nice because when you add a new panel it wraps to the next
row. For most uses grouping panels in a single direction seems more
useful. When they have some logical order that order is preserved when
a new panel is added.

>  background = "/menu/back.png"
>
>  panel
>  {
>    background = ",blue"
>    hspace = 10/0
>    vspace = 5/0
>    halign = left
>    valign = top
>    width = 28%
>    height = 28%

Calculating this value is error prone and redundant since it is the
same for all panels.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Mon, Sep 28, 2009 at 12:12 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> Add new number format to specify size for both graphic and text mode:
>>
>> space = 10/0
>
> I would prefer if the spacing would not need to be specified
> separately for text mode and graphics mode.
>
> I hope I can get to creating some layout mockups so that we can see if
> that is feasible.
>

Hi,

You can still use character unit as:

space = 1

But the problem is that minimum value is 1. In text mode, 1 character
size is significant. We don't want to spend valuable space for
parameters like vspace and hspace. But in graphic mode, we can afford
some pixel on spacing.

>>
>> 10 pixel in graphic text, 0 in text mode
>>
>> New layout manger, it support the following parameters:
>>
>> columns
>> valign
>> halign
>> width
>> height
>> vspace
>> hspace
>> vmargin
>> hmargin
>>
>> width/height is the size of widget, if it's not set, the size is
>> calculated automatically using the size of child widgets
>
> For sizing two modes are useful: the minimum sizing that assigns the
> size required to display all content and the maximum sizing that
> expands the widget as much as possible. If width = 100% means that any
> siblings are not displayed because the widget occupies exactly the
> available space then a different notation would be useful for taking a
> share of the available width.
>

Yep, I have plans for the min_width/min_height/max_width/max_height property.

>>
>> vmargin, hmargin is the distance between horizontal and vertical
>> border, positive value is from left/top, while negative value is from
>> right/bottom, for example:
>>
>> panel
>> {
>>  vmargin = -0
>>  hmargin = -0
>> }
>>
>> places the panel in the bottom right corner.
>
> How does this resolve the problem of setting the top, left, bottom and
> right margin without knowing the size (width, height) of the panel?
>
> I know that when panel is drawn the size is known but the size might
> not be known when the configuration is written (different screen sizes
> or label lengths). Setting the size (width, height) might be
> appropriate in some cases but in most it should be calculated
> automatically so that the layout fits in the available space.
>

It'd work as expected, you can see it by setting the width/height of
the last panel to 28%/28%, it'd still stick to the border. The program
do this in two steps, first the size, then the position, it allows to
the widget to change the size before position is calculated.

> I might want a bit of space (like 0.5 em or 0.5c) around a label so
> that the label text is not sticking to the border as it was in the
> last demo.

You can do this with vspace/hspace. The last panel looks compact as it
does specify width/height so that the minimum required size is used.

>
> If I have a background picture over which I want to draw the menu and
> it has a designated area for this I can either measure the menu
> position as x,y,width, height or as top, left, bottom, right. The
> latter has the advantage that if I decide to allow scaling the picture
> I can measure the margin in % and the rounding error for each border
> is the same. For x,y,width,height the rounding error of the bottom
> corner is twice as large.
>
> In the general case I would want to avoid the menu sticking to the
> border of the screen which again calls for a margin.
>

Actually, when vmargin and hmargin is positive number, it's exactly
the same as x,y, but it also allows to stick to other borders, which
is impossible for x,y without setting the size.

>>
>> Here is a sample config file that shows different valign/halign
>> combination, the image file is inside the previous menu.zip.
>>
>> screen
>> {
>>  halign = "center"
>>  valign = "center"
>>  columns = 3
>
> This is not nice because when you add a new panel it wraps to the next
> row. For most uses grouping panels in a single direction seems more
> useful. When they have some logical order that order is preserved when
> a new panel is added.
>

For single row, set
columns = 0

For single column, set:
columns = 1

>>  background = "/menu/back.png"
>>
>>  panel
>>  {
>>    background = ",blue"
>>    hspace = 10/0
>>    vspace = 5/0
>>    halign = left
>>    valign = top
>>    width = 28%
>>    height = 28%
>
> Calculating this value is error prone and redundant since it is the
> same for all panels.

This is just a demo, in fact, you can skip the width/height parameter
and it will calculate the minimum size for you. But in this case, you
can't see the valign/halign property in action inside the panel.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

Hello

2009/9/27 Bean <bean123ch@gmail.com>:
> On Mon, Sep 28, 2009 at 12:12 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> Add new number format to specify size for both graphic and text mode:
>>>
>>> space = 10/0
>>
>> I would prefer if the spacing would not need to be specified
>> separately for text mode and graphics mode.
>>
>> I hope I can get to creating some layout mockups so that we can see if
>> that is feasible.
>>
>
> Hi,
>
> You can still use character unit as:
>
> space = 1
>
> But the problem is that minimum value is 1. In text mode, 1 character
> size is significant. We don't want to spend valuable space for

We do. It improves readability.

> parameters like vspace and hspace. But in graphic mode, we can afford
> some pixel on spacing.

Does that mean that now the units are characters in text mode and
pixels in graphics when specified separately?

Also when the vspace is set to 1 instead of 5/0 the text does not fit
into the panel but is still drawn. The widgets should really use
viewport for drawing to avoid these overflows. Unfortunately, this is
probably not available in text mode but it should not be hard to add.


>
>>>
>>> 10 pixel in graphic text, 0 in text mode
>>>
>>> New layout manger, it support the following parameters:
>>>
>>> columns
>>> valign
>>> halign
>>> width
>>> height
>>> vspace
>>> hspace
>>> vmargin
>>> hmargin
>>>
>>> width/height is the size of widget, if it's not set, the size is
>>> calculated automatically using the size of child widgets
>>
>> For sizing two modes are useful: the minimum sizing that assigns the
>> size required to display all content and the maximum sizing that
>> expands the widget as much as possible. If width = 100% means that any
>> siblings are not displayed because the widget occupies exactly the
>> available space then a different notation would be useful for taking a
>> share of the available width.
>>
>
> Yep, I have plans for the min_width/min_height/max_width/max_height property.

That's probably not the thing I had in mind. Well, perhaps setting
max_width to 100% would do what width=* in HTML.

>
>>>
>>> vmargin, hmargin is the distance between horizontal and vertical
>>> border, positive value is from left/top, while negative value is from
>>> right/bottom, for example:
>>>
>>> panel
>>> {
>>>  vmargin = -0
>>>  hmargin = -0
>>> }
>>>
>>> places the panel in the bottom right corner.
>>
>> How does this resolve the problem of setting the top, left, bottom and
>> right margin without knowing the size (width, height) of the panel?
>>
>> I know that when panel is drawn the size is known but the size might
>> not be known when the configuration is written (different screen sizes
>> or label lengths). Setting the size (width, height) might be
>> appropriate in some cases but in most it should be calculated
>> automatically so that the layout fits in the available space.
>>
>
> It'd work as expected, you can see it by setting the width/height of
> the last panel to 28%/28%, it'd still stick to the border. The program
> do this in two steps, first the size, then the position, it allows to
> the widget to change the size before position is calculated.

I don't want to set the size of anything, ever. There still should be
a way to get borders into the layout.
>
>> I might want a bit of space (like 0.5 em or 0.5c) around a label so
>> that the label text is not sticking to the border as it was in the
>> last demo.
>
> You can do this with vspace/hspace. The last panel looks compact as it
> does specify width/height so that the minimum required size is used.
>
>>
>> If I have a background picture over which I want to draw the menu and
>> it has a designated area for this I can either measure the menu
>> position as x,y,width, height or as top, left, bottom, right. The
>> latter has the advantage that if I decide to allow scaling the picture
>> I can measure the margin in % and the rounding error for each border
>> is the same. For x,y,width,height the rounding error of the bottom
>> corner is twice as large.
>>
>> In the general case I would want to avoid the menu sticking to the
>> border of the screen which again calls for a margin.
>>
>
> Actually, when vmargin and hmargin is positive number, it's exactly
> the same as x,y, but it also allows to stick to other borders, which

By stick to the border I mean the ugly situation when the element
content touches the border visually blending with it.

> is impossible for x,y without setting the size.

AFAIK it's still impossible to make a panel with the same distance
from each border of the screen without setting its size manually.

All my attempts failed miserably.

The other problem is that the text is not shown for some reason in the
demo with Debian/Ubuntu/Gentoo and the blue squares are still shown in
text mode.

>
>>>
>>> Here is a sample config file that shows different valign/halign
>>> combination, the image file is inside the previous menu.zip.
>>>
>>> screen
>>> {
>>>  halign = "center"
>>>  valign = "center"
>>>  columns = 3
>>
>> This is not nice because when you add a new panel it wraps to the next
>> row. For most uses grouping panels in a single direction seems more
>> useful. When they have some logical order that order is preserved when
>> a new panel is added.
>>
>
> For single row, set
> columns = 0
>
> For single column, set:
> columns = 1
>

These look sensible except 0 meaning infinite is somewhat needlessly confusing.

What's "columns = 3" for other than showing a demo? Which could be
done in other ways, anyway.

There are numerous bugs in the table layout already, and if you go
with tables there's going to be no end of them.

The table has no colspan/rowspan which people will likely expect of tables.

The last cell that has hmargin/vmargin is ignored by the table layout
to the point that it can overlap other cells.

The cells in the last row are aligned differently than the above cells
because the number of cells considered for the table layout is not
divisible by the number of columns.

hspace/vspace is ignored when the valign/halign is center.

Last but not least tables which are a packing of elements modulo
number of columns are fundamentally broken way of rendering a set of
elements. A table is called for when you have elements that are sorted
into a two dimensional space of indices. Then you can find a
particular element by finding its row and column index. We don't have
that kind of data in Grub.

It is completely feasible to have multiple one-dimensional lists side
by side or one below another.

For example a row of bootloader icons and a row of tool icons. There
is no relationship between the elements in the two lists so there is
no problem with the lists scrolling independently. When a new
bootloader is added the tools are not affected.

Similarly you can have a list of Debian kernels in one column and a
list of Gentoo kernels in another. Again they are independent of each
other. Adding a Debian kernel should not affect Gentoo kernels nor the
other way around so this is not a table.

Even HTML does not have a mod N table. It has TR and TD. Managing a
mod N table in a sensible way is a nightmare. When you actually have a
table then you have to make sure you add a row at a time and pad with
empty cells to preserve the columns. When you have a one-dimensional
list adding to the middle of the list reflows all the later elements
so it is not obvious what was changed and where. Adding kernels to the
top as is customary reflows all elements in a mod N list so finding
any earlier kernel is difficult, it changes position all the time.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

Hello

I tried looking at the overflow but i seriously have no idea what are
all these regions the gfx_region_update_* gets.

There is some scn_x and scn_y but these do not seem to be the screen
coordinates of the region.

If I could tell for what region I am doing the update (that is the
x,y,width,height of the region in screen coordinates) I could set the
viewport accordingly so that the content does not overflow.

At the very least the patch replicates the same breakage in much fewer
lines of code.

Thanks

Michal

[-- Attachment #2: menu-viewport.patch --]
[-- Type: text/x-diff, Size: 3846 bytes --]

diff --git a/menu/gfx_region.c b/menu/gfx_region.c
index 8812da7..39dcc1d 100644
--- a/menu/gfx_region.c
+++ b/menu/gfx_region.c
@@ -27,8 +27,8 @@
 
 #define DEFAULT_VIDEO_MODE "auto"
 
-static int screen_width;
-static int screen_height;
+static unsigned screen_width;
+static unsigned screen_height;
 
 static grub_err_t
 grub_gfx_region_init (void)
@@ -36,6 +36,7 @@ grub_gfx_region_init (void)
   const char *modevar;
   struct grub_video_mode_info mode_info;
   grub_err_t err;
+  unsigned size = -1; /*FIXME int_max? */
 
   modevar = grub_env_get ("gfxmode");
   if (! modevar || *modevar == 0)
@@ -61,8 +62,8 @@ grub_gfx_region_init (void)
   if (err)
     return err;
 
-  screen_width = mode_info.width;
-  screen_height = mode_info.height;
+  grub_video_set_viewport(0, 0, size, size); /* Set maximum viewport. */
+  grub_video_get_viewport(&size, &size, &screen_width, &screen_height);
 
   return grub_errno;
 }
@@ -140,7 +141,8 @@ static void
 grub_gfx_region_update_rect (struct grub_menu_region_rect *rect,
 			     int width, int height, int scn_x, int scn_y)
 {
-  grub_video_fill_rect (rect->color, scn_x, scn_y, width, height);
+  grub_video_set_viewport(scn_x, scn_y, width, height);
+  grub_video_fill_rect (rect->color, 0, 0, width, height);
 }
 
 static void
@@ -148,60 +150,11 @@ grub_gfx_region_update_text (struct grub_menu_region_text *text,
 			     int x, int y, int width, int height,
 			     int scn_x, int scn_y)
 {
-  int left_x, base_y;
-  grub_uint32_t code;
-  const grub_uint8_t *ptr;
-  struct grub_video_bitmap glyph_bitmap;
-
-  scn_x -= x;
-  scn_y -= y;
-
-  glyph_bitmap.mode_info.mode_type =
-    (1 << GRUB_VIDEO_MODE_TYPE_DEPTH_POS)
-    | GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP;
-  glyph_bitmap.mode_info.blit_format = GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED;
-  glyph_bitmap.mode_info.bpp = 1;
-  glyph_bitmap.mode_info.bytes_per_pixel = 0;
-  glyph_bitmap.mode_info.number_of_colors = 2;
-  glyph_bitmap.mode_info.bg_red = 0;
-  glyph_bitmap.mode_info.bg_green = 0;
-  glyph_bitmap.mode_info.bg_blue = 0;
-  glyph_bitmap.mode_info.bg_alpha = 0;
-  grub_video_unmap_color(text->color,
-			 &glyph_bitmap.mode_info.fg_red,
-			 &glyph_bitmap.mode_info.fg_green,
-			 &glyph_bitmap.mode_info.fg_blue,
-			 &glyph_bitmap.mode_info.fg_alpha);
+  int base_y;
+  grub_video_set_viewport(scn_x, scn_y, width, height);
 
   base_y = grub_font_get_ascent (text->font);
-  for (ptr = (const grub_uint8_t *) text->text, left_x = 0;
-       grub_utf8_to_ucs4 (&code, 1, ptr, -1, &ptr) > 0; )
-    {
-      struct grub_font_glyph *glyph;
-      int x1, y1, w1, h1, ox, oy;
-
-      glyph = grub_font_get_glyph_with_fallback (text->font, code);
-      x1 = left_x + glyph->offset_x;
-      y1 = base_y - glyph->offset_y - glyph->height;
-      ox = x1;
-      oy = y1;
-      w1 = glyph->width;
-      h1 = glyph->height;
-
-      if (grub_menu_region_check_rect (&x1, &y1, &w1, &h1,
-				       x, y, width, height))
-	{
-	  glyph_bitmap.mode_info.pitch = glyph->width;
-	  glyph_bitmap.mode_info.width = glyph->width;
-	  glyph_bitmap.mode_info.height = glyph->height;
-	  glyph_bitmap.data = glyph->bitmap;
-	  grub_video_blit_bitmap (&glyph_bitmap, GRUB_VIDEO_BLIT_BLEND,
-				  scn_x + x1, scn_y + y1,
-				  x1 - ox, y1 - oy, w1, h1);
-	}
-
-      left_x += glyph->device_width;
-    }
+  grub_font_draw_string(text->text, text->font, text->color, -x, -y + base_y);
 }
 
 static void
@@ -209,8 +162,9 @@ grub_gfx_region_update_bitmap (struct grub_menu_region_bitmap *bitmap,
 			       int x, int y, int width, int height,
 			       int scn_x, int scn_y)
 {
+  grub_video_set_viewport(scn_x, scn_y, width, height);
   grub_video_blit_bitmap (bitmap->bitmap, GRUB_VIDEO_BLIT_REPLACE,
-			  scn_x, scn_y, x, y, width, height);
+			  0, 0, x, y, width, height);
 }
 
 static struct grub_menu_region grub_gfx_region =

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Mon, Sep 28, 2009 at 7:01 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> Hello
>
> I tried looking at the overflow but i seriously have no idea what are
> all these regions the gfx_region_update_* gets.
>
> There is some scn_x and scn_y but these do not seem to be the screen
> coordinates of the region.
>
> If I could tell for what region I am doing the update (that is the
> x,y,width,height of the region in screen coordinates) I could set the
> viewport accordingly so that the content does not overflow.
>
> At the very least the patch replicates the same breakage in much fewer
> lines of code.

Hi,

I've tried to use viewport method before, but there seems to be some
bug in video system that the font doesn't drawn at all. I can see the
text when removing grub_video_set_viewport, and the position is
correct.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Mon, Sep 28, 2009 at 4:46 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> Does that mean that now the units are characters in text mode and
> pixels in graphics when specified separately?

Hi,

No, the default unit is still character. In fact, I've removed to "p"
unit that's specific to graphic
mode, now if you want to set pixel size, you need to use the '/'
method like 100/1 (100 pixels in graphic mode, 1 in text mode).

> Also when the vspace is set to 1 instead of 5/0 the text does not fit
> into the panel but is still drawn. The widgets should really use
> viewport for drawing to avoid these overflows. Unfortunately, this is
> probably not available in text mode but it should not be hard to add.

There are viewport function in region, available in graphic and text
mode. I can use it to limit the widget.

>>> For sizing two modes are useful: the minimum sizing that assigns the
>>> size required to display all content and the maximum sizing that
>>> expands the widget as much as possible. If width = 100% means that any
>>> siblings are not displayed because the widget occupies exactly the
>>> available space then a different notation would be useful for taking a
>>> share of the available width.
>>>
>>
>> Yep, I have plans for the min_width/min_height/max_width/max_height property.
>
> That's probably not the thing I had in mind. Well, perhaps setting
> max_width to 100% would do what width=* in HTML.

Currently, if you don't set width/height property, it would assign
minimum size automatically,  width = 100% means it has the same width
as its parent, the child widget would reposition according to that.

> I don't want to set the size of anything, ever. There still should be
> a way to get borders into the layout.

But layout ready has borders, just set the top_left/top/../bottom property.

> By stick to the border I mean the ugly situation when the element
> content touches the border visually blending with it.

My meaning of sticky is that the widget has a constant distance from
one of the border, for example, -1, -1 means it's -1c -1c from the
bottom right corner.

>
>> is impossible for x,y without setting the size.
>
> AFAIK it's still impossible to make a panel with the same distance
> from each border of the screen without setting its size manually.
>
> All my attempts failed miserably.

Doesn't the demo work ? The last panel only sets vmargin and hmargin,
width and height is calculated automatically and it's in the bottom
right corner.

>
> The other problem is that the text is not shown for some reason in the
> demo with Debian/Ubuntu/Gentoo and the blue squares are still shown in
> text mode.

The "title" property has renamed "text", and to remove the blue
square, just change

image = "/menu/ubunti.png,,blue"

to

image = "/menu/ubunti.png"

as the previous one would create a rect if image can't be loaded.

>> For single row, set
>> columns = 0
>>
>> For single column, set:
>> columns = 1
>>
>
> These look sensible except 0 meaning infinite is somewhat needlessly confusing.
>
> What's "columns = 3" for other than showing a demo? Which could be
> done in other ways, anyway.
>
> There are numerous bugs in the table layout already, and if you go
> with tables there's going to be no end of them.
>
> The table has no colspan/rowspan which people will likely expect of tables.
>
> The last cell that has hmargin/vmargin is ignored by the table layout
> to the point that it can overlap other cells.
>
> The cells in the last row are aligned differently than the above cells
> because the number of cells considered for the table layout is not
> divisible by the number of columns.
>
> hspace/vspace is ignored when the valign/halign is center.
>
> Last but not least tables which are a packing of elements modulo
> number of columns are fundamentally broken way of rendering a set of
> elements. A table is called for when you have elements that are sorted
> into a two dimensional space of indices. Then you can find a
> particular element by finding its row and column index. We don't have
> that kind of data in Grub.
>
> It is completely feasible to have multiple one-dimensional lists side
> by side or one below another.
>
> For example a row of bootloader icons and a row of tool icons. There
> is no relationship between the elements in the two lists so there is
> no problem with the lists scrolling independently. When a new
> bootloader is added the tools are not affected.
>
> Similarly you can have a list of Debian kernels in one column and a
> list of Gentoo kernels in another. Again they are independent of each
> other. Adding a Debian kernel should not affect Gentoo kernels nor the
> other way around so this is not a table.
>
> Even HTML does not have a mod N table. It has TR and TD. Managing a
> mod N table in a sensible way is a nightmare. When you actually have a
> table then you have to make sure you add a row at a time and pad with
> empty cells to preserve the columns. When you have a one-dimensional
> list adding to the middle of the list reflows all the later elements
> so it is not obvious what was changed and where. Adding kernels to the
> top as is customary reflows all elements in a mod N list so finding
> any earlier kernel is difficult, it changes position all the time.

In fact, if we combine the code for row and column handling, we have a
generic solution for any columns = N, I don't see why a generic
solution would be worse than a specific one, you can always falls back
to single row or column with N = 0 or 1. If you want to make it more
clear for users, I can add alias direction=horizontal for columns=0,
and direction=vertical for columns = 1.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/28 Bean <bean123ch@gmail.com>:
> On Mon, Sep 28, 2009 at 7:01 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> Hello
>>
>> I tried looking at the overflow but i seriously have no idea what are
>> all these regions the gfx_region_update_* gets.
>>
>> There is some scn_x and scn_y but these do not seem to be the screen
>> coordinates of the region.
>>
>> If I could tell for what region I am doing the update (that is the
>> x,y,width,height of the region in screen coordinates) I could set the
>> viewport accordingly so that the content does not overflow.
>>
>> At the very least the patch replicates the same breakage in much fewer
>> lines of code.
>
> Hi,
>
> I've tried to use viewport method before, but there seems to be some
> bug in video system that the font doesn't drawn at all. I can see the
> text when removing grub_video_set_viewport, and the position is
> correct.

This patch has identical rendering of the sample so the text does
render, and reduces code size and code duplication.

If bitmaps/backgrounds render but text does not then it's likely a
problem with the code that sets the region. All text/bitmap/fillrect
should  use the same clipping method (unfortunately, there is no
single clipping function and the code is duplicated so I cannot be
sure). If there is a real problem with clipping of text then it should
be fixed in fb.


Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/28 Bean <bean123ch@gmail.com>:
> On Mon, Sep 28, 2009 at 4:46 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> Does that mean that now the units are characters in text mode and
>> pixels in graphics when specified separately?
>
> Hi,
>
> No, the default unit is still character. In fact, I've removed to "p"
> unit that's specific to graphic
> mode, now if you want to set pixel size, you need to use the '/'
> method like 100/1 (100 pixels in graphic mode, 1 in text mode).

That sounds reasonable.

>
>> Also when the vspace is set to 1 instead of 5/0 the text does not fit
>> into the panel but is still drawn. The widgets should really use
>> viewport for drawing to avoid these overflows. Unfortunately, this is
>> probably not available in text mode but it should not be hard to add.
>
> There are viewport function in region, available in graphic and text
> mode. I can use it to limit the widget.

No need for another viewport, we have one in video/fb already.

>
>>>> For sizing two modes are useful: the minimum sizing that assigns the
>>>> size required to display all content and the maximum sizing that
>>>> expands the widget as much as possible. If width = 100% means that any
>>>> siblings are not displayed because the widget occupies exactly the
>>>> available space then a different notation would be useful for taking a
>>>> share of the available width.
>>>>
>>>
>>> Yep, I have plans for the min_width/min_height/max_width/max_height property.
>>
>> That's probably not the thing I had in mind. Well, perhaps setting
>> max_width to 100% would do what width=* in HTML.
>
> Currently, if you don't set width/height property, it would assign
> minimum size automatically,  width = 100% means it has the same width
> as its parent, the child widget would reposition according to that.
>
>> I don't want to set the size of anything, ever. There still should be
>> a way to get borders into the layout.
>
> But layout ready has borders, just set the top_left/top/../bottom property.

OK, so please consider a one pixel border around a widget (it would be
nice if this was available without supplying a bitmap but you can
simulate it by creating a 1x1px bitmap in the widget foreground color
and supplying it to all of top_left/top/../bottom properties).

This layout sucks because there is no space around the border. If you
look at any newspaper, magazine, word processor, whatever has text
with borders you can see that the borders are used to separate
specific piece of text and there is always space on each side of the
border larger than the spacing of the font. The letters aren't glued
to the border because the border is used to separate two pieces of
text, not glue them together.


>
>> By stick to the border I mean the ugly situation when the element
>> content touches the border visually blending with it.
>
> My meaning of sticky is that the widget has a constant distance from
> one of the border, for example, -1, -1 means it's -1c -1c from the
> bottom right corner.
>
>>
>>> is impossible for x,y without setting the size.
>>
>> AFAIK it's still impossible to make a panel with the same distance
>> from each border of the screen without setting its size manually.
>>
>> All my attempts failed miserably.
>
> Doesn't the demo work ? The last panel only sets vmargin and hmargin,
> width and height is calculated automatically and it's in the bottom
> right corner.

I want the panel to be in all corners at once, with a uniform space
between the edge of the screen and the panel. I want the same mechanic
to be usable when I want non-uniform space such as when fitting the
panel to a background bitmap.

>
>>
>> The other problem is that the text is not shown for some reason in the
>> demo with Debian/Ubuntu/Gentoo and the blue squares are still shown in
>> text mode.
>
> The "title" property has renamed "text", and to remove the blue
> square, just change
>
> image = "/menu/ubunti.png,,blue"
>
> to
>
> image = "/menu/ubunti.png"
>
> as the previous one would create a rect if image can't be loaded.

How does it determine the size of the rect if the image is not loaded?
Shouldn't it be 0x0?

>
>>> For single row, set
>>> columns = 0
>>>
>>> For single column, set:
>>> columns = 1
>>>
>>
>> These look sensible except 0 meaning infinite is somewhat needlessly confusing.
>>
>> What's "columns = 3" for other than showing a demo? Which could be
>> done in other ways, anyway.
>>
>> There are numerous bugs in the table layout already, and if you go
>> with tables there's going to be no end of them.
>>
>> The table has no colspan/rowspan which people will likely expect of tables.
>>
>> The last cell that has hmargin/vmargin is ignored by the table layout
>> to the point that it can overlap other cells.
>>
>> The cells in the last row are aligned differently than the above cells
>> because the number of cells considered for the table layout is not
>> divisible by the number of columns.
>>
>> hspace/vspace is ignored when the valign/halign is center.
>>
>> Last but not least tables which are a packing of elements modulo
>> number of columns are fundamentally broken way of rendering a set of
>> elements. A table is called for when you have elements that are sorted
>> into a two dimensional space of indices. Then you can find a
>> particular element by finding its row and column index. We don't have
>> that kind of data in Grub.
>>
>> It is completely feasible to have multiple one-dimensional lists side
>> by side or one below another.
>>
>> For example a row of bootloader icons and a row of tool icons. There
>> is no relationship between the elements in the two lists so there is
>> no problem with the lists scrolling independently. When a new
>> bootloader is added the tools are not affected.
>>
>> Similarly you can have a list of Debian kernels in one column and a
>> list of Gentoo kernels in another. Again they are independent of each
>> other. Adding a Debian kernel should not affect Gentoo kernels nor the
>> other way around so this is not a table.
>>
>> Even HTML does not have a mod N table. It has TR and TD. Managing a
>> mod N table in a sensible way is a nightmare. When you actually have a
>> table then you have to make sure you add a row at a time and pad with
>> empty cells to preserve the columns. When you have a one-dimensional
>> list adding to the middle of the list reflows all the later elements
>> so it is not obvious what was changed and where. Adding kernels to the
>> top as is customary reflows all elements in a mod N list so finding
>> any earlier kernel is difficult, it changes position all the time.
>
> In fact, if we combine the code for row and column handling, we have a
> generic solution for any columns = N, I don't see why a generic
> solution would be worse than a specific one, you can always falls back
> to single row or column with N = 0 or 1. If you want to make it more
> clear for users, I can add alias direction=horizontal for columns=0,
> and direction=vertical for columns = 1.

Because the generic case creates only poor layouts and adds needless
complexity to the solution.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Mon, Sep 28, 2009 at 5:47 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> There are viewport function in region, available in graphic and text
>> mode. I can use it to limit the widget.
>
> No need for another viewport, we have one in video/fb already.

But that only works in graphic mode, it we want the ui to be portable
between text and graphic mode, we need to use region function.

> OK, so please consider a one pixel border around a widget (it would be
> nice if this was available without supplying a bitmap but you can
> simulate it by creating a 1x1px bitmap in the widget foreground color
> and supplying it to all of top_left/top/../bottom properties).
>
> This layout sucks because there is no space around the border. If you
> look at any newspaper, magazine, word processor, whatever has text
> with borders you can see that the borders are used to separate
> specific piece of text and there is always space on each side of the
> border larger than the spacing of the font. The letters aren't glued
> to the border because the border is used to separate two pieces of
> text, not glue them together.

I can add border_width/border_height/border_color property that draw a
extra rect around the top/left/bottom/right bitmap.

> I want the panel to be in all corners at once, with a uniform space
> between the edge of the screen and the panel. I want the same mechanic
> to be usable when I want non-uniform space such as when fitting the
> panel to a background bitmap.

I see, that can be archived, we can use negative value of width/height
to indicate subtraction from parent's width/height, perhaps something
like this:

panel
{
  vmargin = 2
  hmargin = 2
  width = -4
  height = -4
}

This leaves a 2 character size at the borders.

> How does it determine the size of the rect if the image is not loaded?
> Shouldn't it be 0x0?

Actually the size of rect is 1c x 1c. This is used for
top/left/bottom/right bitmap property. In graphic mode, it loads the
bitmap, in text mode, it replace it with a 1 x N rect box with ascii
fill character.

> Because the generic case creates only poor layouts and adds needless
> complexity to the solution.

Some uses for columns:

Dialog boxes. For example, in password input, we have widget label
Name, edit box, label Password, edit box, etc. We can wrap a panel
around each pair, but setting columns = 2 is easier.

If we use a background image like this:

http://www.kde-look.org/content/preview.php?preview=1&id=76173&file1=76173-1.png&file2=76173-2.png&file3=76173-3.png&name=Gentoo+GFXboot+Theme+Set

The menu is limited to a small box. If we use icons to represent boot
items, then only a few icons can be shown in single row/single column
setup. Using columns can maximize space usage, it also has the
iphone's look and feel.


-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/28 Bean <bean123ch@gmail.com>:
> On Mon, Sep 28, 2009 at 5:47 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> There are viewport function in region, available in graphic and text
>>> mode. I can use it to limit the widget.
>>
>> No need for another viewport, we have one in video/fb already.
>
> But that only works in graphic mode, it we want the ui to be portable
> between text and graphic mode, we need to use region function.

Or implement a viewport for text which can be undoubtedly used outside of menu.
>
>> OK, so please consider a one pixel border around a widget (it would be
>> nice if this was available without supplying a bitmap but you can
>> simulate it by creating a 1x1px bitmap in the widget foreground color
>> and supplying it to all of top_left/top/../bottom properties).
>>
>> This layout sucks because there is no space around the border. If you
>> look at any newspaper, magazine, word processor, whatever has text
>> with borders you can see that the borders are used to separate
>> specific piece of text and there is always space on each side of the
>> border larger than the spacing of the font. The letters aren't glued
>> to the border because the border is used to separate two pieces of
>> text, not glue them together.
>
> I can add border_width/border_height/border_color property that draw a
> extra rect around the top/left/bottom/right bitmap.
>
>> I want the panel to be in all corners at once, with a uniform space
>> between the edge of the screen and the panel. I want the same mechanic
>> to be usable when I want non-uniform space such as when fitting the
>> panel to a background bitmap.
>
> I see, that can be archived, we can use negative value of width/height
> to indicate subtraction from parent's width/height, perhaps something
> like this:
>
> panel
> {
>  vmargin = 2
>  hmargin = 2
>  width = -4
>  height = -4
> }

OK, and instead of negative width/height and vmargin/hmargin (which
should be actually on both sides anyway) can't we just have margin-to,
margin-bottom, margin-left, margin-right so that the naming and values
make some sense?

>
> This leaves a 2 character size at the borders.
>
>> How does it determine the size of the rect if the image is not loaded?
>> Shouldn't it be 0x0?
>
> Actually the size of rect is 1c x 1c. This is used for
> top/left/bottom/right bitmap property. In graphic mode, it loads the
> bitmap, in text mode, it replace it with a 1 x N rect box with ascii
> fill character.

That's quite odd way of doing this. What we actually have is a rect,
top-left rect, top-rect .. so there's no reason they should be the
same size, and they actually aren't only the corner rects and plain
rect are 1x1, the side rects are 1xN.

Isn't there a more straightforward way of doing this? Perhaps add a
property for borders that can hold a bitmap and a simple style
(single,double), and defaults to single in text if only a bitmap is
specified.

>
>> Because the generic case creates only poor layouts and adds needless
>> complexity to the solution.
>
> Some uses for columns:
>
> Dialog boxes. For example, in password input, we have widget label
> Name, edit box, label Password, edit box, etc. We can wrap a panel
> around each pair, but setting columns = 2 is easier.

Not that much, really. And wrapping a panel around each pair is more
robust, the panel should hold them together even if another element is
added.

>
> If we use a background image like this:
>
> http://www.kde-look.org/content/preview.php?preview=1&id=76173&file1=76173-1.png&file2=76173-2.png&file3=76173-3.png&name=Gentoo+GFXboot+Theme+Set
>
> The menu is limited to a small box. If we use icons to represent boot
> items, then only a few icons can be shown in single row/single column
> setup. Using columns can maximize space usage, it also has the
> iphone's look and feel.

What icons are you going to use for distinguishing boot items? You can
either put very few icons there so they will very well fit a single
row or single column or you have many icons but then they aren't
distinguishing and you can use them at most as bullets for the kernel
list.

This isn't iPhone so there is no use in making grub look like one. You
can't get 20 distinct things you can do with grub so you can't have 20
(4x5) functional icons. You can add dummy icons in your theme if you
insist.

And I'm sure that even on an iPhone if you enter an application that
shows ie your bookmarks or playlist it does not show the entries as
icon view but as plaintext list, otherwise you could not tell what is
what.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Change the region structure, remove region tree as it's duplicate with
similar function of widget.
Change layout manger, only allow one dimension (direction = horizontal
or vertical).
Add margin_top, margin_left, margin_right, margin_bottom,
border_width, border_height, border_color property for panel
Create transparent panel when background is null.
Remove label widget, adds image and text widget, as the layout
function of label is duplicate with panel.
Add selected state. You can specify the normal mode and selected mode
bitmap with something like this:

top_left = "/menu/menu_tl.png,,black/cyan,#0x250F:/menu/select_tl.png,,black/green,/"

Likewise, to set normal mode and selected mode color:

color = "yellow:light-green"

: is used to separate the two parts.

The demo first shows normal state, then selected state, then return.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/9/30 Bean <bean123ch@gmail.com>:
> Hi,
>
> Update:
>
> Change the region structure, remove region tree as it's duplicate with
> similar function of widget.
> Change layout manger, only allow one dimension (direction = horizontal
> or vertical).
> Add margin_top, margin_left, margin_right, margin_bottom,
> border_width, border_height, border_color property for panel

With these its should be quite easy to put together some nice designs
(or at least ones that hint at the nice designs that would be
possible).

Unfortunately it seems I will have less time for playing with this now.

> Create transparent panel when background is null.

It's nice that a transparent bitmap is not required for that.

> Remove label widget, adds image and text widget, as the layout
> function of label is duplicate with panel.

It is not. A label can have focus (the whole icon+text widget) but panel cannot.

It will be impossible to make both focused at once without special trickery.

> Add selected state. You can specify the normal mode and selected mode
> bitmap with something like this:
>
> top_left = "/menu/menu_tl.png,,black/cyan,#0x250F:/menu/select_tl.png,,black/green,/"
>
> Likewise, to set normal mode and selected mode color:
>
> color = "yellow:light-green"
>
> : is used to separate the two parts.
>
> The demo first shows normal state, then selected state, then return.

I finally found utility in the screen widget. While panels should
enforce that their content is not overlapped and is nicely and orderly
aligned it should be possible to place panels or labels freely in the
screen widget so that they can be positioned over particular places of
a bitmap if desired.

I hoped it would be possible to create custom layouts in lua but it's
not necessary to use scripting in most cases and it's moved out of
grub core now. Still I would want to see some way that would allow for
creating arced panels or the like, eventually.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Oct 1, 2009 at 7:21 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> It is not. A label can have focus (the whole icon+text widget) but panel cannot.
>
> It will be impossible to make both focused at once without special trickery.

Hi,

It's possible to make both focused, actually my next demo would be to
illustrate the menu interaction. The basic unit is panel, we can add
"input" or "select" property to panel so that it can have input focus
or can be selected, something like this:

  panel {
    direction = vertical
    space = 10/1
    input = 1

    panel {
      direction = horizontal
      space = 10/1
      command = ""

      image {
        image = "/menu/ubuntu.png"
      }

      text {
        text = "Ubuntu"
        color = "yellow:light-green"
      }
    }

    panel {
      direction = horizontal
      space = 10/1
      command = ""

      image {
        image = "/menu/debian.png"
      }

      text {
        text = "Debian"
        color = "yellow:light-green"
      }
    }

    panel {
      direction = horizontal
      space = 10/1
      command = ""

      image {
        image = "/menu/gentoo.png"
      }

      text {
        text = "Gentoo"
        color = "yellow:light-green"
      }
    }
  }

There are two level interaction, "input" is used to indicate "window",
we use tab key to switch between different window. "command" is used
to indicate "item", each window can have multiple items, we use up or
down key to navigate between items. The command property also contains
the  command to execute when the item is clicked.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/1 Bean <bean123ch@gmail.com>:
> On Thu, Oct 1, 2009 at 7:21 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> It is not. A label can have focus (the whole icon+text widget) but panel cannot.
>>
>> It will be impossible to make both focused at once without special trickery.
>
> Hi,
>
> It's possible to make both focused, actually my next demo would be to
> illustrate the menu interaction. The basic unit is panel, we can add
> "input" or "select" property to panel so that it can have input focus
> or can be selected, something like this:
>
>  panel {
>    direction = vertical
>    space = 10/1
>    input = 1
>
>    panel {
>      direction = horizontal
>      space = 10/1
>      command = ""
>
>      image {
>        image = "/menu/ubuntu.png"
>      }
>
>      text {
>        text = "Ubuntu"
>        color = "yellow:light-green"
>      }
>    }
>
>    panel {
>      direction = horizontal
>      space = 10/1
>      command = ""
>
>      image {
>        image = "/menu/debian.png"
>      }
>
>      text {
>        text = "Debian"
>        color = "yellow:light-green"
>      }
>    }
>
>    panel {
>      direction = horizontal
>      space = 10/1
>      command = ""
>
>      image {
>        image = "/menu/gentoo.png"
>      }
>
>      text {
>        text = "Gentoo"
>        color = "yellow:light-green"
>      }
>    }
>  }
>

This sounds good. It gives more flexibility in designing the active items.

> There are two level interaction, "input" is used to indicate "window",

Cannot this be inferred automatically?

That is any panel that contains command items is a window.

> we use tab key to switch between different window. "command" is used
> to indicate "item", each window can have multiple items, we use up or
> down key to navigate between items. The command property also contains
> the  command to execute when the item is clicked.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Oct 1, 2009 at 4:41 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> Cannot this be inferred automatically?
>
> That is any panel that contains command items is a window.

Hi,

Sometimes panel can be used to ground some widgets together, for
example, a dialog may look like this:

panel
{
  direction = vertical
  input = 1

  panel
  {
    direction = horizontal
    text { text="username"}
    edit {}
  }

  panel
  {
    direction = horizontal
    text { text="password"}
    edit {}
  }
}

In this case, the outer panel should be a single window, and the edits
are items. The inner panel is only used for layout, we don't want them
to receive input focus.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

New properties for the layout manager:

The previous version uses the simplified align and space property, but
this is not enough for complete control, now it goes back to the
previous four property valign, halign, vspace and hspace.

Add extend property, if the children have different width/height, the
menu looks a little awkward. When extend property is set, the
width/height of children is the maximum value.

Add min_width/max_width/min_height/max_height, it's used to limit the
width/height calculated from children widgets. Width/Height set
directly using property is not affected by these.

When some of the margin property are not set, it's position is
controlled by the parent alignment properties, for example, we can
generate a OSX like dock with something like this:

screen {
halign = center

  panel {
    background = ",,blue,#32:,,green,#32"
    direction = left_to_right
    margin_bottom = 0
    hspace = 10/0
    vspace = 10/0

    image {
      image = "/menu/ubuntu.png"
    }

    image {
      image = "/menu/debian.png"
    }

    image {
      image = "/menu/gentoo.png"
    }
  }
}

As panel only sets margin_bottom, it's x coordination can be set by screen.

Now support four direction: left_to_right, right_to_left,
top_to_bottom and bottom_to_top.

The layout control function is moved from coreui.c to widget.c, now
all container widget would inherit the layout manager automatically.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

BTW, I've fixed a small problem as indicated bty pxwpxw from ubuntu
forum. Previously to test Colin's patch, I enable double buffer
support for EFI, but now it's not needed anymore. The latest menu
branch disable double buffer for EFI.

The demo should be working on EFI now, I add menu_efi.cfg in the resource file:

http://grub4dos.sourceforge.net/menu.zip

The following modules should be added when generating grub.efi:
coreui loadcfg menutest gfxmenu textmenu

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/1 Bean <bean123ch@gmail.com>:
> On Thu, Oct 1, 2009 at 4:41 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> Cannot this be inferred automatically?
>>
>> That is any panel that contains command items is a window.
>
> Hi,
>
> Sometimes panel can be used to ground some widgets together, for
> example, a dialog may look like this:
>
> panel
> {
>  direction = vertical
>  input = 1
>
>  panel
>  {
>    direction = horizontal
>    text { text="username"}
>    edit {}
>  }
>
>  panel
>  {
>    direction = horizontal
>    text { text="password"}
>    edit {}
>  }
> }
>
> In this case, the outer panel should be a single window, and the edits
> are items. The inner panel is only used for layout, we don't want them
> to receive input focus.

Since the panel only contains one active item ( the edit ) this should
still work.

I recall writing about this here already.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Oct 1, 2009 at 8:44 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/1 Bean <bean123ch@gmail.com>:
>> On Thu, Oct 1, 2009 at 4:41 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> Cannot this be inferred automatically?
>>>
>>> That is any panel that contains command items is a window.
>>
>> Hi,
>>
>> Sometimes panel can be used to ground some widgets together, for
>> example, a dialog may look like this:
>>
>> panel
>> {
>>  direction = vertical
>>  input = 1
>>
>>  panel
>>  {
>>    direction = horizontal
>>    text { text="username"}
>>    edit {}
>>  }
>>
>>  panel
>>  {
>>    direction = horizontal
>>    text { text="password"}
>>    edit {}
>>  }
>> }
>>
>> In this case, the outer panel should be a single window, and the edits
>> are items. The inner panel is only used for layout, we don't want them
>> to receive input focus.
>
> Since the panel only contains one active item ( the edit ) this should
> still work.
>
> I recall writing about this here already.

Hi,

It'd be ok if we only have one level input items, but I plans to add
two two level interaction, first is window, second is item, TAB switch
different window, while UP/DOWN switch different items. In this setup,
we need to mark the panel that acted as window.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/1 Bean <bean123ch@gmail.com>:
> On Thu, Oct 1, 2009 at 8:44 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/1 Bean <bean123ch@gmail.com>:
>>> On Thu, Oct 1, 2009 at 4:41 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> Cannot this be inferred automatically?
>>>>
>>>> That is any panel that contains command items is a window.
>>>
>>> Hi,
>>>
>>> Sometimes panel can be used to ground some widgets together, for
>>> example, a dialog may look like this:
>>>
>>> panel
>>> {
>>> ádirection = vertical
>>> áinput = 1
>>>
>>> ápanel
>>> á{
>>> á ádirection = horizontal
>>> á átext { text="username"}
>>> á áedit {}
>>> á}
>>>
>>> ápanel
>>> á{
>>> á ádirection = horizontal
>>> á átext { text="password"}
>>> á áedit {}
>>> á}
>>> }
>>>
>>> In this case, the outer panel should be a single window, and the edits
>>> are items. The inner panel is only used for layout, we don't want them
>>> to receive input focus.
>>
>> Since the panel only contains one active item ( the edit ) this should
>> still work.
>>
>> I recall writing about this here already.
>
> Hi,
>
> It'd be ok if we only have one level input items, but I plans to add
> two two level interaction, first is window, second is item, TAB switch
> different window, while UP/DOWN switch different items. In this setup,
> we need to mark the panel that acted as window.
>

Yes, there's no problem inferring the interaction from the widget tree.

Widgets that don't do anything don't get focus, they are ignored for
purpose of determining focus.

An active item like edit or panel with command is an atomic widget for
focus. A panel that contains exactly one atomic widget is also atomic.

A panel that contains multiple atomic items (or alternatively in which
atomic item is focused) acts on directional keys by switching focus to
next item - this seems what window = 1 does.

A panel that contains multiple panels that can focus but are not
atomic handles (Shift +)TAB by switching to the (previous) next
contained panel. In case the focused panel is its (first) last
focusable item it passes the key to the upper panel.

As an extension the panel direction can be taken into account, and
panels can be seen as atomic in both directions (atomic) atomic in
vertical direction (horizontal panel containing atomic widgets), ...

This can work completely automagically without user setup and thus can
eliminate errors in the setup.

It perhaps might be useful to override the default in some cases but
this should work for any menu I would want to put together.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Oct 1, 2009 at 10:53 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/1 Bean <bean123ch@gmail.com>:
>> On Thu, Oct 1, 2009 at 8:44 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> 2009/10/1 Bean <bean123ch@gmail.com>:
>>>> On Thu, Oct 1, 2009 at 4:41 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>> Cannot this be inferred automatically?
>>>>>
>>>>> That is any panel that contains command items is a window.
>>>>
>>>> Hi,
>>>>
>>>> Sometimes panel can be used to ground some widgets together, for
>>>> example, a dialog may look like this:
>>>>
>>>> panel
>>>> {
>>>> ádirection = vertical
>>>> áinput = 1
>>>>
>>>> ápanel
>>>> á{
>>>> á ádirection = horizontal
>>>> á átext { text="username"}
>>>> á áedit {}
>>>> á}
>>>>
>>>> ápanel
>>>> á{
>>>> á ádirection = horizontal
>>>> á átext { text="password"}
>>>> á áedit {}
>>>> á}
>>>> }
>>>>
>>>> In this case, the outer panel should be a single window, and the edits
>>>> are items. The inner panel is only used for layout, we don't want them
>>>> to receive input focus.
>>>
>>> Since the panel only contains one active item ( the edit ) this should
>>> still work.
>>>
>>> I recall writing about this here already.
>>
>> Hi,
>>
>> It'd be ok if we only have one level input items, but I plans to add
>> two two level interaction, first is window, second is item, TAB switch
>> different window, while UP/DOWN switch different items. In this setup,
>> we need to mark the panel that acted as window.
>>
>
> Yes, there's no problem inferring the interaction from the widget tree.
>
> Widgets that don't do anything don't get focus, they are ignored for
> purpose of determining focus.
>
> An active item like edit or panel with command is an atomic widget for
> focus. A panel that contains exactly one atomic widget is also atomic.
>
> A panel that contains multiple atomic items (or alternatively in which
> atomic item is focused) acts on directional keys by switching focus to
> next item - this seems what window = 1 does.
>
> A panel that contains multiple panels that can focus but are not
> atomic handles (Shift +)TAB by switching to the (previous) next
> contained panel. In case the focused panel is its (first) last
> focusable item it passes the key to the upper panel.
>
> As an extension the panel direction can be taken into account, and
> panels can be seen as atomic in both directions (atomic) atomic in
> vertical direction (horizontal panel containing atomic widgets), ...
>
> This can work completely automagically without user setup and thus can
> eliminate errors in the setup.
>
> It perhaps might be useful to override the default in some cases but
> this should work for any menu I would want to put together.

Hi,

The window = 1 is used to group some input items together, for example:

screen {
  panel {   # A
    window = 1
    panel { }  #A1
    panel { }  #A2
  }

  panel { # B
    window = 1
    panel { } #B1
    panel { } #B2
  }
}

This define two menus, each with two items. Each menu remember its
current selection, for example, if panel A select a language, panel B
select theme, both can have current selection at the same time. You
can walk from A to B as they represent two different things.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Add input handler, now you can walk the widget tree with keys.

New properties:

command
If command is set, the widget is selectable

anchor
This is used to group widgets together, next and previous key can't
escape the current anchor.

For example, if there are two menus, what would happen if you use the
previous key on the first item:

1. wrap to the last item on this menu
2, jump to the next menu

I use the anchor property to distinguish the two situation

If anchor is set for the parent panel, previous key can't escape the
current menu, so it wrap to the last item
If anchor is not set, jump to the next menu

anchor also define a scope for the current node, this is useful when
define onkey handlers:

screen - anchor - node

In screen, we set global key binding, for example, F1, etc
In anchor, we set local key binding, for example, c and e for the menu widget.
We can also define specific key handler for each node.

The demo supports the following keys:

n: jump to next item from the current anchor
p: jump to previous item from the current anchor
N: jump to next item in another anchor
P: jump to previous item in another anchor
ESC: exit from the demo

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/1 Bean <bean123ch@gmail.com>:
> On Thu, Oct 1, 2009 at 10:53 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/1 Bean <bean123ch@gmail.com>:
>>> On Thu, Oct 1, 2009 at 8:44 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> 2009/10/1 Bean <bean123ch@gmail.com>:
>>>>> On Thu, Oct 1, 2009 at 4:41 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>>> Cannot this be inferred automatically?
>>>>>>
>>>>>> That is any panel that contains command items is a window.
>>>>>
>>>>> Hi,
>>>>>
>>>>> Sometimes panel can be used to ground some widgets together, for
>>>>> example, a dialog may look like this:
>>>>>
>>>>> panel
>>>>> {
>>>>> ádirection = vertical
>>>>> áinput = 1
>>>>>
>>>>> ápanel
>>>>> á{
>>>>> á ádirection = horizontal
>>>>> á átext { text="username"}
>>>>> á áedit {}
>>>>> á}
>>>>>
>>>>> ápanel
>>>>> á{
>>>>> á ádirection = horizontal
>>>>> á átext { text="password"}
>>>>> á áedit {}
>>>>> á}
>>>>> }
>>>>>
>>>>> In this case, the outer panel should be a single window, and the edits
>>>>> are items. The inner panel is only used for layout, we don't want them
>>>>> to receive input focus.
>>>>
>>>> Since the panel only contains one active item ( the edit ) this should
>>>> still work.
>>>>
>>>> I recall writing about this here already.
>>>
>>> Hi,
>>>
>>> It'd be ok if we only have one level input items, but I plans to add
>>> two two level interaction, first is window, second is item, TAB switch
>>> different window, while UP/DOWN switch different items. In this setup,
>>> we need to mark the panel that acted as window.
>>>
>>
>> Yes, there's no problem inferring the interaction from the widget tree.
>>
>> Widgets that don't do anything don't get focus, they are ignored for
>> purpose of determining focus.
>>
>> An active item like edit or panel with command is an atomic widget for
>> focus. A panel that contains exactly one atomic widget is also atomic.
>>
>> A panel that contains multiple atomic items (or alternatively in which
>> atomic item is focused) acts on directional keys by switching focus to
>> next item - this seems what window = 1 does.
>>
>> A panel that contains multiple panels that can focus but are not
>> atomic handles (Shift +)TAB by switching to the (previous) next
>> contained panel. In case the focused panel is its (first) last
>> focusable item it passes the key to the upper panel.
>>
>> As an extension the panel direction can be taken into account, and
>> panels can be seen as atomic in both directions (atomic) atomic in
>> vertical direction (horizontal panel containing atomic widgets), ...
>>
>> This can work completely automagically without user setup and thus can
>> eliminate errors in the setup.
>>
>> It perhaps might be useful to override the default in some cases but
>> this should work for any menu I would want to put together.
>
> Hi,
>
> The window = 1 is used to group some input items together, for example:
>
> screen {
>  panel {   # A
>    window = 1
>    panel { }  #A1
>    panel { }  #A2
>  }
>
>  panel { # B
>    window = 1
>    panel { } #B1
>    panel { } #B2
>  }
> }
>
> This define two menus, each with two items. Each menu remember its
> current selection, for example, if panel A select a language, panel B
> select theme, both can have current selection at the same time. You

Yes, they should both remember their position.

I still don't see any reason why the window = 1 property could not be
set automatically.

> can walk from A to B as they represent two different things.

That's useful, and in case the number of panels is reasonably small so
that you can put them together into a simple layout you could use the
up/down keys to select the item in the panel and left/right to select
the "window" panel.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Add auto scrolling support, view port would be adjusted automatically
to show the current node. In the demo, there are five horizontal
widgets, total length exceed that of the screen, using 'N' and 'P' to
navigating between anchors, and you can see the hidden widget would
scroll into view automatically, ESC to exit the demo.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/3 Bean <bean123ch@gmail.com>:
> Hi,
>
> Update:
>
> Add auto scrolling support, view port would be adjusted automatically
> to show the current node. In the demo, there are five horizontal
> widgets, total length exceed that of the screen, using 'N' and 'P' to
> navigating between anchors, and you can see the hidden widget would
> scroll into view automatically, ESC to exit the demo.
>

Hello,

Do you have an update of the sample configuration for menu test?

The old sample reports "class not found".

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Sun, Oct 4, 2009 at 6:34 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/3 Bean <bean123ch@gmail.com>:
>> Hi,
>>
>> Update:
>>
>> Add auto scrolling support, view port would be adjusted automatically
>> to show the current node. In the demo, there are five horizontal
>> widgets, total length exceed that of the screen, using 'N' and 'P' to
>> navigating between anchors, and you can see the hidden widget would
>> scroll into view automatically, ESC to exit the demo.
>>
>
> Hello,
>
> Do you have an update of the sample configuration for menu test?
>
> The old sample reports "class not found".

Hi,

It's at:

http://grub4dos.sourceforge.net/menu.zip

Download it again and replace the files.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

2009/10/4 Bean <bean123ch@gmail.com>:
> On Sun, Oct 4, 2009 at 6:34 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/3 Bean <bean123ch@gmail.com>:
>>> Hi,
>>>
>>> Update:
>>>
>>> Add auto scrolling support, view port would be adjusted automatically
>>> to show the current node. In the demo, there are five horizontal
>>> widgets, total length exceed that of the screen, using 'N' and 'P' to
>>> navigating between anchors, and you can see the hidden widget would
>>> scroll into view automatically, ESC to exit the demo.
>>>
>>
>> Hello,
>>
>> Do you have an update of the sample configuration for menu test?
>>
>> The old sample reports "class not found".
>
> Hi,
>
> It's at:
>
> http://grub4dos.sourceforge.net/menu.zip
>
> Download it again and replace the files.
>
Hi

I only tried running the sample, did not look how things are done yet.

The major problem is that the panels are not sorted in any way so the
navigation is very confusing. There should be only a single toplevel
panel which contains all active elements in a layout.

However, when I put everything into a single panel I still get issues:

 - the content is not inside the panel border
 - focus is on an invisible element, not the first element
 - panels are not ordered left to right as specified

There is an issue with setting the border and margins.
 - if I set all margins to the same number the horizontal and vertical
margins are different which is quite ugly
 - the border settings offer many options but I miss the option for
   - setting the text border explicitly to single/double border
without using an image
   - replicating similar effect in graphics (that is setting a few
pixel border with some space on either side - margin should set the
outer space but I am not sure about the inner space)
 - background bitmap does not cover margins. I am not sure if it is
desirable to cover them, though. CSS works that way but I am sure some
systems work differently.

Thanks

Michal

[-- Attachment #2: menu.txt --]
[-- Type: text/plain, Size: 10068 bytes --]

screen {
          background = "/menu/back.png,,blue"

    panel {
        direction = left_to_right
          margin_left = 3
          margin_top = 3
          margin_right = 3
          margin_bottom = 3

          top_left = "/menu/menu_tl.png,,black/cyan,#0x250F:/menu/select_tl.png,,black/green,/"
          top = "/menu/menu_t.png,tiling,black/cyan,#0x2501:/menu/select_t.png,,black/green,-"
          top_right = "/menu/menu_tr.png,,black/cyan,#0x2513:/menu/select_tr.png,,black/green,\\"
          left = "/menu/menu_l.png,tiling,black/cyan,#0x2503:/menu/select_l.png,,black/green,|"
          right = "/menu/menu_r.png,tiling,black/cyan,#0x2503:/menu/select_r.png,,black/green,|"
          bottom_left = "/menu/menu_bl.png,,black/cyan,#0x2517:/menu/select_bl.png,,black/green,\\"
          bottom = "/menu/menu_b.png,tiling,black/cyan,#0x2501:/menu/select_b.png,,black/green,-"
          bottom_right = "/menu/menu_br.png,tiling,black/cyan,#0x251B:/menu/select_br.png,,black/green,/"
          border_width = 0/1
          border_height = 0/1
          border_color = "brown:red"

          panel {
              background = ",,brown,#32:,,red,#32"
                direction = left_to_right
                margin_bottom = 0
                hspace = 10/0
                vspace = 10/0
                anchor = 1

                image {
                    image = "/menu/ubuntu_b.png:/menu/ubuntu.png"
                      command = "aa"
                }

              image {
                  image = "/menu/debian_b.png:/menu/debian.png"
                    command = "bb"
              }

              image {
                  image = "/menu/gentoo_b.png:/menu/gentoo.png"
                    command = "cc"
              }
          }

        panel {
            direction = bottom_to_top
              vspace = 10/1
#background = ",,green,#32:,,cyan,#32"
              border_width = 1
              border_height = 1
              border_color = "brown:red"
              extend = 1
              anchor = 1

              panel {
                  direction = left_to_right
                    hspace = 10/1
                    background = ":,,green, "
                    command = "aa"

                    image {
                        image = "/menu/ubuntu.png"
                    }

                  text {
                      text = "Ubuntu"
                        color = "yellow:light-green"
                  }
              }

            panel {
                direction = right_to_left
                  hspace = 10/1
                  valign = center
                  background = ":,,green, "
                  command = "bb"

                  image {
                      image = "/menu/debian.png"
                  }

                text {
                    text = "Debian Lenny"
                      color = "yellow:light-green"
                }
            }

            panel {
                direction = left_to_right
                  hspace = 10/1
                  valign = bottom
                  halign = right
                  background = ":,,green, "
                  command = "cc"

                  image {
                      image = "/menu/gentoo.png"
                  }

                text {
                    text = "Gentoo"
                      color = "yellow:light-green"
                }
            }
        }

        panel {
            direction = bottom_to_top
              vspace = 10/1
#background = ",,green,#32:,,cyan,#32"
              border_width = 1
              border_height = 1
              border_color = "brown:red"
              anchor = 1

              panel {
                  direction = left_to_right
                    hspace = 10/1
                    background = ":,,green, "
                    command = "aa"

                    image {
                        image = "/menu/ubuntu.png"
                    }

                  text {
                      text = "Ubuntu"
                        color = "yellow:light-green"
                  }
              }

            panel {
                direction = right_to_left
                  hspace = 10/1
                  valign = center
                  background = ":,,green, "
                  command = "bb"

                  image {
                      image = "/menu/debian.png"
                  }

                text {
                    text = "Debian Lenny"
                      color = "yellow:light-green"
                }
            }

            panel {
                direction = left_to_right
                  hspace = 10/1
                  valign = bottom
                  halign = right
                  background = ":,,green, "
                  command = "cc"

                  image {
                      image = "/menu/gentoo.png"
                  }

                text {
                    text = "Gentoo"
                      color = "yellow:light-green"
                }
            }
        }

        panel {
            direction = left_to_right
              hspace = 10/1
#background = ",,green,#32:,,cyan,#32"
              border_width = 1
              border_height = 1
              border_color = "brown:red"
              max_width = 25
              min_height = 8
              extend = 1
              anchor = 1

              panel {
                  direction = top_to_bottom
                    vspace = 10/1
                    background = ":,,cyan, "
                    command = "aa"

                    image {
                        image = "/menu/ubuntu.png"
                    }

                  text {
                      text = "Ubuntu"
                        color = "yellow:light-green"
                  }
              }

            panel {
                direction = bottom_to_top
                  vspace = 10/1
                  halign = center
                  background = ":,,cyan, "
                  command = "bb"

                  image {
                      image = "/menu/debian.png"
                  }

                text {
                    text = "Debian Lenny"
                      color = "yellow:light-green"
                }
            }

            panel {
                direction = top_to_bottom
                  vspace = 10/1
                  halign = center
                  background = ":,,cyan, "
                  command = "bb"

                  image {
                      image = "/menu/gentoo.png"
                  }

                text {
                    text = "Gentoo"
                      color = "yellow:light-green"
                }
            }
        }

        panel {
            direction = left_to_right
              hspace = 10/1
#background = ",,green,#32:,,cyan,#32"
              border_width = 1
              border_height = 1
              border_color = "brown:red"
              max_width = 25
              min_height = 8
              anchor = 1

              panel {
                  direction = top_to_bottom
                    vspace = 10/1
                    background = ":,,cyan, "
                    command = "aa"

                    image {
                        image = "/menu/ubuntu.png"
                    }

                  text {
                      text = "Ubuntu"
                        color = "yellow:light-green"
                  }
              }

            panel {
                direction = bottom_to_top
                  vspace = 10/1
                  halign = center
                  background = ":,,cyan, "
                  command = "bb"

                  image {
                      image = "/menu/debian.png"
                  }

                text {
                    text = "Debian Lenny"
                      color = "yellow:light-green"
                }
            }

            panel {
                direction = top_to_bottom
                  vspace = 10/1
                  halign = center
                  background = ":,,cyan, "
                  command = "bb"

                  image {
                      image = "/menu/gentoo.png"
                  }

                text {
                    text = "Gentoo"
                      color = "yellow:light-green"
                }
            }
        }

        panel {
            direction = top_to_bottom
              border_width = 1
              border_height = 1
              border_color = "brown:red"
              width = 16
              height = 8
              vspace = 1
              anchor = 1

              panel {
                  direction = left_to_right
                    hspace = 2

                    panel {
                        width = 8
                          height = 4
                          background = ",,black,#32:,,light-gray,#32"
                          command = "aa"
                    }

                  panel {
                      width = 8
                        height = 4
                        background = ",,blue,#32:,,brown,#32"
                        command = "bb"
                  }
              }

            panel {
                direction = left_to_right
                  hspace = 2

                  panel {
                      width = 8
                        height = 4
                        background = ",,green,#32:,,magenta,#32"
                        command = "cc"
                  }

                panel {
                    width = 8
                      height = 4
                      background = ",,cyan,#32:,,red,#32"
                      command = "dd"
                }
            }
        }
    }
}

Re: [GITGRUB] New menu interface (implementation)

[Peter Cros]

[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]

Demo auto scrolling runs  OK on apple efi but some comments  -

Problem with different scaling between Text and Graphic mode on 1920x1200,
text loses the bottom  7th widget selection possibility.

I seem to expect an initial visible focussed panel indication, instead of
having to hit N to see it. Perhaps that is irrelevant at this stage.

Posted pictures on ubuntuforms to show Text versus Gfx.

On Sun, Oct 4, 2009 at 3:27 PM, Bean <bean123ch@gmail.com> wrote:

> On Sun, Oct 4, 2009 at 6:34 AM, Michal Suchanek <hramrach@centrum.cz>
> wrote:
> > 2009/10/3 Bean <bean123ch@gmail.com>:
> >> Hi,
> >>
> >> Update:
> >>
> >> Add auto scrolling support, view port would be adjusted automatically
> >> to show the current node. In the demo, there are five horizontal
> >> widgets, total length exceed that of the screen, using 'N' and 'P' to
> >> navigating between anchors, and you can see the hidden widget would
> >> scroll into view automatically, ESC to exit the demo.
> >>
> >
> > Hello,
> >
> > Do you have an update of the sample configuration for menu test?
> >
> > The old sample reports "class not found".
>
> Hi,
>
> It's at:
>
> http://grub4dos.sourceforge.net/menu.zip
>
> Download it again and replace the files.
>
> --
> Bean
>
> gitgrub home: http://github.com/grub/grub/
> my fork page: http://github.com/bean123/grub/
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Cros (pxw)

[-- Attachment #2: Type: text/html, Size: 2566 bytes --]

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Sun, Oct 4, 2009 at 8:03 PM, Peter Cros <pxwpxw8@gmail.com> wrote:
> Demo auto scrolling runs  OK on apple efi but some comments  -
>
> Problem with different scaling between Text and Graphic mode on 1920x1200,
> text loses the bottom  7th widget selection possibility.

Hi,

Oh, that's expected. As the bottom widget consist of bitmaps only, and
text mode can't display bitmaps, it'd be skipped. In order to show it,
you can either:

1, use panel to bind bitmap and text together

    panel {
      direction = left_to_right
      background = ":,,green, "
      command = "aa"

      image {
        image = "/menu/ubuntu.png"
      }

      text {
        text = "Ubuntu"
        color = "yellow:light-green"
      }
    }

2, Use a special syntax that instruct the menu system to display a
rectangle when bitmap can't be loaded:

      image {
        image = "/menu/ubuntu.png,,red,#32"
      }

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Sun, Oct 4, 2009 at 7:22 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> Hi
>
> I only tried running the sample, did not look how things are done yet.
>
> The major problem is that the panels are not sorted in any way so the
> navigation is very confusing. There should be only a single toplevel
> panel which contains all active elements in a layout.
>
> However, when I put everything into a single panel I still get issues:
>
>  - the content is not inside the panel border
>  - focus is on an invisible element, not the first element

Hi,

Oh, that's a small bug, easy to fix.

>  - panels are not ordered left to right as specified

I don't understand, it looks left to right to me. Or do you mean that
small bar in the bottom ? It has margin_bottom set so that it sticks
to the border.

>
> There is an issue with setting the border and margins.
>  - if I set all margins to the same number the horizontal and vertical
> margins are different which is quite ugly

The default unit is character, which have different width and height
value, you can use the pixel format as:

border_width = "5/1"
border_height = "5/1"

Then width/height would be 5 pixel in graphic mode.

>  - the border settings offer many options but I miss the option for
>   - setting the text border explicitly to single/double border
> without using an image

I think image is most flexible, who want ascii border in graphic mode
? BTW, border in graphic mode doesn't necessary be full character
size, so text may not draw properly anyway. About the single/double
border, it's more suitable to config them using styles other that
property.

>   - replicating similar effect in graphics (that is setting a few
> pixel border with some space on either side - margin should set the
> outer space but I am not sure about the inner space)
>  - background bitmap does not cover margins. I am not sure if it is
> desirable to cover them, though. CSS works that way but I am sure some
> systems work differently.

I don't understand, can you be more specific ?

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[richardvoigt]

>>  - the border settings offer many options but I miss the option for
>>   - setting the text border explicitly to single/double border
>> without using an image
>
> I think image is most flexible, who want ascii border in graphic mode
> ? BTW, border in graphic mode doesn't necessary be full character
> size, so text may not draw properly anyway. About the single/double
> border, it's more suitable to config them using styles other that
> property.

Can't one obtain an N pixel solid border by using a parent panel with
background = border color, and client panel just a few pixels smaller
using the margin-positioning directives?

This should give a border without needing a new set of commands, nor
image files.

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Mon, Oct 5, 2009 at 12:06 AM, richardvoigt@gmail.com
<richardvoigt@gmail.com> wrote:
>>>  - the border settings offer many options but I miss the option for
>>>   - setting the text border explicitly to single/double border
>>> without using an image
>>
>> I think image is most flexible, who want ascii border in graphic mode
>> ? BTW, border in graphic mode doesn't necessary be full character
>> size, so text may not draw properly anyway. About the single/double
>> border, it's more suitable to config them using styles other that
>> property.
>
> Can't one obtain an N pixel solid border by using a parent panel with
> background = border color, and client panel just a few pixels smaller
> using the margin-positioning directives?
>
> This should give a border without needing a new set of commands, nor
> image files.

Hi,

You can use border_width, border_height and border_color property to
add a strip of solid color around a panel, no need to add another one.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Select the first item when menu starts.
Fix a bug in border handling, now the position should be ok
Fix a bug in EFI linux loader
Add edit widget.

Properties for the edit widget:
lines: number of lines, default value is 1
columns: number of columns, default value 20
max_lines: maximum number of history, default value 100, if more lines
are entered, the oldest lines would be discard. If max_lines is set to
0, no limit on the
lines stored.
font: font name
color: font color

Unlike gfxterm, edit widget support proportional font, the demo use
Helvetica to illustrate it.

Hotkey inside edit widget:

Up: Move up one line
Down: Move down one line
Left: Move left one character
Right: Move right one character
Backspace: Erase one character
TAB: Leave the widget and jump to next item

The widget support smart scrolling, when the text exceed the border,
it scroll the cursor to the center so that it have more blank space
(like emacs), it also remember the cursor position, you can edit some
text, then jump to another item. When you jump back to the edit
widget, the cursor would restore to the last position.

Resource file menu.zip updated for the new edit widget.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Mon, Oct 5, 2009 at 4:05 AM, Bean <bean123ch@gmail.com> wrote:
> Hi,
>
> Update:
>
> Select the first item when menu starts.
> Fix a bug in border handling, now the position should be ok
> Fix a bug in EFI linux loader
> Add edit widget.
>
> Properties for the edit widget:
> lines: number of lines, default value is 1
> columns: number of columns, default value 20
> max_lines: maximum number of history, default value 100, if more lines
> are entered, the oldest lines would be discard. If max_lines is set to
> 0, no limit on the
> lines stored.
> font: font name
> color: font color
>
> Unlike gfxterm, edit widget support proportional font, the demo use
> Helvetica to illustrate it.
>
> Hotkey inside edit widget:
>
> Up: Move up one line
> Down: Move down one line
> Left: Move left one character
> Right: Move right one character
> Backspace: Erase one character
> TAB: Leave the widget and jump to next item
>
> The widget support smart scrolling, when the text exceed the border,
> it scroll the cursor to the center so that it have more blank space
> (like emacs), it also remember the cursor position, you can edit some
> text, then jump to another item. When you jump back to the edit
> widget, the cursor would restore to the last position.
>
> Resource file menu.zip updated for the new edit widget.

Hi,

Oh, forget to mention these keys:

Home: jump to the first character in the current line
End: jump to the last character in the current line


-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/4 Bean <bean123ch@gmail.com>:
> On Mon, Oct 5, 2009 at 12:06 AM, richardvoigt@gmail.com
> <richardvoigt@gmail.com> wrote:
>>>>  - the border settings offer many options but I miss the option for
>>>>   - setting the text border explicitly to single/double border
>>>> without using an image
>>>
>>> I think image is most flexible, who want ascii border in graphic mode

It should be possible to construct a menu usable in both text and
graphics without additional images.

>>> ? BTW, border in graphic mode doesn't necessary be full character
>>> size, so text may not draw properly anyway. About the single/double
>>> border, it's more suitable to config them using styles other that
>>> property.
>>
>> Can't one obtain an N pixel solid border by using a parent panel with
>> background = border color, and client panel just a few pixels smaller
>> using the margin-positioning directives?

Yes, that should be possible. I just expect that his would be a common
task so it would be nicer to have also inner spacing that adds space
inside the border without an additional panel.

>>
>> This should give a border without needing a new set of commands, nor
>> image files.
>
> Hi,
>
> You can use border_width, border_height and border_color property to
> add a strip of solid color around a panel, no need to add another one.

You need another one to get a a space between the border and the panel content.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/4 Bean <bean123ch@gmail.com>:
> On Sun, Oct 4, 2009 at 7:22 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> Hi
>>
>> I only tried running the sample, did not look how things are done yet.
>>
>> The major problem is that the panels are not sorted in any way so the
>> navigation is very confusing. There should be only a single toplevel
>> panel which contains all active elements in a layout.
>>
>> However, when I put everything into a single panel I still get issues:
>>
>>  - the content is not inside the panel border
>>  - focus is on an invisible element, not the first element
>
> Hi,
>
> Oh, that's a small bug, easy to fix.
>
>>  - panels are not ordered left to right as specified
>
> I don't understand, it looks left to right to me. Or do you mean that
> small bar in the bottom ? It has margin_bottom set so that it sticks
> to the border.

There are panels above it so it is not left to right.

The margin should increase the outer size of the widget so that when
space is allocated for it the margin is taken into account but not
stick it to the bottom. That's what alignment (valign) is for.

A width=100%, margin_left=3, margin_right=3 widget should occupy the
available width minus 6 characters.

>
> The default unit is character, which have different width and height
> value, you can use the pixel format as:
>
> border_width = "5/1"
> border_height = "5/1"
>
> Then width/height would be 5 pixel in graphic mode.
>

One should only remember to set horizontal sizes twice of the vertical
sizes in text. Not nice but there is no nice way to avoid it I guess.

>>  - background bitmap does not cover margins. I am not sure if it is
>> desirable to cover them, though. CSS works that way but I am sure some
>> systems work differently.
>
> I don't understand, can you be more specific ?

The only useful case is probably resolved by adding a toplevel panel
inside screen and setting background on the screen.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

Hello

I tried to get some borders into the previous demo but I got overlapping panels.

This should not happen because it is not supported. That's what the
layout manager is for.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

[-- Attachment #1: Type: text/plain, Size: 41 bytes --]

Forgot to attach the menu configuration.

[-- Attachment #2: menu.txt --]
[-- Type: text/plain, Size: 12226 bytes --]

screen {
    background = "/menu/back.png,,blue"

      panel {
          border_width = 2/1
            margin_left = 25/3
            margin_top = 25/1
            margin_right = 25/3
            margin_bottom = 25/1
            border_color = "brown:red"
            panel{
                direction = left_to_right
                  margin_left = 3/0
                  margin_top = 3/0
                  margin_right = 3/0
                  margin_bottom = 3/0


                  panel{
                      border_width = 2/0
                        margin_left = 3/1
                        margin_top = 3/0
                        margin_right = 3/1
                        margin_bottom = 3/0
                        border_color = "brown:red"
                        panel{
                            direction = left_to_right
                              margin_left = 3/0
                              margin_top = 3/0
                              margin_right = 3/0
                              margin_bottom = 3/0

                              background = ",,brown,#32:,,red,#32"
                              direction = left_to_right
                              hspace = 10/0
                              vspace = 10/0
                              anchor = 1

                              image {
                                  image = "/menu/ubuntu_b.png:/menu/ubuntu.png"
                                    command = "aa"
                              }

                            image {
                                image = "/menu/debian_b.png:/menu/debian.png"
                                  command = "bb"
                            }

                            image {
                                image = "/menu/gentoo_b.png:/menu/gentoo.png"
                                  command = "cc"
                            }
                        }
                  }

                panel {
                    direction = bottom_to_top
                      vspace = 10/1
#background = ",,green,#32:,,cyan,#32"
                      border_width = 1
                      border_height = 1
                      border_color = "brown:red"
                      extend = 1
                      anchor = 1

                      panel {
                          direction = left_to_right
                            hspace = 10/1
                            background = ":,,green, "
                            command = "aa"

                            image {
                                image = "/menu/ubuntu.png"
                            }

                          text {
                              text = "Ubuntu"
                                color = "yellow:light-green"
                          }
                      }

                    panel {
                        direction = right_to_left
                          hspace = 10/1
                          valign = center
                          background = ":,,green, "
                          command = "bb"

                          image {
                              image = "/menu/debian.png"
                          }

                        text {
                            text = "Debian Lenny"
                              color = "yellow:light-green"
                        }
                    }

                    panel {
                        direction = left_to_right
                          hspace = 10/1
                          valign = bottom
                          halign = right
                          background = ":,,green, "
                          command = "cc"

                          image {
                              image = "/menu/gentoo.png"
                          }

                        text {
                            text = "Gentoo"
                              color = "yellow:light-green"
                        }
                    }
                }

                panel {
                    direction = bottom_to_top
                      vspace = 10/1
#background = ",,green,#32:,,cyan,#32"
                      border_width = 1
                      border_height = 1
                      border_color = "brown:red"
                      anchor = 1

                      panel {
                          direction = left_to_right
                            hspace = 10/1
                            background = ":,,green, "
                            command = "aa"

                            image {
                                image = "/menu/ubuntu.png"
                            }

                          text {
                              text = "Ubuntu"
                                color = "yellow:light-green"
                          }
                      }

                    panel {
                        direction = right_to_left
                          hspace = 10/1
                          valign = center
                          background = ":,,green, "
                          command = "bb"

                          image {
                              image = "/menu/debian.png"
                          }

                        text {
                            text = "Debian Lenny"
                              color = "yellow:light-green"
                        }
                    }

                    panel {
                        direction = left_to_right
                          hspace = 10/1
                          valign = bottom
                          halign = right
                          background = ":,,green, "
                          command = "cc"

                          image {
                              image = "/menu/gentoo.png"
                          }

                        text {
                            text = "Gentoo"
                              color = "yellow:light-green"
                        }
                    }
                }

                panel {
                    direction = left_to_right
                      hspace = 10/1
#background = ",,green,#32:,,cyan,#32"
                      border_width = 1
                      border_height = 1
                      border_color = "brown:red"
                      max_width = 25
                      min_height = 8
                      extend = 1
                      anchor = 1

                      panel {
                          direction = top_to_bottom
                            vspace = 10/1
                            background = ":,,cyan, "
                            command = "aa"

                            image {
                                image = "/menu/ubuntu.png"
                            }

                          text {
                              text = "Ubuntu"
                                color = "yellow:light-green"
                          }
                      }

                    panel {
                        direction = bottom_to_top
                          vspace = 10/1
                          halign = center
                          background = ":,,cyan, "
                          command = "bb"

                          image {
                              image = "/menu/debian.png"
                          }

                        text {
                            text = "Debian Lenny"
                              color = "yellow:light-green"
                        }
                    }

                    panel {
                        direction = top_to_bottom
                          vspace = 10/1
                          halign = center
                          background = ":,,cyan, "
                          command = "bb"

                          image {
                              image = "/menu/gentoo.png"
                          }

                        text {
                            text = "Gentoo"
                              color = "yellow:light-green"
                        }
                    }
                }

                panel {
                    direction = left_to_right
                      hspace = 10/1
#background = ",,green,#32:,,cyan,#32"
                      border_width = 1
                      border_height = 1
                      border_color = "brown:red"
                      max_width = 25
                      min_height = 8
                      anchor = 1

                      panel {
                          direction = top_to_bottom
                            vspace = 10/1
                            background = ":,,cyan, "
                            command = "aa"

                            image {
                                image = "/menu/ubuntu.png"
                            }

                          text {
                              text = "Ubuntu"
                                color = "yellow:light-green"
                          }
                      }

                    panel {
                        direction = bottom_to_top
                          vspace = 10/1
                          halign = center
                          background = ":,,cyan, "
                          command = "bb"

                          image {
                              image = "/menu/debian.png"
                          }

                        text {
                            text = "Debian Lenny"
                              color = "yellow:light-green"
                        }
                    }

                    panel {
                        direction = top_to_bottom
                          vspace = 10/1
                          halign = center
                          background = ":,,cyan, "
                          command = "bb"

                          image {
                              image = "/menu/gentoo.png"
                          }

                        text {
                            text = "Gentoo"
                              color = "yellow:light-green"
                        }
                    }
                }

                panel {
                    direction = top_to_bottom
                      border_width = 1
                      border_height = 1
                      border_color = "brown:red"
                      width = 16
                      height = 8
                      vspace = 1
                      anchor = 1

                      panel {
                          direction = left_to_right
                            hspace = 2

                            panel {
                                width = 8
                                  height = 4
                                  background = ",,black,#32:,,light-gray,#32"
                                  command = "aa"
                            }

                          panel {
                              width = 8
                                height = 4
                                background = ",,blue,#32:,,brown,#32"
                                command = "bb"
                          }
                      }

                    panel {
                        direction = left_to_right
                          hspace = 2

                          panel {
                              width = 8
                                height = 4
                                background = ",,green,#32:,,magenta,#32"
                                command = "cc"
                          }

                        panel {
                            width = 8
                              height = 4
                              background = ",,cyan,#32:,,red,#32"
                              command = "dd"
                        }
                    }
                }
            }
      }
}

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Mon, Oct 5, 2009 at 6:20 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> Hello
>
> I tried to get some borders into the previous demo but I got overlapping panels.
>
> This should not happen because it is not supported. That's what the
> layout manager is for.

Hi,

I think you misunderstand the meaning of margin_* properties. It means
that the widget is always at a constant distance from parent widget.
Once it's set, their position is fixed, it's not subject to the layout
manger. This is used to create sticky panels like docks. For example:

panel
{
  panel { id="aa" margin_bottom=0 }
  panel { id="bb" }
  panel { id="cc" }
  panel { id="dd"}
}

aa's location is fixed, bb, cc and dd's location is calculated by the
panel, they can overlap with aa.

The sticky panel also doesn't move when view port is scrolled to
display active item.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Mon, Oct 5, 2009 at 5:57 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> There are panels above it so it is not left to right.
>
> The margin should increase the outer size of the widget so that when
> space is allocated for it the margin is taken into account but not
> stick it to the bottom. That's what alignment (valign) is for.

Hi,

To add space between widgets whose location is calculated by layout
manger, use hspace and vspace, margin_bottom is used to indicate that
widget is sticky to the south border and therefore not determined by
the layout manger.

> A width=100%, margin_left=3, margin_right=3 widget should occupy the
> available width minus 6 characters.

margin_left=3, margin_right=3 already means the widget would occupy
the available width minus 6 characters, don't use width=100% as well
otherwise it'd confuse the menu system.

The percentage is calculated using parent panel, for example, if
parent panel width is 10, margin_left=3, margin_right=3 would generate
a width of 4, but 100% calculated as 10, they're different.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/5 Bean <bean123ch@gmail.com>:
> On Mon, Oct 5, 2009 at 6:20 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> Hello
>>
>> I tried to get some borders into the previous demo but I got overlapping panels.
>>
>> This should not happen because it is not supported. That's what the
>> layout manager is for.
>
> Hi,
>
> I think you misunderstand the meaning of margin_* properties. It means
> that the widget is always at a constant distance from parent widget.
> Once it's set, their position is fixed, it's not subject to the layout
> manger. This is used to create sticky panels like docks. For example:
>
> panel
> {
>  panel { id="aa" margin_bottom=0 }
>  panel { id="bb" }
>  panel { id="cc" }
>  panel { id="dd"}
> }
>
> aa's location is fixed, bb, cc and dd's location is calculated by the
> panel, they can overlap with aa.
>
> The sticky panel also doesn't move when view port is scrolled to
> display active item.

No, dock is easily created like

panel
{
 panel { id="aa" margin_bottom=0 }
 panel {
  panel { id="bb" }
  panel { id="cc" }
  panel { id="dd"}
 }
}

A panel should never be removed from layout management, it then
becomes pointless.

A top-aligned panel should be done with alignment, and should be only
possible in horizontal panels like this:

panel{
 direction = left_to_right
  panel{ id ="bb" ;valign = center}
  panel{ id ="bb" ; valign = top}
  panel{ id ="bb" ; valign = bottom}
 }
}

In a top to bottom or bottom to top the first panel is aligned to
bottom/top side of the panel automatically.

The margin property should not force a fixed position because it
breaks layout to the point that elements overlap and it's completely
pointless to have fixed position since position can be specified with
margins and alignment once width is fixed to include margins.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/5 Bean <bean123ch@gmail.com>:
> On Mon, Oct 5, 2009 at 5:57 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> There are panels above it so it is not left to right.
>>
>> The margin should increase the outer size of the widget so that when
>> space is allocated for it the margin is taken into account but not
>> stick it to the bottom. That's what alignment (valign) is for.
>
> Hi,
>
> To add space between widgets whose location is calculated by layout
> manger, use hspace and vspace, margin_bottom is used to indicate that

It does not add space between the elements contained in a panel and
the border of the panel.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Mon, Oct 5, 2009 at 5:07 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/5 Bean <bean123ch@gmail.com>:
>> On Mon, Oct 5, 2009 at 6:20 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> Hello
>>>
>>> I tried to get some borders into the previous demo but I got overlapping panels.
>>>
>>> This should not happen because it is not supported. That's what the
>>> layout manager is for.
>>
>> Hi,
>>
>> I think you misunderstand the meaning of margin_* properties. It means
>> that the widget is always at a constant distance from parent widget.
>> Once it's set, their position is fixed, it's not subject to the layout
>> manger. This is used to create sticky panels like docks. For example:
>>
>> panel
>> {
>>  panel { id="aa" margin_bottom=0 }
>>  panel { id="bb" }
>>  panel { id="cc" }
>>  panel { id="dd"}
>> }
>>
>> aa's location is fixed, bb, cc and dd's location is calculated by the
>> panel, they can overlap with aa.
>>
>> The sticky panel also doesn't move when view port is scrolled to
>> display active item.
>
> No, dock is easily created like
>
> panel
> {
>  panel { id="aa" margin_bottom=0 }
>  panel {
>  panel { id="bb" }
>  panel { id="cc" }
>  panel { id="dd"}
>  }
> }
>
> A panel should never be removed from layout management, it then
> becomes pointless.

Hi,

Sometimes it's useful to have absolute address, for example to adjust
the window according to the background image, it's quite tricky to do
this with dynamic positioning. If you want everything to be controlled
by the layout manger, just don't use the property and wrap panels
around widgets.

From your previous description, I think your meaning of margin is some
kind of space left around the border of panel, I think that could be
useful as well, but perhaps with a different name, I'm considering the
following properties:

inner_left, inner_right, inner_top, inner_bottom: space reserved
inside the border
outer_left, outer_right, outer_top, outer_bottom: space reserved
outside the border

Perhaps the naming of margin_* property is a little misleading,
perhaps I can rename them distance_* to remind it they're used as
fixed distance to borders of parent.

>
> A top-aligned panel should be done with alignment, and should be only
> possible in horizontal panels like this:
>
> panel{
>  direction = left_to_right
>  panel{ id ="bb" ;valign = center}
>  panel{ id ="bb" ; valign = top}
>  panel{ id ="bb" ; valign = bottom}
>  }
> }
>
> In a top to bottom or bottom to top the first panel is aligned to
> bottom/top side of the panel automatically.

In the currently implementation, valign is for the parent widget

 panel{
  direction = left_to_right
  valign = center
  panel{ id ="bb"}
  panel{ id ="bb"}
  panel{ id ="bb"}
  }
 }

Align all child vertically, but I guess this can be implemented per child.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Mon, Oct 5, 2009 at 5:07 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> A panel should never be removed from layout management, it then
> becomes pointless.
>
> A top-aligned panel should be done with alignment, and should be only
> possible in horizontal panels like this:
>
> panel{
>  direction = left_to_right
>  panel{ id ="bb" ;valign = center}
>  panel{ id ="bb" ; valign = top}
>  panel{ id ="bb" ; valign = bottom}
>  }
> }
>
> In a top to bottom or bottom to top the first panel is aligned to
> bottom/top side of the panel automatically.

Hi,

Actually, I just through of a possible issue with children assigned
alignment. For the parent panel, there is a halign property, For
example, if parent width is 50, each child's width is 10, there are
three halign values:

halign = right
b1  b2  b3  empty
10  10  10  20

halign = center
b1  empty b2  empty  b3
10    10    10     10     10

halign = right
empty b1  b2  b3
20      10  10   10

halign is obviously not belonged to children, so you might write it as:

panel{
 direction = left_to_right
 halign = center
 panel{ id ="bb" ;valign = center}
 panel{ id ="bb" ; valign = top}
 panel{ id ="bb" ; valign = bottom}
 }
}

But then there is problem, as panel can be children as well, for example:

panel {
 id = "top"
 direction = top_to_bottom

panel{
 id = "aa"
 direction = left_to_right
 halign = center
 panel{ id ="bb" ;valign = center}
 panel{ id ="bb" ; valign = top}
 panel{ id ="bb" ; valign = bottom}
 }
}
}

In this case, should halign of aa be used to control its own alignment
from top, or that of its children ?

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/5 Bean <bean123ch@gmail.com>:
> On Mon, Oct 5, 2009 at 5:07 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> A panel should never be removed from layout management, it then
>> becomes pointless.
>>
>> A top-aligned panel should be done with alignment, and should be only
>> possible in horizontal panels like this:
>>
>> panel{
>>  direction = left_to_right
>>  panel{ id ="bb" ;valign = center}
>>  panel{ id ="bb" ; valign = top}
>>  panel{ id ="bb" ; valign = bottom}
>>  }
>> }
>>
>> In a top to bottom or bottom to top the first panel is aligned to
>> bottom/top side of the panel automatically.
>
> Hi,
>
> Actually, I just through of a possible issue with children assigned
> alignment. For the parent panel, there is a halign property, For
> example, if parent width is 50, each child's width is 10, there are
> three halign values:
>
> halign = right
> b1  b2  b3  empty
> 10  10  10  20
>
> halign = center
> b1  empty b2  empty  b3
> 10    10    10     10     10

This can be done with

  b1     hspace   b2       hspace     b3
  20%  20%       20%          20%   20%

but why would you want such spacing?

Normally you would want the panels take up most space possibly with
some small spacing or the outer panel shrink around the inner panels.

>
> halign = right

Perhaps use direction?
Why do you want the empty space there?

There are infinite possibilities of alignment so we should choose an
alignment method that allows for commonly used alignments and perhaps
some less common but useful, not all alignments that somebody can
possibly think of.

> empty b1  b2  b3
> 20      10  10   10
>
> halign is obviously not belonged to children, so you might write it as:
>
> panel{
>  direction = left_to_right
>  halign = center
>  panel{ id ="bb" ;valign = center}
>  panel{ id ="bb" ; valign = top}
>  panel{ id ="bb" ; valign = bottom}
>  }
> }
>
> But then there is problem, as panel can be children as well, for example:
>
> panel {
>  id = "top"
>  direction = top_to_bottom
>
> panel{
>  id = "aa"
>  direction = left_to_right
>  halign = center
>  panel{ id ="bb" ;valign = center}
>  panel{ id ="bb" ; valign = top}
>  panel{ id ="bb" ; valign = bottom}
>  }
> }
> }
>
> In this case, should halign of aa be used to control its own alignment
> from top, or that of its children ?

It should be used to align itself, obviously as you want to control
the alignment of each child separately and if halign = center was
applied to all this would not be possible.


Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/5 Bean <bean123ch@gmail.com>:
> On Mon, Oct 5, 2009 at 5:07 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/5 Bean <bean123ch@gmail.com>:
>>> On Mon, Oct 5, 2009 at 6:20 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> Hello
>>>>
>>>> I tried to get some borders into the previous demo but I got overlapping panels.
>>>>
>>>> This should not happen because it is not supported. That's what the
>>>> layout manager is for.
>>>
>>> Hi,
>>>
>>> I think you misunderstand the meaning of margin_* properties. It means
>>> that the widget is always at a constant distance from parent widget.
>>> Once it's set, their position is fixed, it's not subject to the layout
>>> manger. This is used to create sticky panels like docks. For example:
>>>
>>> panel
>>> {
>>>  panel { id="aa" margin_bottom=0 }
>>>  panel { id="bb" }
>>>  panel { id="cc" }
>>>  panel { id="dd"}
>>> }
>>>
>>> aa's location is fixed, bb, cc and dd's location is calculated by the
>>> panel, they can overlap with aa.
>>>
>>> The sticky panel also doesn't move when view port is scrolled to
>>> display active item.
>>
>> No, dock is easily created like
>>
>> panel
>> {
>>  panel { id="aa" margin_bottom=0 }
>>  panel {
>>  panel { id="bb" }
>>  panel { id="cc" }
>>  panel { id="dd"}
>>  }
>> }
>>
>> A panel should never be removed from layout management, it then
>> becomes pointless.
>
> Hi,
>
> Sometimes it's useful to have absolute address, for example to adjust
> the window according to the background image, it's quite tricky to do
> this with dynamic positioning. If you want everything to be controlled

How is it hard to measure the place where you want to place the
element on the background bitmap and use that place as the margin (or
outer space as you call it) and then align the element to the border
from which you measured (as in valign = bottom)?

You measure and enter the exact same value as you do with fixed
positioning but the layout manages makes sure that another element
does not cover your precisely positioned element.

> by the layout manger, just don't use the property and wrap panels
> around widgets.

That does not work because I want to insert spacing which the layout
manager does not do automatically.

>
> From your previous description, I think your meaning of margin is some
> kind of space left around the border of panel, I think that could be
> useful as well, but perhaps with a different name, I'm considering the
> following properties:
>
> inner_left, inner_right, inner_top, inner_bottom: space reserved
> inside the border
> outer_left, outer_right, outer_top, outer_bottom: space reserved
> outside the border
>
> Perhaps the naming of margin_* property is a little misleading,
> perhaps I can rename them distance_* to remind it they're used as
> fixed distance to borders of parent.

Yes. margin is normally used for spacing, not absolute positioning.
However, spacing and alignment can be used together to force an
absolute position without the need for yet another property.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[richardvoigt]

> Perhaps the naming of margin_* property is a little misleading,
> perhaps I can rename them distance_* to remind it they're used as
> fixed distance to borders of parent.

That's undoubtedly the problem.

For example, Motif uses the term "attach" to achieve fixed distance
from the edge of the parent (or from a sibling component).

See e.g. http://www.cs.cf.ac.uk/Dave/X_lecture/node8.html

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Mon, Oct 5, 2009 at 9:33 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/5 Bean <bean123ch@gmail.com>:
>> On Mon, Oct 5, 2009 at 5:07 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> A panel should never be removed from layout management, it then
>>> becomes pointless.
>>>
>>> A top-aligned panel should be done with alignment, and should be only
>>> possible in horizontal panels like this:
>>>
>>> panel{
>>>  direction = left_to_right
>>>  panel{ id ="bb" ;valign = center}
>>>  panel{ id ="bb" ; valign = top}
>>>  panel{ id ="bb" ; valign = bottom}
>>>  }
>>> }
>>>
>>> In a top to bottom or bottom to top the first panel is aligned to
>>> bottom/top side of the panel automatically.
>>
>> Hi,
>>
>> Actually, I just through of a possible issue with children assigned
>> alignment. For the parent panel, there is a halign property, For
>> example, if parent width is 50, each child's width is 10, there are
>> three halign values:
>>
>> halign = right
>> b1  b2  b3  empty
>> 10  10  10  20
>>
>> halign = center
>> b1  empty b2  empty  b3
>> 10    10    10     10     10
>
> This can be done with
>
>  b1     hspace   b2       hspace     b3
>  20%  20%       20%          20%   20%
>
> but why would you want such spacing?
>
> Normally you would want the panels take up most space possibly with
> some small spacing or the outer panel shrink around the inner panels.
>
>>
>> halign = right
>
> Perhaps use direction?
> Why do you want the empty space there?
>
> There are infinite possibilities of alignment so we should choose an
> alignment method that allows for commonly used alignments and perhaps
> some less common but useful, not all alignments that somebody can
> possibly think of.
>

Hi,

Consider the outer box as screen, whose size is fixed. If we want the
panels to span the whole screen instead of cluster at the left side,
then halign is quite useful, you can check out the demo to see how the
windows are placed.

>> empty b1  b2  b3
>> 20      10  10   10
>>
>> halign is obviously not belonged to children, so you might write it as:
>>
>> panel{
>>  direction = left_to_right
>>  halign = center
>>  panel{ id ="bb" ;valign = center}
>>  panel{ id ="bb" ; valign = top}
>>  panel{ id ="bb" ; valign = bottom}
>>  }
>> }
>>
>> But then there is problem, as panel can be children as well, for example:
>>
>> panel {
>>  id = "top"
>>  direction = top_to_bottom
>>
>> panel{
>>  id = "aa"
>>  direction = left_to_right
>>  halign = center
>>  panel{ id ="bb" ;valign = center}
>>  panel{ id ="bb" ; valign = top}
>>  panel{ id ="bb" ; valign = bottom}
>>  }
>> }
>> }
>>
>> In this case, should halign of aa be used to control its own alignment
>> from top, or that of its children ?
>
> It should be used to align itself, obviously as you want to control
> the alignment of each child separately and if halign = center was
> applied to all this would not be possible.

Right, perhaps it's more natural that the valign/halign are used for
the widget itself, but I still think it's useful to control parent's
alignment strategy, perhaps with a new property.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Tue, Oct 6, 2009 at 1:52 AM, richardvoigt@gmail.com
<richardvoigt@gmail.com> wrote:
>> Perhaps the naming of margin_* property is a little misleading,
>> perhaps I can rename them distance_* to remind it they're used as
>> fixed distance to borders of parent.
>
> That's undoubtedly the problem.
>
> For example, Motif uses the term "attach" to achieve fixed distance
> from the edge of the parent (or from a sibling component).
>
> See e.g. http://www.cs.cf.ac.uk/Dave/X_lecture/node8.html

Hi,

Oh, attach is a better name, thanks for the tip.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Mon, Oct 5, 2009 at 9:40 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/5 Bean <bean123ch@gmail.com>:
>> On Mon, Oct 5, 2009 at 5:07 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> 2009/10/5 Bean <bean123ch@gmail.com>:
>>>> On Mon, Oct 5, 2009 at 6:20 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>> Hello
>>>>>
>>>>> I tried to get some borders into the previous demo but I got overlapping panels.
>>>>>
>>>>> This should not happen because it is not supported. That's what the
>>>>> layout manager is for.
>>>>
>>>> Hi,
>>>>
>>>> I think you misunderstand the meaning of margin_* properties. It means
>>>> that the widget is always at a constant distance from parent widget.
>>>> Once it's set, their position is fixed, it's not subject to the layout
>>>> manger. This is used to create sticky panels like docks. For example:
>>>>
>>>> panel
>>>> {
>>>>  panel { id="aa" margin_bottom=0 }
>>>>  panel { id="bb" }
>>>>  panel { id="cc" }
>>>>  panel { id="dd"}
>>>> }
>>>>
>>>> aa's location is fixed, bb, cc and dd's location is calculated by the
>>>> panel, they can overlap with aa.
>>>>
>>>> The sticky panel also doesn't move when view port is scrolled to
>>>> display active item.
>>>
>>> No, dock is easily created like
>>>
>>> panel
>>> {
>>>  panel { id="aa" margin_bottom=0 }
>>>  panel {
>>>  panel { id="bb" }
>>>  panel { id="cc" }
>>>  panel { id="dd"}
>>>  }
>>> }
>>>
>>> A panel should never be removed from layout management, it then
>>> becomes pointless.
>>
>> Hi,
>>
>> Sometimes it's useful to have absolute address, for example to adjust
>> the window according to the background image, it's quite tricky to do
>> this with dynamic positioning. If you want everything to be controlled
>
> How is it hard to measure the place where you want to place the
> element on the background bitmap and use that place as the margin (or
> outer space as you call it) and then align the element to the border
> from which you measured (as in valign = bottom)?
>
> You measure and enter the exact same value as you do with fixed
> positioning but the layout manages makes sure that another element
> does not cover your precisely positioned element.
>
>> by the layout manger, just don't use the property and wrap panels
>> around widgets.
>
> That does not work because I want to insert spacing which the layout
> manager does not do automatically.
>
>>
>> From your previous description, I think your meaning of margin is some
>> kind of space left around the border of panel, I think that could be
>> useful as well, but perhaps with a different name, I'm considering the
>> following properties:
>>
>> inner_left, inner_right, inner_top, inner_bottom: space reserved
>> inside the border
>> outer_left, outer_right, outer_top, outer_bottom: space reserved
>> outside the border
>>
>> Perhaps the naming of margin_* property is a little misleading,
>> perhaps I can rename them distance_* to remind it they're used as
>> fixed distance to borders of parent.
>
> Yes. margin is normally used for spacing, not absolute positioning.
> However, spacing and alignment can be used together to force an
> absolute position without the need for yet another property.

Hi,

I think you've overlooked a detail about grub's menu layout. The
smallest elements, text and image, both have fixed size, The largest
element, the screen, also have fixed size, therefore, we need to
adjust the middle layers to fit both ends, it's not as simple as it
seems.

There are two method to calculate the size of window. It can be
calculate using children widget, with auto layout, or parent widget,
with x,y,width,height coordinate, as the smallest and largest element
are fixed, we need to switch from children determined size to parent
determined size at some point during the walk of ui tree.

For operation system, the switch is at the window boundary. Consider
web browser. Inside the browser, elements are placed with layout
manager, no coordinate is needed, but the browser itself is placed on
the screen using x,y,width,height coordinate by the OS. For some OS
like chrome, it seems to incorporate the concept of using the whole
screen as browser. The menu system support both method, it's just a
matter of how you define the border, that's, when to switch from
x,y,width,height positioning to layout manager positioning.

Therefore, it needs to have two set of margin properties:

inner_*, outer_* : calculate from children to parent
attach_* : calculate from parent to children

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[richardvoigt]

> Hi,
>
> I think you've overlooked a detail about grub's menu layout. The
> smallest elements, text and image, both have fixed size, The largest
> element, the screen, also have fixed size, therefore, we need to
> adjust the middle layers to fit both ends, it's not as simple as it
> seems.
>
> There are two method to calculate the size of window. It can be
> calculate using children widget, with auto layout, or parent widget,
> with x,y,width,height coordinate, as the smallest and largest element
> are fixed, we need to switch from children determined size to parent
> determined size at some point during the walk of ui tree.
>
> For operation system, the switch is at the window boundary. Consider
> web browser. Inside the browser, elements are placed with layout
> manager, no coordinate is needed, but the browser itself is placed on
> the screen using x,y,width,height coordinate by the OS. For some OS
> like chrome, it seems to incorporate the concept of using the whole
> screen as browser. The menu system support both method, it's just a
> matter of how you define the border, that's, when to switch from
> x,y,width,height positioning to layout manager positioning.
>
> Therefore, it needs to have two set of margin properties:
>
> inner_*, outer_* : calculate from children to parent

I think that "margin" and "padding" are the standard names for this
spacing measurements (distance from content to border) and (distance
from border to bounding box), respectively.  Also in some systems
padding of adjacent elements can overlap.

> attach_* : calculate from parent to children
>
> --
> Bean
>
> gitgrub home: http://github.com/grub/grub/
> my fork page: http://github.com/bean123/grub/
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/6 Bean <bean123ch@gmail.com>:
> On Mon, Oct 5, 2009 at 9:33 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/5 Bean <bean123ch@gmail.com>:
>>> On Mon, Oct 5, 2009 at 5:07 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> A panel should never be removed from layout management, it then
>>>> becomes pointless.
>>>>
>>>> A top-aligned panel should be done with alignment, and should be only
>>>> possible in horizontal panels like this:
>>>>
>>>> panel{
>>>>  direction = left_to_right
>>>>  panel{ id ="bb" ;valign = center}
>>>>  panel{ id ="bb" ; valign = top}
>>>>  panel{ id ="bb" ; valign = bottom}
>>>>  }
>>>> }
>>>>
>>>> In a top to bottom or bottom to top the first panel is aligned to
>>>> bottom/top side of the panel automatically.
>>>
>>> Hi,
>>>
>>> Actually, I just through of a possible issue with children assigned
>>> alignment. For the parent panel, there is a halign property, For
>>> example, if parent width is 50, each child's width is 10, there are
>>> three halign values:
>>>
>>> halign = right
>>> b1  b2  b3  empty
>>> 10  10  10  20
>>>
>>> halign = center
>>> b1  empty b2  empty  b3
>>> 10    10    10     10     10
>>
>> This can be done with
>>
>>  b1     hspace   b2       hspace     b3
>>  20%  20%       20%          20%   20%
>>
>> but why would you want such spacing?
>>
>> Normally you would want the panels take up most space possibly with
>> some small spacing or the outer panel shrink around the inner panels.
>>
>>>
>>> halign = right
>>
>> Perhaps use direction?
>> Why do you want the empty space there?
>>
>> There are infinite possibilities of alignment so we should choose an
>> alignment method that allows for commonly used alignments and perhaps
>> some less common but useful, not all alignments that somebody can
>> possibly think of.
>>
>
> Hi,
>
> Consider the outer box as screen, whose size is fixed. If we want the
> panels to span the whole screen instead of cluster at the left side,
> then halign is quite useful, you can check out the demo to see how the
> windows are placed.

You wrap them in a panel and center that. If there is any content that
would use the space it uses it. If not they stay in the center.

If you really insist on spreading several panels over the screen I
suggest panel properties that solve this problem: homogenous and
stretch.

homogenous allocates equal space to each child regardless of its size.
Child alignment strategy can then be used to determine where to put
the child in the allocated space in case it is larger/smaller than
required.

stretch inserts equal spacing between its children. This could be
possibly a special spacing value. Given that we have unidirectional
panels now perhaps we should reduce vspace/hspace to a single
property.

>
>>> empty b1  b2  b3
>>> 20      10  10   10
>>>
>>> halign is obviously not belonged to children, so you might write it as:
>>>
>>> panel{
>>>  direction = left_to_right
>>>  halign = center
>>>  panel{ id ="bb" ;valign = center}
>>>  panel{ id ="bb" ; valign = top}
>>>  panel{ id ="bb" ; valign = bottom}
>>>  }
>>> }
>>>
>>> But then there is problem, as panel can be children as well, for example:
>>>
>>> panel {
>>>  id = "top"
>>>  direction = top_to_bottom
>>>
>>> panel{
>>>  id = "aa"
>>>  direction = left_to_right
>>>  halign = center
>>>  panel{ id ="bb" ;valign = center}
>>>  panel{ id ="bb" ; valign = top}
>>>  panel{ id ="bb" ; valign = bottom}
>>>  }
>>> }
>>> }
>>>
>>> In this case, should halign of aa be used to control its own alignment
>>> from top, or that of its children ?
>>
>> It should be used to align itself, obviously as you want to control
>> the alignment of each child separately and if halign = center was
>> applied to all this would not be possible.
>
> Right, perhaps it's more natural that the valign/halign are used for
> the widget itself, but I still think it's useful to control parent's
> alignment strategy, perhaps with a new property.

We already have properties for controlling this strategy:
 - direction
 - hspace/vspace (spacing)
 - inner_space (padding)
 - outer_space on the children (margin)

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Support fill character in graphic mode, this can be used to draw rect
box using ascii character, for example:

    top_left = ",,cyan/blue,#0x250F:,,green/blue,#0x2554"
    top = ",tiling,cyan/blue,#0x2501:,,green/blue,#0x2550"
    top_right = ",,cyan/blue,#0x2513:,,green/blue,#0x2557"
    left = ",tiling,cyan/blue,#0x2503:,,green/blue,#0x2551"
    right = ",tiling,cyan/blue,#0x2503:,,green/blue,#0x2551"
    bottom_left = ",,cyan/blue,#0x2517:,,green/blue,#0x255A"
    bottom = ",tiling,cyan/blue,#0x2501:,,green/blue,#0x2550"
    bottom_right = ",tiling,cyan/blue,#0x251B:,,green/blue,#0x255D"

It draws double rect box when selected, single rect box when not
selected. Works both in text and graphic mode.

To draw a solid color rect, use #0 as the fill character, as in:

background = ",,blue,#0"

Adjustment to the layout manager, now it support the following properties:

direction:
Same as before, value can be left_to_right, right_to_left,
top_to_bottom (default) and bottm_to_top.

position:
This indicate how extra space are distributed among children widgets:
near: pack the widgets at the near end (for example, in left_to_right,
near is left)
center: space are distributed evenly among widgets
far: pack the widgets at the far end (for example, in left_to_right,
far is right)

valign, halign:
Now align property control the position of current widget, instead of
its children, each have four values:
left/top
center
right/bottom
extend - Extend the widget to the full width/height of parent.

margin_left, margin_right, margin_top, margin_bottom
This properties set the inner space reserved by the panel

padding_left, padding_right, padding_top, padding_bottom
This set the outbound box of the panel

attach_left, attach_right, attach_top, attach_bottom
Stick the widget to one of the border of parent, once this is set, the
widget is no longed controlled by the layout manager and therefore can
overlap with other widget.

The demo menu.zip is updated for the new properties.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/6 Bean <bean123ch@gmail.com>:
> Hi,
>
> Update:
>
> Support fill character in graphic mode, this can be used to draw rect
> box using ascii character, for example:
>
>    top_left = ",,cyan/blue,#0x250F:,,green/blue,#0x2554"
>    top = ",tiling,cyan/blue,#0x2501:,,green/blue,#0x2550"
>    top_right = ",,cyan/blue,#0x2513:,,green/blue,#0x2557"
>    left = ",tiling,cyan/blue,#0x2503:,,green/blue,#0x2551"
>    right = ",tiling,cyan/blue,#0x2503:,,green/blue,#0x2551"
>    bottom_left = ",,cyan/blue,#0x2517:,,green/blue,#0x255A"
>    bottom = ",tiling,cyan/blue,#0x2501:,,green/blue,#0x2550"
>    bottom_right = ",tiling,cyan/blue,#0x251B:,,green/blue,#0x255D"
>
> It draws double rect box when selected, single rect box when not
> selected. Works both in text and graphic mode.

This is an interesting feature but I was more interested in
controlling the border in text mode independently of graphics mode.

For example, I would want something like:
 - graphics: 3px outer space, 2px border, 16px inner space
(unfortunately there is no character unit usable because the character
size is different when measured horizontally and vertically)
 - text: single border using the box drawing characters, inner space
vertical 1character

AFAIK this is not possible.

>
>
> Adjustment to the layout manager, now it support the following properties:
>
> direction:
> Same as before, value can be left_to_right, right_to_left,
> top_to_bottom (default) and bottm_to_top.
>
> position:
> This indicate how extra space are distributed among children widgets:
> near: pack the widgets at the near end (for example, in left_to_right,
> near is left)
> center: space are distributed evenly among widgets
> far: pack the widgets at the far end (for example, in left_to_right,
> far is right)

This sounds good. The case when the widgets should be packed in the
center can be done with an additional centered panel.

>
> valign, halign:
> Now align property control the position of current widget, instead of
> its children, each have four values:
> left/top
> center
> right/bottom
> extend - Extend the widget to the full width/height of parent.
>
> margin_left, margin_right, margin_top, margin_bottom
> This properties set the inner space reserved by the panel
>
> padding_left, padding_right, padding_top, padding_bottom
> This set the outbound box of the panel
>
> attach_left, attach_right, attach_top, attach_bottom
> Stick the widget to one of the border of parent, once this is set, the
> widget is no longed controlled by the layout manager and therefore can
> overlap with other widget.
>

This sucks. Since overlap is not properly handled it should not happen.

I am not sure what is the use of this property anyway.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Tue, Oct 6, 2009 at 7:46 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/6 Bean <bean123ch@gmail.com>:
>> Hi,
>>
>> Update:
>>
>> Support fill character in graphic mode, this can be used to draw rect
>> box using ascii character, for example:
>>
>>    top_left = ",,cyan/blue,#0x250F:,,green/blue,#0x2554"
>>    top = ",tiling,cyan/blue,#0x2501:,,green/blue,#0x2550"
>>    top_right = ",,cyan/blue,#0x2513:,,green/blue,#0x2557"
>>    left = ",tiling,cyan/blue,#0x2503:,,green/blue,#0x2551"
>>    right = ",tiling,cyan/blue,#0x2503:,,green/blue,#0x2551"
>>    bottom_left = ",,cyan/blue,#0x2517:,,green/blue,#0x255A"
>>    bottom = ",tiling,cyan/blue,#0x2501:,,green/blue,#0x2550"
>>    bottom_right = ",tiling,cyan/blue,#0x251B:,,green/blue,#0x255D"
>>
>> It draws double rect box when selected, single rect box when not
>> selected. Works both in text and graphic mode.
>
> This is an interesting feature but I was more interested in
> controlling the border in text mode independently of graphics mode.
>
> For example, I would want something like:
>  - graphics: 3px outer space, 2px border, 16px inner space
> (unfortunately there is no character unit usable because the character
> size is different when measured horizontally and vertically)
>  - text: single border using the box drawing characters, inner space
> vertical 1character
>
> AFAIK this is not possible.

Hi,

Well, to achieve that, we need some special syntax to allow users to
skip the border bitmaps optionally in graphic mode, perhaps something
like this:

top_left = "null,,cyan/blue,#0x250F:,,green/blue,#0x2554"

>> valign, halign:
>> Now align property control the position of current widget, instead of
>> its children, each have four values:
>> left/top
>> center
>> right/bottom
>> extend - Extend the widget to the full width/height of parent.
>>
>> margin_left, margin_right, margin_top, margin_bottom
>> This properties set the inner space reserved by the panel
>>
>> padding_left, padding_right, padding_top, padding_bottom
>> This set the outbound box of the panel
>>
>> attach_left, attach_right, attach_top, attach_bottom
>> Stick the widget to one of the border of parent, once this is set, the
>> widget is no longed controlled by the layout manager and therefore can
>> overlap with other widget.
>>
>
> This sucks. Since overlap is not properly handled it should not happen.
>
> I am not sure what is the use of this property anyway.

This can be used to implement the auto hide toolbar. We can use a
hotkey to show/hide the bar. In this case, we definitely don't want to
add the widget to the layout manger otherwise all widgets on screen
would need to be resized after the show/hide operation.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/6 Bean <bean123ch@gmail.com>:
> On Tue, Oct 6, 2009 at 7:46 PM, Michal Suchanek <hramrach@centrum.cz> wrote:

>> This is an interesting feature but I was more interested in
>> controlling the border in text mode independently of graphics mode.
>>
>> For example, I would want something like:
>>  - graphics: 3px outer space, 2px border, 16px inner space
>> (unfortunately there is no character unit usable because the character
>> size is different when measured horizontally and vertically)
>>  - text: single border using the box drawing characters, inner space
>> vertical 1character
>>
>> AFAIK this is not possible.
>
> Hi,
>
> Well, to achieve that, we need some special syntax to allow users to
> skip the border bitmaps optionally in graphic mode, perhaps something
> like this:
>
> top_left = "null,,cyan/blue,#0x250F:,,green/blue,#0x2554"

Is the hex number the number of the box drawing character?

I would prefer if the border was easier to construct in text mode
without looking up which character goes where.

I think there are these common uses for borders:

- line border in graphics, box drawing char border in text
  This is the simplest case which does not require any support media.
  This should be well supported so that creating layout that just
works is easy (think fixing grub configuration, posting on pastebin,
etc)

- bitmap border, box drawing char border in text
  This seems to be the default currently if bitmap is specified
  I wonder what the semantics would be if I had bitmap only for some
borders (ie left, right)

- bitmap border, no border in text
  This is probably also common use - the bitmap only serves to add
rounded corners or something like that. No need to replicate in text
although some special characters might fit in some cases.

Adding a flat border can be done with an additional panel if desired
and is probably not common, no need for special support.

>
>>> valign, halign:
>>> Now align property control the position of current widget, instead of
>>> its children, each have four values:
>>> left/top
>>> center
>>> right/bottom
>>> extend - Extend the widget to the full width/height of parent.
>>>
>>> margin_left, margin_right, margin_top, margin_bottom
>>> This properties set the inner space reserved by the panel
>>>
>>> padding_left, padding_right, padding_top, padding_bottom
>>> This set the outbound box of the panel
>>>
>>> attach_left, attach_right, attach_top, attach_bottom
>>> Stick the widget to one of the border of parent, once this is set, the
>>> widget is no longed controlled by the layout manager and therefore can
>>> overlap with other widget.
>>>
>>
>> This sucks. Since overlap is not properly handled it should not happen.
>>
>> I am not sure what is the use of this property anyway.
>
> This can be used to implement the auto hide toolbar. We can use a
> hotkey to show/hide the bar. In this case, we definitely don't want to
> add the widget to the layout manger otherwise all widgets on screen
> would need to be resized after the show/hide operation.
>

It could be used like that if we had the ability to show/hide
individual widgets.

I know concealable toolbars are cool but do we really need them for grub?

They are cheap in a desktop environment where the windowing system is
already present and you just write an application that hides/resizes
its window.

In grub we would have to add and maintain/support features just to
support a concealable toolbar.

And what would be the use?

grub is not a windowing environment in which you stay for a prolonged
period of time. You just boot your system and are done with it.

Admittedly, concealable toolbars are somewhat useful to hold tools
which you need occasionally but which would occupy precious screen
space while you are working on something else. This is not the case in
grub, though.

All tools that are at your disposal should be clearly visible and you
don't really need to put the effort into hiding them because it should
take about the same effort to boot your system and exit grub
completely, including its toolbars.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Add term widget.

The new demo shows two term window, one with fixed width font, one
proportion font (Times). Use tab to switch between them, press enter
to execute current line. You can use UP/DOWN key to go back to the
output history, press enter on a previous line with grub> prompt would
execute it again.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Tue, Oct 6, 2009 at 11:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/6 Bean <bean123ch@gmail.com>:
>> On Tue, Oct 6, 2009 at 7:46 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>
>>> This is an interesting feature but I was more interested in
>>> controlling the border in text mode independently of graphics mode.
>>>
>>> For example, I would want something like:
>>>  - graphics: 3px outer space, 2px border, 16px inner space
>>> (unfortunately there is no character unit usable because the character
>>> size is different when measured horizontally and vertically)
>>>  - text: single border using the box drawing characters, inner space
>>> vertical 1character
>>>
>>> AFAIK this is not possible.
>>
>> Hi,
>>
>> Well, to achieve that, we need some special syntax to allow users to
>> skip the border bitmaps optionally in graphic mode, perhaps something
>> like this:
>>
>> top_left = "null,,cyan/blue,#0x250F:,,green/blue,#0x2554"
>
> Is the hex number the number of the box drawing character?
>
> I would prefer if the border was easier to construct in text mode
> without looking up which character goes where.

Hi,

Perhaps I can add some alias.

>
> I think there are these common uses for borders:
>
> - line border in graphics, box drawing char border in text
>  This is the simplest case which does not require any support media.
>  This should be well supported so that creating layout that just
> works is easy (think fixing grub configuration, posting on pastebin,
> etc)

Yes, you can archive it with this:

top_left = ",,cyan/blue,#0x250F:,,green/blue,#0x2554"

>
> - bitmap border, box drawing char border in text
>  This seems to be the default currently if bitmap is specified
>  I wonder what the semantics would be if I had bitmap only for some
> borders (ie left, right)

Very similar to above, just add the bitmap path as first parameter
top_left = "/menu/menu_tl.png,,cyan/blue,#0x250F:/menu/select_tl.png,,green/blue,#0x2554"

>
> - bitmap border, no border in text
>  This is probably also common use - the bitmap only serves to add
> rounded corners or something like that. No need to replicate in text
> although some special characters might fit in some cases.

If the fill character is not set, it won't displayed in text mode:
top_left = "/menu/menu_tl.png:/menu/select_tl.png"

>
> Adding a flat border can be done with an additional panel if desired
> and is probably not common, no need for special support.
>
>>
>>>> valign, halign:
>>>> Now align property control the position of current widget, instead of
>>>> its children, each have four values:
>>>> left/top
>>>> center
>>>> right/bottom
>>>> extend - Extend the widget to the full width/height of parent.
>>>>
>>>> margin_left, margin_right, margin_top, margin_bottom
>>>> This properties set the inner space reserved by the panel
>>>>
>>>> padding_left, padding_right, padding_top, padding_bottom
>>>> This set the outbound box of the panel
>>>>
>>>> attach_left, attach_right, attach_top, attach_bottom
>>>> Stick the widget to one of the border of parent, once this is set, the
>>>> widget is no longed controlled by the layout manager and therefore can
>>>> overlap with other widget.
>>>>
>>>
>>> This sucks. Since overlap is not properly handled it should not happen.
>>>
>>> I am not sure what is the use of this property anyway.
>>
>> This can be used to implement the auto hide toolbar. We can use a
>> hotkey to show/hide the bar. In this case, we definitely don't want to
>> add the widget to the layout manger otherwise all widgets on screen
>> would need to be resized after the show/hide operation.
>>
>
> It could be used like that if we had the ability to show/hide
> individual widgets.
>
> I know concealable toolbars are cool but do we really need them for grub?
>
> They are cheap in a desktop environment where the windowing system is
> already present and you just write an application that hides/resizes
> its window.
>
> In grub we would have to add and maintain/support features just to
> support a concealable toolbar.
>
> And what would be the use?
>
> grub is not a windowing environment in which you stay for a prolonged
> period of time. You just boot your system and are done with it.
>
> Admittedly, concealable toolbars are somewhat useful to hold tools
> which you need occasionally but which would occupy precious screen
> space while you are working on something else. This is not the case in
> grub, though.
>
> All tools that are at your disposal should be clearly visible and you
> don't really need to put the effort into hiding them because it should
> take about the same effort to boot your system and exit grub
> completely, including its toolbars.

It can also be used to placed small widgets, like a digital clock at
the upper left corner, I guess it won't look pretty if all window have
to align leftward and downward to show it (and a lot of extra panels).
Anyway, it's not much code for the attach_* properties, I guess it
doesn't hurt to leave it there in case we find new use for them in the
future.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/6 Bean <bean123ch@gmail.com>:
> On Tue, Oct 6, 2009 at 11:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/6 Bean <bean123ch@gmail.com>:
>>> On Tue, Oct 6, 2009 at 7:46 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>
>>>> This is an interesting feature but I was more interested in
>>>> controlling the border in text mode independently of graphics mode.
>>>>
>>>> For example, I would want something like:
>>>>  - graphics: 3px outer space, 2px border, 16px inner space
>>>> (unfortunately there is no character unit usable because the character
>>>> size is different when measured horizontally and vertically)
>>>>  - text: single border using the box drawing characters, inner space
>>>> vertical 1character
>>>>
>>>> AFAIK this is not possible.
>>>
>>> Hi,
>>>
>>> Well, to achieve that, we need some special syntax to allow users to
>>> skip the border bitmaps optionally in graphic mode, perhaps something
>>> like this:
>>>
>>> top_left = "null,,cyan/blue,#0x250F:,,green/blue,#0x2554"
>>
>> Is the hex number the number of the box drawing character?
>>
>> I would prefer if the border was easier to construct in text mode
>> without looking up which character goes where.
>
> Hi,
>
> Perhaps I can add some alias.
>
>>
>> I think there are these common uses for borders:
>>
>> - line border in graphics, box drawing char border in text
>>  This is the simplest case which does not require any support media.
>>  This should be well supported so that creating layout that just
>> works is easy (think fixing grub configuration, posting on pastebin,
>> etc)
>
> Yes, you can archive it with this:
>
> top_left = ",,cyan/blue,#0x250F:,,green/blue,#0x2554"
>
>>
>> - bitmap border, box drawing char border in text
>>  This seems to be the default currently if bitmap is specified
>>  I wonder what the semantics would be if I had bitmap only for some
>> borders (ie left, right)
>
> Very similar to above, just add the bitmap path as first parameter
> top_left = "/menu/menu_tl.png,,cyan/blue,#0x250F:/menu/select_tl.png,,green/blue,#0x2554"
>
>>
>> - bitmap border, no border in text
>>  This is probably also common use - the bitmap only serves to add
>> rounded corners or something like that. No need to replicate in text
>> although some special characters might fit in some cases.
>
> If the fill character is not set, it won't displayed in text mode:
> top_left = "/menu/menu_tl.png:/menu/select_tl.png"
>
>>
>> Adding a flat border can be done with an additional panel if desired
>> and is probably not common, no need for special support.
>>
>>>
>>>>> valign, halign:
>>>>> Now align property control the position of current widget, instead of
>>>>> its children, each have four values:
>>>>> left/top
>>>>> center
>>>>> right/bottom
>>>>> extend - Extend the widget to the full width/height of parent.
>>>>>
>>>>> margin_left, margin_right, margin_top, margin_bottom
>>>>> This properties set the inner space reserved by the panel
>>>>>
>>>>> padding_left, padding_right, padding_top, padding_bottom
>>>>> This set the outbound box of the panel
>>>>>
>>>>> attach_left, attach_right, attach_top, attach_bottom
>>>>> Stick the widget to one of the border of parent, once this is set, the
>>>>> widget is no longed controlled by the layout manager and therefore can
>>>>> overlap with other widget.
>>>>>
>>>>
>>>> This sucks. Since overlap is not properly handled it should not happen.
>>>>
>>>> I am not sure what is the use of this property anyway.
>>>
>>> This can be used to implement the auto hide toolbar. We can use a
>>> hotkey to show/hide the bar. In this case, we definitely don't want to
>>> add the widget to the layout manger otherwise all widgets on screen
>>> would need to be resized after the show/hide operation.
>>>
>>
>> It could be used like that if we had the ability to show/hide
>> individual widgets.
>>
>> I know concealable toolbars are cool but do we really need them for grub?
>>
>> They are cheap in a desktop environment where the windowing system is
>> already present and you just write an application that hides/resizes
>> its window.
>>
>> In grub we would have to add and maintain/support features just to
>> support a concealable toolbar.
>>
>> And what would be the use?
>>
>> grub is not a windowing environment in which you stay for a prolonged
>> period of time. You just boot your system and are done with it.
>>
>> Admittedly, concealable toolbars are somewhat useful to hold tools
>> which you need occasionally but which would occupy precious screen
>> space while you are working on something else. This is not the case in
>> grub, though.
>>
>> All tools that are at your disposal should be clearly visible and you
>> don't really need to put the effort into hiding them because it should
>> take about the same effort to boot your system and exit grub
>> completely, including its toolbars.
>
> It can also be used to placed small widgets, like a digital clock at
> the upper left corner, I guess it won't look pretty if all window have
> to align leftward and downward to show it (and a lot of extra panels).

They have to be aligned leftwards or downwards, not both.

It also won't look pretty if the clock gets sometimes obscured by other panels.

However, the screen is not a panel so it might not force any
particular layout and placing a clock like that might be viable.
Still you have to take care not to overlap it with other panels and
leave space for it so I see little use for such placement, you can as
well put the clock in a ltr or ttb layout which automatically reserves
space for it.

Note also that the clock will likely be in UTC unless you replicate
system TZ data and settings in grub.

> Anyway, it's not much code for the attach_* properties, I guess it
> doesn't hurt to leave it there in case we find new use for them in the
> future.

It's additional code that might have bugs, the more if it is seldom used.

And it can cause bugs by its sole existence because then users of the
code can cause panels to overlap and complain that stuff broke.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

2009/10/6 Bean <bean123ch@gmail.com>:
> On Tue, Oct 6, 2009 at 11:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:

>>
>> I think there are these common uses for borders:
>>
>> - line border in graphics, box drawing char border in text
>>  This is the simplest case which does not require any support media.
>>  This should be well supported so that creating layout that just
>> works is easy (think fixing grub configuration, posting on pastebin,
>> etc)
>
> Yes, you can archive it with this:
>
> top_left = ",,cyan/blue,#0x250F:,,green/blue,#0x2554"

This gives box drawing characters in both graphics and text. Perhaps
this is an acceptable solution for single border but I would like this
to be the default grub configuration when no theme is applied and
having a distinct more precise border in graphics mode would be a
bonus.

The extend alignment does not seem to work quite well, nor does
setting absolute size and margins (which is slightly more ugly).

Thanks

Michal

[-- Attachment #2: term.0.txt --]
[-- Type: text/plain, Size: 1811 bytes --]

screen {
  background = "/menu/back.png,,blue"
  direction = left_to_right
  position = center

  panel {
    valign = extend
    halign = extend

    top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
    top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
    left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
    bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"

    term {
      padding_top = 8/0
      padding_bottom = 8/0
      padding_left = 8/1
      padding_right = 8/1
      width = 100%
      height = 100%
      color = "cyan/blue:light-gray/blue"
    }
  }

  panel {
    valign = extend
    halign = extend

    top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
    top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
    left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
    bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"

    border_width = 2/0
    border_color = brown:red


    term {
      padding_top = 8/0
      padding_bottom = 8/0
      padding_left = 8/1
      padding_right = 8/1
      width = 100%
      height = 100%
      font = "Times Regular 18"
      color = "cyan/blue:light-gray/blue"
    }
  }
}

[-- Attachment #3: term.txt --]
[-- Type: text/plain, Size: 2089 bytes --]

screen {
  background = "/menu/back.png,,blue"
  direction = left_to_right
  position = center
  padding_top = 15/0
  padding_left = 15/0
  padding_right = 15/0
  padding_bottom = 15/0

  panel {
    width = 50%
    height = 100%
    margin_top = 15/0
    margin_bottom = 15/0
    margin_left = 15/1
    margin_right = 15/1

    top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
    top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
    left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
    bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"

    term {
      padding_top = 8/0
      padding_bottom = 8/0
      padding_left = 8/1
      padding_right = 8/1
      width = 100%
      height = 100%
      color = "cyan/blue:light-gray/blue"
    }
  }

  panel {
    width = 50%
    height = 100%
    margin_top = 15/0
    margin_bottom = 15/0
    margin_left = 15/1
    margin_right = 15/1

    top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
    top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
    left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
    bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"

    border_width = 2/0
    border_color = brown:red


    term {
      padding_top = 8/0
      padding_bottom = 8/0
      padding_left = 8/1
      padding_right = 8/1
      width = 100%
      height = 100%
      font = "Times Regular 18"
      color = "cyan/blue:light-gray/blue"
    }
  }
}

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

2009/10/6 Bean <bean123ch@gmail.com>:
> On Tue, Oct 6, 2009 at 11:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:

>>
>> I think there are these common uses for borders:
>>
>> - line border in graphics, box drawing char border in text
>>  This is the simplest case which does not require any support media.
>>  This should be well supported so that creating layout that just
>> works is easy (think fixing grub configuration, posting on pastebin,
>> etc)
>
> Yes, you can archive it with this:
>
> top_left = ",,cyan/blue,#0x250F:,,green/blue,#0x2554"

This gives box drawing characters in both graphics and text. Perhaps
this is an acceptable solution for single border but I would like this
to be the default grub configuration when no theme is applied and
having a distinct more precise border in graphics mode would be a
bonus.

The extend alignment does not seem to work quite well, nor does
setting absolute size and margins (which is slightly more ugly).

Thanks

Michal

[-- Attachment #2: term.0.txt --]
[-- Type: text/plain, Size: 1811 bytes --]

screen {
  background = "/menu/back.png,,blue"
  direction = left_to_right
  position = center

  panel {
    valign = extend
    halign = extend

    top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
    top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
    left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
    bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"

    term {
      padding_top = 8/0
      padding_bottom = 8/0
      padding_left = 8/1
      padding_right = 8/1
      width = 100%
      height = 100%
      color = "cyan/blue:light-gray/blue"
    }
  }

  panel {
    valign = extend
    halign = extend

    top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
    top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
    left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
    bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"

    border_width = 2/0
    border_color = brown:red


    term {
      padding_top = 8/0
      padding_bottom = 8/0
      padding_left = 8/1
      padding_right = 8/1
      width = 100%
      height = 100%
      font = "Times Regular 18"
      color = "cyan/blue:light-gray/blue"
    }
  }
}

[-- Attachment #3: term.txt --]
[-- Type: text/plain, Size: 2089 bytes --]

screen {
  background = "/menu/back.png,,blue"
  direction = left_to_right
  position = center
  padding_top = 15/0
  padding_left = 15/0
  padding_right = 15/0
  padding_bottom = 15/0

  panel {
    width = 50%
    height = 100%
    margin_top = 15/0
    margin_bottom = 15/0
    margin_left = 15/1
    margin_right = 15/1

    top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
    top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
    left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
    bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"

    term {
      padding_top = 8/0
      padding_bottom = 8/0
      padding_left = 8/1
      padding_right = 8/1
      width = 100%
      height = 100%
      color = "cyan/blue:light-gray/blue"
    }
  }

  panel {
    width = 50%
    height = 100%
    margin_top = 15/0
    margin_bottom = 15/0
    margin_left = 15/1
    margin_right = 15/1

    top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
    top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
    left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
    bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"

    border_width = 2/0
    border_color = brown:red


    term {
      padding_top = 8/0
      padding_bottom = 8/0
      padding_left = 8/1
      padding_right = 8/1
      width = 100%
      height = 100%
      font = "Times Regular 18"
      color = "cyan/blue:light-gray/blue"
    }
  }
}

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Wed, Oct 7, 2009 at 6:16 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/6 Bean <bean123ch@gmail.com>:
>> On Tue, Oct 6, 2009 at 11:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>
>>>
>>> I think there are these common uses for borders:
>>>
>>> - line border in graphics, box drawing char border in text
>>>  This is the simplest case which does not require any support media.
>>>  This should be well supported so that creating layout that just
>>> works is easy (think fixing grub configuration, posting on pastebin,
>>> etc)
>>
>> Yes, you can archive it with this:
>>
>> top_left = ",,cyan/blue,#0x250F:,,green/blue,#0x2554"
>
> This gives box drawing characters in both graphics and text. Perhaps
> this is an acceptable solution for single border but I would like this
> to be the default grub configuration when no theme is applied and
> having a distinct more precise border in graphics mode would be a
> bonus.
>
> The extend alignment does not seem to work quite well, nor does
> setting absolute size and margins (which is slightly more ugly).

Hi,

The extend attribute extends  in the orthogonal direction, for example

screen
{
  direction = "left_to_right"
  panel { width=50% id="aa"  valign=top }
  panel { width=50% id="bb" valign=extend}
}

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/7 Bean <bean123ch@gmail.com>:
> On Wed, Oct 7, 2009 at 6:16 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/6 Bean <bean123ch@gmail.com>:
>>> On Tue, Oct 6, 2009 at 11:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>
>>>>
>>>> I think there are these common uses for borders:
>>>>
>>>> - line border in graphics, box drawing char border in text
>>>>  This is the simplest case which does not require any support media.
>>>>  This should be well supported so that creating layout that just
>>>> works is easy (think fixing grub configuration, posting on pastebin,
>>>> etc)
>>>
>>> Yes, you can archive it with this:
>>>
>>> top_left = ",,cyan/blue,#0x250F:,,green/blue,#0x2554"
>>
>> This gives box drawing characters in both graphics and text. Perhaps
>> this is an acceptable solution for single border but I would like this
>> to be the default grub configuration when no theme is applied and
>> having a distinct more precise border in graphics mode would be a
>> bonus.
>>
>> The extend alignment does not seem to work quite well, nor does
>> setting absolute size and margins (which is slightly more ugly).
>
> Hi,
>
> The extend attribute extends  in the orthogonal direction, for example
>
> screen
> {
>  direction = "left_to_right"
>  panel { width=50% id="aa"  valign=top }
>  panel { width=50% id="bb" valign=extend}
> }
>

This might make switching the direction of a panel more difficult but
there may be other issues. Either way the method with margin does not
work either.

Thanks

Mchal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Support align in both direction, for example, this works now:

screen {
  direction = left_to_right
  position = center

  panel { valign = extend halign = extend }
  panel { valign = extend halign = extend }
  }
}

The distributed of extra space is based on direction and position:
direction = left_to_right
position = near
space is added to the rightmost widget

direction = left_to_right
position = center
space is distributed evenly

direction = left_to_right
position = far
space is added to the leftmost widget

Remove hspace and vspace, as they're duplicated with margin
properties, add space property which is the reserved space between two
widgets.

Image now support the following modes:

top_left = "/menu/menu_tl.png,,black/cyan,#0x250F:/menu/select_tl.png,,black/green,#0x2554"
Load bitmap in graphic mode, use box char in text mode,

top_left = ",,black/cyan,#0x250F:,,black/green,#0x2554"
Use box char in both graphic and text mode

top_left = "/menu/menu_tl.png:/menu/select_tl.png"
Load bitmap in graphic mode, empty in text mode

top_left = "none,,black/cyan,#0x250F:none,,black/green,#0x2554"
Use box char in text mode, empty in graphic mode

Text widget support new property gfx_text, which can be used to
displayed different text in graphic and text mode:

text { text = "text mode" gfx_text="gfx mode" }

Fix a few issue in edit/term widget, now it support the
pageup/pagedown key, and backspace at the beginning of line would
merge the current line with previous one.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Wed, Oct 7, 2009 at 4:54 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> This might make switching the direction of a panel more difficult but
> there may be other issues. Either way the method with margin does not
> work either.

Hi,

The latest version should work now, although there is a small issue,
the margin_*, padding_* property only works for panel widget for now,
so you should replace padding_* of the term with margin_* of parent
panel.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/7 Bean <bean123ch@gmail.com>:
> On Wed, Oct 7, 2009 at 4:54 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> This might make switching the direction of a panel more difficult but
>> there may be other issues. Either way the method with margin does not
>> work either.
>
> Hi,
>
> The latest version should work now, although there is a small issue,
> the margin_*, padding_* property only works for panel widget for now,
> so you should replace padding_* of the term with margin_* of parent
> panel.

Yes, spacing on panels should be sufficient.

Terminals probably would not have borders and such anyway.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

2009/10/7 Michal Suchanek <hramrach@centrum.cz>:
> 2009/10/7 Bean <bean123ch@gmail.com>:
>> On Wed, Oct 7, 2009 at 4:54 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> This might make switching the direction of a panel more difficult but
>>> there may be other issues. Either way the method with margin does not
>>> work either.
>>
>> Hi,
>>
>> The latest version should work now, although there is a small issue,
>> the margin_*, padding_* property only works for panel widget for now,
>> so you should replace padding_* of the term with margin_* of parent
>> panel.

I tired the latest code and there is still some alignment issue.

In graphics mode the top and bottom part of border is missing.

The problem with zero width panels is fixed but a layout with a
"toolbar" does not really work for me.

Thanks

Michal

[-- Attachment #2: term.txt --]
[-- Type: text/plain, Size: 3060 bytes --]

screen {
    background = "/menu/back.png,,blue"
      direction = bottom_to_top
      panel {
          height = 1c

            top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
            top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
            top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
            left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
            right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
            bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
            bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
            bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"
      }
    panel {
        direction = left_to_right
          position = center
          valign = extend
          halign = extend

          panel {
              valign = extend
                halign = extend

                top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
                top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
                top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
                left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
                right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
                bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
                bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
                bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"
                padding_top = 8/0
                padding_bottom = 8/0
                padding_left = 8/1
                padding_right = 8/1

                term {
                    width = 100%
                      height = 100%
                      color = "cyan/blue:light-gray/blue"
                }
          }

        panel {
            valign = extend
              halign = extend

              top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
              top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
              top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
              left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
              right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
              bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
              bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
              bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"

              border_width = 2/0
              border_color = brown:red

              padding_top = 8/0
              padding_bottom = 8/0
              padding_left = 8/1
              padding_right = 8/1

              term {
                  width = 100%
                    height = 100%
                    font = "Times Regular 18"
                    color = "cyan/blue:light-gray/blue"
              }
        }
    }

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Oct 8, 2009 at 5:13 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/7 Michal Suchanek <hramrach@centrum.cz>:
>> 2009/10/7 Bean <bean123ch@gmail.com>:
>>> On Wed, Oct 7, 2009 at 4:54 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> This might make switching the direction of a panel more difficult but
>>>> there may be other issues. Either way the method with margin does not
>>>> work either.
>>>
>>> Hi,
>>>
>>> The latest version should work now, although there is a small issue,
>>> the margin_*, padding_* property only works for panel widget for now,
>>> so you should replace padding_* of the term with margin_* of parent
>>> panel.
>
> I tired the latest code and there is still some alignment issue.
>
> In graphics mode the top and bottom part of border is missing.
>
> The problem with zero width panels is fixed but a layout with a
> "toolbar" does not really work for me.

Hi,

Some issue of the config:

1, Don't add the c suffix , now default unit is character, just use
number. Also, if you set height/width directly, it should include the
border size, so minimum value is 2 (for top and bottom rect).

2, You should use far position as you want to extend the widget at the
far side (top).

3, border_width only draws left/right border, to draw top/bottom
border, you need to add border_height as well.

This config should work:

screen {
   background = "/menu/back.png,,blue"
   direction = bottom_to_top
   position = far

   panel {
     height = 2
     halign = extend

     top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
     top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
     top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
     left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
     right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
     bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
     bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
     bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"
   }

   panel {
     direction = left_to_right
     position = center
     valign = extend
     halign = extend

     panel {
       valign = extend
       halign = extend

       top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
       top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
       top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
       left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
       right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
       bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
       bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
       bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"
       padding_top = 8/0
       padding_bottom = 8/0
       padding_left = 8/1
       padding_right = 8/1

       term {
         width = 100%
         height = 100%
         color = "cyan/blue:light-gray/blue"
       }
     }

     panel {
       valign = extend
       halign = extend

       top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
       top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
       top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
       left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
       right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
       bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
       bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
       bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"

       border_width = 2/0
       border_height = 2/0
       border_color = brown:red

       padding_top = 8/0
       padding_bottom = 8/0
       padding_left = 8/1
       padding_right = 8/1

       term {
         width = 100%
         height = 100%
         font = "Times Regular 18"
         color = "cyan/blue:light-gray/blue"
       }
     }
   }
}
-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Rename position to extend, values are:
first: extend the first child widget (near)
all: extend all children widgets
last: extend the last child widget (far), this is default value if not set

For example:
direction = left_to_right
extend = all

Add style support, each widget has style property, if it's set, menu
would looks through the style section for additional property, for
example:

screen {
  background = "/menu/back.png,,blue"
  direction = bottom_to_top

  panel {
    height = 2
    halign = extend
    style = text_border
  }

  panel {
    direction = left_to_right
    extend = all
    valign = extend
    halign = extend

    panel {
      valign = extend
      halign = extend
      style = text_border,padding

      term {
        width = 100%
        height = 100%
      }
    }

    panel {
      valign = extend
      halign = extend
      style = text_border,padding
      border_width = 2/0
      border_height = 2/0
      border_color = brown:red

      term {
        width = 100%
        height = 100%
        font = "Times Regular 18"
      }
    }
  }
}

style {
  text_border {
    top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
    top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
    left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
    bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
    bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
    bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"
  }

  padding {
    padding_top = 8/0
    padding_bottom = 8/0
    padding_left = 8/1
    padding_right = 8/1
  }

  term {
    color = "cyan/blue:light-gray/blue"
  }
}

panel that has "style = text_border,padding" would inherit the
properties in text_border and padding section. If style is not set, it
would search the section with the same class name (term for instance).

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/8 Bean <bean123ch@gmail.com>:
> On Thu, Oct 8, 2009 at 5:13 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/7 Michal Suchanek <hramrach@centrum.cz>:
>>> 2009/10/7 Bean <bean123ch@gmail.com>:
>>>> On Wed, Oct 7, 2009 at 4:54 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>> This might make switching the direction of a panel more difficult but
>>>>> there may be other issues. Either way the method with margin does not
>>>>> work either.
>>>>
>>>> Hi,
>>>>
>>>> The latest version should work now, although there is a small issue,
>>>> the margin_*, padding_* property only works for panel widget for now,
>>>> so you should replace padding_* of the term with margin_* of parent
>>>> panel.
>>
>> I tired the latest code and there is still some alignment issue.
>>
>> In graphics mode the top and bottom part of border is missing.
>>
>> The problem with zero width panels is fixed but a layout with a
>> "toolbar" does not really work for me.
>
> Hi,
>
> Some issue of the config:
>
> 1, Don't add the c suffix , now default unit is character, just use

It should be possible to use the c suffix even if it is the default.

> number. Also, if you set height/width directly, it should include the
> border size, so minimum value is 2 (for top and bottom rect).

Indeed, the width should include the border which is currently quite large.

>
> 2, You should use far position as you want to extend the widget at the
> far side (top).

This dependency is a problem. The rules for creating a working layout
are then complicated and hard to understand.

Also I have no idea why I should set position on the screen, it is
never positioned.

>
> 3, border_width only draws left/right border, to draw top/bottom
> border, you need to add border_height as well.

That's quite surprising. In other layout systems I have seen so far there is
 - border width (of all borders)
 - border top/left/bottom/right width (for particular borders,
sometimes not available)

It would be useful to have aliases for margin and padding so that
vertical./horizontal/all can be set in one assignment.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/8 Bean <bean123ch@gmail.com>:
> Hi,
>
> Update:
>
> Rename position to extend, values are:
> first: extend the first child widget (near)
> all: extend all children widgets
> last: extend the last child widget (far), this is default value if not set
>
> For example:
> direction = left_to_right
> extend = all
>
> Add style support, each widget has style property, if it's set, menu
> would looks through the style section for additional property, for
> example:
>
> screen {
>  background = "/menu/back.png,,blue"
>  direction = bottom_to_top
>
>  panel {
>    height = 2
>    halign = extend
>    style = text_border
>  }
>
>  panel {
>    direction = left_to_right
>    extend = all
>    valign = extend
>    halign = extend
>
>    panel {
>      valign = extend
>      halign = extend
>      style = text_border,padding
>
>      term {
>        width = 100%
>        height = 100%
>      }
>    }
>
>    panel {
>      valign = extend
>      halign = extend
>      style = text_border,padding
>      border_width = 2/0
>      border_height = 2/0
>      border_color = brown:red
>
>      term {
>        width = 100%
>        height = 100%
>        font = "Times Regular 18"
>      }
>    }
>  }
> }
>
> style {
>  text_border {
>    top_left = ",,cyan/blue,#0x250F:,,light-gray/blue,#0x2554"
>    top = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
>    top_right = ",,cyan/blue,#0x2513:,,light-gray/blue,#0x2557"
>    left = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
>    right = ",tiling,cyan/blue,#0x2503:,,light-gray/blue,#0x2551"
>    bottom_left = ",,cyan/blue,#0x2517:,,light-gray/blue,#0x255A"
>    bottom = ",tiling,cyan/blue,#0x2501:,,light-gray/blue,#0x2550"
>    bottom_right = ",tiling,cyan/blue,#0x251B:,,light-gray/blue,#0x255D"
>  }
>
>  padding {
>    padding_top = 8/0
>    padding_bottom = 8/0
>    padding_left = 8/1
>    padding_right = 8/1
>  }
>
>  term {
>    color = "cyan/blue:light-gray/blue"
>  }
> }
>
> panel that has "style = text_border,padding" would inherit the
> properties in text_border and padding section. If style is not set, it
> would search the section with the same class name (term for instance).
>

I am not sure this is the right approach.

Style writers should be free to style any widget without special
support in the widget.

If there is special styling property it should not refer to a
particular visual representation. They should specify the purpose of
the widget and the style should decide how widgets of that type are
visually realized.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Oct 8, 2009 at 7:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2, You should use far position as you want to extend the widget at the
>> far side (top).
>
> This dependency is a problem. The rules for creating a working layout
> are then complicated and hard to understand.
>
> Also I have no idea why I should set position on the screen, it is
> never positioned.

Hi,

For example, if parent width=10, two children, width=4, then the
extend property decide how to assign the extra 2 space:

extend=first, space is added to first widget, which is 6,4
extend=all, space is distributed to alls widget, which is 5,5
extend=last, space is added to last widget, which is 4,6

This is different than the halign property of children, which indicate
how it uses the extra space, for example, when extend=first, the first
widget gets two extra space, halign can be:

left: starts at 0, width=4
center: starts at 1, width=4
right: starts at 2, width=4
extend: starts at 0, width=6

>
>>
>> 3, border_width only draws left/right border, to draw top/bottom
>> border, you need to add border_height as well.
>
> That's quite surprising. In other layout systems I have seen so far there is
>  - border width (of all borders)
>  - border top/left/bottom/right width (for particular borders,
> sometimes not available)
>
> It would be useful to have aliases for margin and padding so that
> vertical./horizontal/all can be set in one assignment.

Right, I can use border_top/border_left/border_right/border_bottom to
control four different borders, if users want to set all of them at
the same time, he can use border_size.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Oct 8, 2009 at 7:26 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> I am not sure this is the right approach.
>
> Style writers should be free to style any widget without special
> support in the widget.

Hi,

The style property is parsed by the menu system, no special handling
for individual widgets.

>
> If there is special styling property it should not refer to a
> particular visual representation. They should specify the purpose of
> the widget and the style should decide how widgets of that type are
> visually realized.

In order to support this, I can just add recursive handling to the
style section, something like this:

screen { panel { style=dialog }}

style
{
  frame {
  }
  padding {
  }
  dialog {
    style=frame,padding
  }
}

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/8 Bean <bean123ch@gmail.com>:
> On Thu, Oct 8, 2009 at 7:26 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> I am not sure this is the right approach.
>>
>> Style writers should be free to style any widget without special
>> support in the widget.
>
> Hi,
>
> The style property is parsed by the menu system, no special handling
> for individual widgets.
>
>>
>> If there is special styling property it should not refer to a
>> particular visual representation. They should specify the purpose of
>> the widget and the style should decide how widgets of that type are
>> visually realized.
>
> In order to support this, I can just add recursive handling to the
> style section, something like this:
>
> screen { panel { style=dialog }}
>
> style
> {
>  frame {
>  }
>  padding {
>  }
>  dialog {
>    style=frame,padding
>  }
> }
>

This is backwards. At first you want some separation of model and view
and now you want to apply style only to elements that are explicitly
styled.

Every element should have its default style which can be further
modified by changing its properties through styling.

There should be no need for the element to have any additional
property for it to be affected by styles.
There should be a way to assign additional identification to elements
so that they can be affected by more specific style.

In X *foreground: yellow and *background: MidnightBlue changes the
color on each and every element for which there is no more specific
color declaration. Similarly in CSS * { color: black ; background:
white ;} changes the properties of all elements.

The class is used only to target some elements more specifically.
For example, in gfxterm it would be probably useful to add specific
class (or similar property) to menu items that correspond  to linux
kernels so that they can be styled differently from the other menu
items.

The problem with splitting text and image into separate widgets is
that the image cannot be attached as icon property in  this case but I
guess bitmap borders will work equally well.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/8 Bean <bean123ch@gmail.com>:
> On Thu, Oct 8, 2009 at 7:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> 2, You should use far position as you want to extend the widget at the
>>> far side (top).
>>
>> This dependency is a problem. The rules for creating a working layout
>> are then complicated and hard to understand.
>>
>> Also I have no idea why I should set position on the screen, it is
>> never positioned.
>
> Hi,
>
> For example, if parent width=10, two children, width=4, then the
> extend property decide how to assign the extra 2 space:
>
> extend=first, space is added to first widget, which is 6,4
> extend=all, space is distributed to alls widget, which is 5,5
> extend=last, space is added to last widget, which is 4,6

This should not be necessary. The default is to wrap the children with
any spacing the children specify.  This should work nicely for layouts
similar to the current gfxterm.

If the panel is larger (because it is itself extended or fixed-width)
then children are packed at the start (which is determined by
direction). This should work nicely for buttons in a dialog box, for
example. If a dialog has two buttons they should be placed together,
placing one on each end can easily lead to situation when the user
notices only one of the buttons.

If you want to explicitly control which children get the available
space then finer granularity is again achieved by setting properties
on the chidren. Any child that has the expand property will take a
share of the surplus space. If you want children to take space without
growing add another property which specifies that the space should be
taken without expanding the element.

For example, gtk2 has properties expand and fill. Expand means that
the element will take surplus space and fill means that the element
enlarges to fill the surplus space.

With these properties you can specify that third element out of four
can get extra space which is not available with extend property on the
parent. It is also more natural because you set the properties on the
element you want to grow together with its other dimensions.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Fri, Oct 9, 2009 at 5:46 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/8 Bean <bean123ch@gmail.com>:
>> On Thu, Oct 8, 2009 at 7:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> 2, You should use far position as you want to extend the widget at the
>>>> far side (top).
>>>
>>> This dependency is a problem. The rules for creating a working layout
>>> are then complicated and hard to understand.
>>>
>>> Also I have no idea why I should set position on the screen, it is
>>> never positioned.
>>
>> Hi,
>>
>> For example, if parent width=10, two children, width=4, then the
>> extend property decide how to assign the extra 2 space:
>>
>> extend=first, space is added to first widget, which is 6,4
>> extend=all, space is distributed to alls widget, which is 5,5
>> extend=last, space is added to last widget, which is 4,6
>
> This should not be necessary. The default is to wrap the children with
> any spacing the children specify.  This should work nicely for layouts
> similar to the current gfxterm.
>
> If the panel is larger (because it is itself extended or fixed-width)
> then children are packed at the start (which is determined by
> direction). This should work nicely for buttons in a dialog box, for
> example. If a dialog has two buttons they should be placed together,
> placing one on each end can easily lead to situation when the user
> notices only one of the buttons.
>
> If you want to explicitly control which children get the available
> space then finer granularity is again achieved by setting properties
> on the chidren. Any child that has the expand property will take a
> share of the surplus space. If you want children to take space without
> growing add another property which specifies that the space should be
> taken without expanding the element.

Hi,

What if more than one children has the extend property, for example,
how do we handle config like this:

panel {
  panel { halign="extend" }
  panel { }
  panel { halign="extend"}
  panel { }
}


>
> For example, gtk2 has properties expand and fill. Expand means that
> the element will take surplus space and fill means that the element
> enlarges to fill the surplus space.
>
> With these properties you can specify that third element out of four
> can get extra space which is not available with extend property on the
> parent. It is also more natural because you set the properties on the
> element you want to grow together with its other dimensions.
>
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Fri, Oct 9, 2009 at 5:34 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/8 Bean <bean123ch@gmail.com>:
>> On Thu, Oct 8, 2009 at 7:26 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> I am not sure this is the right approach.
>>>
>>> Style writers should be free to style any widget without special
>>> support in the widget.
>>
>> Hi,
>>
>> The style property is parsed by the menu system, no special handling
>> for individual widgets.
>>
>>>
>>> If there is special styling property it should not refer to a
>>> particular visual representation. They should specify the purpose of
>>> the widget and the style should decide how widgets of that type are
>>> visually realized.
>>
>> In order to support this, I can just add recursive handling to the
>> style section, something like this:
>>
>> screen { panel { style=dialog }}
>>
>> style
>> {
>>  frame {
>>  }
>>  padding {
>>  }
>>  dialog {
>>    style=frame,padding
>>  }
>> }
>>
>
> This is backwards. At first you want some separation of model and view
> and now you want to apply style only to elements that are explicitly
> styled.
>
> Every element should have its default style which can be further
> modified by changing its properties through styling.
>
> There should be no need for the element to have any additional
> property for it to be affected by styles.
> There should be a way to assign additional identification to elements
> so that they can be affected by more specific style.
>
> In X *foreground: yellow and *background: MidnightBlue changes the
> color on each and every element for which there is no more specific
> color declaration. Similarly in CSS * { color: black ; background:
> white ;} changes the properties of all elements.
>
> The class is used only to target some elements more specifically.
> For example, in gfxterm it would be probably useful to add specific
> class (or similar property) to menu items that correspond  to linux
> kernels so that they can be styled differently from the other menu
> items.
>
> The problem with splitting text and image into separate widgets is
> that the image cannot be attached as icon property in  this case but I
> guess bitmap borders will work equally well.

Hi,

The main reason for style is to customized ui independent of code, for
example, to show a message box, we might use something like this in
code:

popup { style=dialog.message text { text="Hello" }}

Users can write a dialog.message section to customize the look of
dialog box without changing the code.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/9 Bean <bean123ch@gmail.com>:
> On Fri, Oct 9, 2009 at 5:46 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/8 Bean <bean123ch@gmail.com>:
>>> On Thu, Oct 8, 2009 at 7:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>> 2, You should use far position as you want to extend the widget at the
>>>>> far side (top).
>>>>
>>>> This dependency is a problem. The rules for creating a working layout
>>>> are then complicated and hard to understand.
>>>>
>>>> Also I have no idea why I should set position on the screen, it is
>>>> never positioned.
>>>
>>> Hi,
>>>
>>> For example, if parent width=10, two children, width=4, then the
>>> extend property decide how to assign the extra 2 space:
>>>
>>> extend=first, space is added to first widget, which is 6,4
>>> extend=all, space is distributed to alls widget, which is 5,5
>>> extend=last, space is added to last widget, which is 4,6
>>
>> This should not be necessary. The default is to wrap the children with
>> any spacing the children specify.  This should work nicely for layouts
>> similar to the current gfxterm.
>>
>> If the panel is larger (because it is itself extended or fixed-width)
>> then children are packed at the start (which is determined by
>> direction). This should work nicely for buttons in a dialog box, for
>> example. If a dialog has two buttons they should be placed together,
>> placing one on each end can easily lead to situation when the user
>> notices only one of the buttons.
>>
>> If you want to explicitly control which children get the available
>> space then finer granularity is again achieved by setting properties
>> on the chidren. Any child that has the expand property will take a
>> share of the surplus space. If you want children to take space without
>> growing add another property which specifies that the space should be
>> taken without expanding the element.
>
> Hi,
>
> What if more than one children has the extend property, for example,
> how do we handle config like this:
>
> panel {
>  panel { halign="extend" }
>  panel { }
>  panel { halign="extend"}
>  panel { }
> }
>
>

Then both get a share of the available space, obviously. It's similar
to your extend=all but each child can opt to get a share of the extra
space individually.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/9 Bean <bean123ch@gmail.com>:
> On Fri, Oct 9, 2009 at 5:34 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/8 Bean <bean123ch@gmail.com>:
>>> On Thu, Oct 8, 2009 at 7:26 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> I am not sure this is the right approach.
>>>>
>>>> Style writers should be free to style any widget without special
>>>> support in the widget.
>>>
>>> Hi,
>>>
>>> The style property is parsed by the menu system, no special handling
>>> for individual widgets.
>>>
>>>>
>>>> If there is special styling property it should not refer to a
>>>> particular visual representation. They should specify the purpose of
>>>> the widget and the style should decide how widgets of that type are
>>>> visually realized.
>>>
>>> In order to support this, I can just add recursive handling to the
>>> style section, something like this:
>>>
>>> screen { panel { style=dialog }}
>>>
>>> style
>>> {
>>>  frame {
>>>  }
>>>  padding {
>>>  }
>>>  dialog {
>>>    style=frame,padding
>>>  }
>>> }
>>>
>>
>> This is backwards. At first you want some separation of model and view
>> and now you want to apply style only to elements that are explicitly
>> styled.
>>
>> Every element should have its default style which can be further
>> modified by changing its properties through styling.
>>
>> There should be no need for the element to have any additional
>> property for it to be affected by styles.
>> There should be a way to assign additional identification to elements
>> so that they can be affected by more specific style.
>>
>> In X *foreground: yellow and *background: MidnightBlue changes the
>> color on each and every element for which there is no more specific
>> color declaration. Similarly in CSS * { color: black ; background:
>> white ;} changes the properties of all elements.
>>
>> The class is used only to target some elements more specifically.
>> For example, in gfxterm it would be probably useful to add specific
>> class (or similar property) to menu items that correspond  to linux
>> kernels so that they can be styled differently from the other menu
>> items.
>>
>> The problem with splitting text and image into separate widgets is
>> that the image cannot be attached as icon property in  this case but I
>> guess bitmap borders will work equally well.
>
> Hi,
>
> The main reason for style is to customized ui independent of code, for
> example, to show a message box, we might use something like this in
> code:
>
> popup { style=dialog.message text { text="Hello" }}
>
> Users can write a dialog.message section to customize the look of
> dialog box without changing the code.
>

Yes, that's nice to name the dialog so that it can be styled more easily.

However, the text has no style assigned. Still the user should be able
to do something like

popup text { font-face: sans }

or

 .dialog.mesasge text { font-face: sans }

to override the font used in the dialog although the text element is
not explicitly linked to any style.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Fri, Oct 9, 2009 at 7:48 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/9 Bean <bean123ch@gmail.com>:
>> On Fri, Oct 9, 2009 at 5:46 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> 2009/10/8 Bean <bean123ch@gmail.com>:
>>>> On Thu, Oct 8, 2009 at 7:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>>> 2, You should use far position as you want to extend the widget at the
>>>>>> far side (top).
>>>>>
>>>>> This dependency is a problem. The rules for creating a working layout
>>>>> are then complicated and hard to understand.
>>>>>
>>>>> Also I have no idea why I should set position on the screen, it is
>>>>> never positioned.
>>>>
>>>> Hi,
>>>>
>>>> For example, if parent width=10, two children, width=4, then the
>>>> extend property decide how to assign the extra 2 space:
>>>>
>>>> extend=first, space is added to first widget, which is 6,4
>>>> extend=all, space is distributed to alls widget, which is 5,5
>>>> extend=last, space is added to last widget, which is 4,6
>>>
>>> This should not be necessary. The default is to wrap the children with
>>> any spacing the children specify.  This should work nicely for layouts
>>> similar to the current gfxterm.
>>>
>>> If the panel is larger (because it is itself extended or fixed-width)
>>> then children are packed at the start (which is determined by
>>> direction). This should work nicely for buttons in a dialog box, for
>>> example. If a dialog has two buttons they should be placed together,
>>> placing one on each end can easily lead to situation when the user
>>> notices only one of the buttons.
>>>
>>> If you want to explicitly control which children get the available
>>> space then finer granularity is again achieved by setting properties
>>> on the chidren. Any child that has the expand property will take a
>>> share of the surplus space. If you want children to take space without
>>> growing add another property which specifies that the space should be
>>> taken without expanding the element.
>>
>> Hi,
>>
>> What if more than one children has the extend property, for example,
>> how do we handle config like this:
>>
>> panel {
>>  panel { halign="extend" }
>>  panel { }
>>  panel { halign="extend"}
>>  panel { }
>> }
>>
>>
>
> Then both get a share of the available space, obviously. It's similar
> to your extend=all but each child can opt to get a share of the extra
> space individually.

Hi,

Ok, fine with me.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Fri, Oct 9, 2009 at 7:52 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> Yes, that's nice to name the dialog so that it can be styled more easily.
>
> However, the text has no style assigned. Still the user should be able
> to do something like
>
> popup text { font-face: sans }
>
> or
>
>  .dialog.mesasge text { font-face: sans }
>
> to override the font used in the dialog although the text element is
> not explicitly linked to any style.

Hi,

Oh, perhaps the name style is not very appropriate here, class may be
a better one. As for the sub element, it can be handle it like this:

panel { class=dialog.message text { text="Hello" }}

class
{
  dialog.message
  {
    background = "/back.png"
    color="blue"
  }
}

All widgets under the panel would looks in the dialog.message section
for default property, this is similar to Xterm*color in Xresource.
This method also make it easier to define a menu item:

panel { class=menu.debian image {} text {}}

class
{
  menu.debian
  {
    image = "/debian.png"
    text = "Boot debian"
  }
}


-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/9 Bean <bean123ch@gmail.com>:
> On Fri, Oct 9, 2009 at 7:52 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> Yes, that's nice to name the dialog so that it can be styled more easily.
>>
>> However, the text has no style assigned. Still the user should be able
>> to do something like
>>
>> popup text { font-face: sans }
>>
>> or
>>
>>  .dialog.mesasge text { font-face: sans }
>>
>> to override the font used in the dialog although the text element is
>> not explicitly linked to any style.
>
> Hi,
>
> Oh, perhaps the name style is not very appropriate here, class may be
> a better one. As for the sub element, it can be handle it like this:
>
> panel { class=dialog.message text { text="Hello" }}
>
> class
> {
>  dialog.message
>  {
>    background = "/back.png"
>    color="blue"
>  }
> }
>
> All widgets under the panel would looks in the dialog.message section
> for default property, this is similar to Xterm*color in Xresource.
> This method also make it easier to define a menu item:
>
> panel { class=menu.debian image {} text {}}
>
> class
> {
>  menu.debian
>  {
>    image = "/debian.png"
>    text = "Boot debian"
>  }
> }
>

I don't understand what is what in this example. Which part is the style here?

In my mind there are two separate parts of the menu.

1) the content - text and icons separated into logical groups

2) style which specifies how these logical groups are rendered

By now we have enough styling properties that adding a style to bare
widget tree should not require meaningless elements. The unit of user
visible focus focus is a panel and the unit of content is an edit,
text or bitmap.

It is natural then that a panel is used to group several content
elements (text and edit or bitmap) that represent aspects of a single
action into a single panel and group related panels (such as the boot
menu items in current gfxterm) into a larger panel.


The widget properties that relate to content (text, the image for
bitmap element, command/action, key shortcut) should not be affected
by style. Even if it is possible right now we should forbid it for
consistency and security reasons. Localization should be applied while
generating the layout, possibly by generating the layout in multiple
languages and allowing to switch between languages.

A style should be generally applicable to any layout (mostly) without
any help from the layout author. You can add user styles to your
browser to fix style problems on existing sites, for example. I think
in grub we do not need this level of control, it's fine if loading a
new style completely replaces (rather than amends) the previous style.

Still applying a style should not rely on every element having a class
wherever the style is to change.

For example, it is not possible to identify a toplevel panel of a
dialog without setting a class on it. On the other hand, setting a
class on the toplevel window should suffice for styling each and every
element of the dialog separately without any further support from the
dialog author. Sure, marking some elements with the intended use (ie
marking all buttons in the default layouts with the same class) would
make the styling easier but it should not be a requirement.
Inheritance (= cascading) might be a nice thing but it is not required
when you can selectively apply style to anonymous elements.

Powerful selectors make it possible to amend omissions in the layout
you style so that you can download a style, apply it, and it just
works on the default layout in your distribution even if it styles the
layout differently than originally intended.  Relying on support in
the layout is error prone and limits style flexibility.


Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Fri, Oct 9, 2009 at 10:20 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/9 Bean <bean123ch@gmail.com>:
>> On Fri, Oct 9, 2009 at 7:52 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> Yes, that's nice to name the dialog so that it can be styled more easily.
>>>
>>> However, the text has no style assigned. Still the user should be able
>>> to do something like
>>>
>>> popup text { font-face: sans }
>>>
>>> or
>>>
>>>  .dialog.mesasge text { font-face: sans }
>>>
>>> to override the font used in the dialog although the text element is
>>> not explicitly linked to any style.
>>
>> Hi,
>>
>> Oh, perhaps the name style is not very appropriate here, class may be
>> a better one. As for the sub element, it can be handle it like this:
>>
>> panel { class=dialog.message text { text="Hello" }}
>>
>> class
>> {
>>  dialog.message
>>  {
>>    background = "/back.png"
>>    color="blue"
>>  }
>> }
>>
>> All widgets under the panel would looks in the dialog.message section
>> for default property, this is similar to Xterm*color in Xresource.
>> This method also make it easier to define a menu item:
>>
>> panel { class=menu.debian image {} text {}}
>>
>> class
>> {
>>  menu.debian
>>  {
>>    image = "/debian.png"
>>    text = "Boot debian"
>>  }
>> }
>>
>
> I don't understand what is what in this example. Which part is the style here?
>
> In my mind there are two separate parts of the menu.
>
> 1) the content - text and icons separated into logical groups
>
> 2) style which specifies how these logical groups are rendered
>
> By now we have enough styling properties that adding a style to bare
> widget tree should not require meaningless elements. The unit of user
> visible focus focus is a panel and the unit of content is an edit,
> text or bitmap.
>
> It is natural then that a panel is used to group several content
> elements (text and edit or bitmap) that represent aspects of a single
> action into a single panel and group related panels (such as the boot
> menu items in current gfxterm) into a larger panel.
>
>
> The widget properties that relate to content (text, the image for
> bitmap element, command/action, key shortcut) should not be affected
> by style. Even if it is possible right now we should forbid it for
> consistency and security reasons. Localization should be applied while
> generating the layout, possibly by generating the layout in multiple
> languages and allowing to switch between languages.
>
> A style should be generally applicable to any layout (mostly) without
> any help from the layout author. You can add user styles to your
> browser to fix style problems on existing sites, for example. I think
> in grub we do not need this level of control, it's fine if loading a
> new style completely replaces (rather than amends) the previous style.
>
> Still applying a style should not rely on every element having a class
> wherever the style is to change.
>
> For example, it is not possible to identify a toplevel panel of a
> dialog without setting a class on it. On the other hand, setting a
> class on the toplevel window should suffice for styling each and every
> element of the dialog separately without any further support from the
> dialog author. Sure, marking some elements with the intended use (ie
> marking all buttons in the default layouts with the same class) would
> make the styling easier but it should not be a requirement.
> Inheritance (= cascading) might be a nice thing but it is not required
> when you can selectively apply style to anonymous elements.
>
> Powerful selectors make it possible to amend omissions in the layout
> you style so that you can download a style, apply it, and it just
> works on the default layout in your distribution even if it styles the
> layout differently than originally intended.  Relying on support in
> the layout is error prone and limits style flexibility.

Hi,

I'm not sure what interface you're suggesting. Currently, class
property is optional, if it's not set, it would use the class name to
scan for default property, like:

panel {}
panel { class=menu }

class
{
  panel {}
  menu {}
}

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/9 Bean <bean123ch@gmail.com>:
> On Fri, Oct 9, 2009 at 10:20 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/9 Bean <bean123ch@gmail.com>:
>>> On Fri, Oct 9, 2009 at 7:52 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> Yes, that's nice to name the dialog so that it can be styled more easily.
>>>>
>>>> However, the text has no style assigned. Still the user should be able
>>>> to do something like
>>>>
>>>> popup text { font-face: sans }
>>>>
>>>> or
>>>>
>>>>  .dialog.mesasge text { font-face: sans }
>>>>
>>>> to override the font used in the dialog although the text element is
>>>> not explicitly linked to any style.
>>>
>>> Hi,
>>>
>>> Oh, perhaps the name style is not very appropriate here, class may be
>>> a better one. As for the sub element, it can be handle it like this:
>>>
>>> panel { class=dialog.message text { text="Hello" }}
>>>
>>> class
>>> {
>>>  dialog.message
>>>  {
>>>    background = "/back.png"
>>>    color="blue"
>>>  }
>>> }
>>>
>>> All widgets under the panel would looks in the dialog.message section
>>> for default property, this is similar to Xterm*color in Xresource.
>>> This method also make it easier to define a menu item:
>>>
>>> panel { class=menu.debian image {} text {}}
>>>
>>> class
>>> {
>>>  menu.debian
>>>  {
>>>    image = "/debian.png"
>>>    text = "Boot debian"
>>>  }
>>> }
>>>
>>
>> I don't understand what is what in this example. Which part is the style here?
>>
>> In my mind there are two separate parts of the menu.
>>
>> 1) the content - text and icons separated into logical groups
>>
>> 2) style which specifies how these logical groups are rendered
>>
>> By now we have enough styling properties that adding a style to bare
>> widget tree should not require meaningless elements. The unit of user
>> visible focus focus is a panel and the unit of content is an edit,
>> text or bitmap.
>>
>> It is natural then that a panel is used to group several content
>> elements (text and edit or bitmap) that represent aspects of a single
>> action into a single panel and group related panels (such as the boot
>> menu items in current gfxterm) into a larger panel.
>>
>>
>> The widget properties that relate to content (text, the image for
>> bitmap element, command/action, key shortcut) should not be affected
>> by style. Even if it is possible right now we should forbid it for
>> consistency and security reasons. Localization should be applied while
>> generating the layout, possibly by generating the layout in multiple
>> languages and allowing to switch between languages.
>>
>> A style should be generally applicable to any layout (mostly) without
>> any help from the layout author. You can add user styles to your
>> browser to fix style problems on existing sites, for example. I think
>> in grub we do not need this level of control, it's fine if loading a
>> new style completely replaces (rather than amends) the previous style.
>>
>> Still applying a style should not rely on every element having a class
>> wherever the style is to change.
>>
>> For example, it is not possible to identify a toplevel panel of a
>> dialog without setting a class on it. On the other hand, setting a
>> class on the toplevel window should suffice for styling each and every
>> element of the dialog separately without any further support from the
>> dialog author. Sure, marking some elements with the intended use (ie
>> marking all buttons in the default layouts with the same class) would
>> make the styling easier but it should not be a requirement.
>> Inheritance (= cascading) might be a nice thing but it is not required
>> when you can selectively apply style to anonymous elements.
>>
>> Powerful selectors make it possible to amend omissions in the layout
>> you style so that you can download a style, apply it, and it just
>> works on the default layout in your distribution even if it styles the
>> layout differently than originally intended.  Relying on support in
>> the layout is error prone and limits style flexibility.
>
> Hi,
>
> I'm not sure what interface you're suggesting. Currently, class
> property is optional, if it's not set, it would use the class name to
> scan for default property, like:
>
> panel {}
> panel { class=menu }
>
> class
> {
>  panel {}
>  menu {}
> }
>

I am suggesting an interface that allows style commands like

style {

(class==button).(text==OK) { <style> }

(class==dialog).<nothing here>.(class=button) { <style> }

(class==buttonbar) { direction = right_to_left }

(class==button) {
  border_top = button_top
  border_left = button_left
 ...
}

}

for

panel { class = dialog ; direction = top_to_bottom
  panel {
   scroll = auto
    text { Blah blah blah... }
 }
 panel { class = buttonbar ;
  panel { class = button ; img { check.png } ;text { OK } ; command =
<something> }
  panel { class = button ; img { cross.png } ;text { Cancel } ;
command = <something>}
 }
}

The exact syntax and semantic of the selectors it to be defined.

They may be imperative commands that are applied immediately to all
widgets currently in existence or they may be stored in a style
database that widgets consult each time they are drawn or some
combination of the above (for example the style commands affect a
style database in order of appearance but do not affect widgets
directly).

I guess the styles that appear in the main config (grub.cfg or loaded
by loadcfg) should be added together so that scripts that generate
different parts of the file can add style bits for their widgets.

loadstyle command should reset all widget style properties to default
(either widget default or the state after loading config) and then
interpret the content of the file as if it was enclosed in style {}.

When loadstyle is repeated the widgets should be reset again so that
previous style cannot affect the newly loaded style.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Change extend property, now it should be set in the children widget,
for example, to draw a toolbar:

screen {
  direction = bottom_to_top

  panel { class = frame }

  panel {
    direction = left_to_right
    extend = 1

    panel { extend = 1 class = frame }
    panel { extend = 1 class = frame }
  }
}

You can also use valign/halign to adjust the position of children
widget, default value is extend.

Replace border_width/border_height with
border_left/border_right/border_top/border_bottom. To set all borders
to the same size, use border_size. You can also use border_size to set
a default value and then overwrite some of the borders using
border_left/border_right/border_top/border_bottom.

Add margin_size and padding_size, the usage is very similar to border_*.

Rename style property to class.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Fri, Oct 9, 2009 at 11:57 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> I am suggesting an interface that allows style commands like
>
> style {
>
> (class==button).(text==OK) { <style> }
>
> (class==dialog).<nothing here>.(class=button) { <style> }
>
> (class==buttonbar) { direction = right_to_left }
>
> (class==button) {
>  border_top = button_top
>  border_left = button_left
>  ...
> }
>
> }
>
> for
>
> panel { class = dialog ; direction = top_to_bottom
>  panel {
>   scroll = auto
>    text { Blah blah blah... }
>  }
>  panel { class = buttonbar ;
>  panel { class = button ; img { check.png } ;text { OK } ; command =
> <something> }
>  panel { class = button ; img { cross.png } ;text { Cancel } ;
> command = <something>}
>  }
> }
>
> The exact syntax and semantic of the selectors it to be defined.
>
> They may be imperative commands that are applied immediately to all
> widgets currently in existence or they may be stored in a style
> database that widgets consult each time they are drawn or some
> combination of the above (for example the style commands affect a
> style database in order of appearance but do not affect widgets
> directly).
>
> I guess the styles that appear in the main config (grub.cfg or loaded
> by loadcfg) should be added together so that scripts that generate
> different parts of the file can add style bits for their widgets.
>
> loadstyle command should reset all widget style properties to default
> (either widget default or the state after loading config) and then
> interpret the content of the file as if it was enclosed in style {}.
>
> When loadstyle is repeated the widgets should be reset again so that
> previous style cannot affect the newly loaded style.

Hi,

Perhaps it can be written like this:

class {
  button.text_OK { <style>}
  dialog.*button { <style> }
  buttonbar { direction = right_to_left }
  button {  border_top = button_top  border_left = button_left }
}

panel { class = dialog ; direction = top_to_bottom
  panel {
   scroll = auto
    text { Blah blah blah... }
  }
  panel { class = buttonbar ;
  panel { class = button ; img { check.png } ;text { class=text_OK } ;
command =<something> }
  panel { class = button ; img { cross.png } ;text { class=text_Cancel
} ; command = <something>}
  }
 }

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/9 Bean <bean123ch@gmail.com>:
> On Fri, Oct 9, 2009 at 11:57 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> I am suggesting an interface that allows style commands like
>>
>> style {
>>
>> (class==button).(text==OK) { <style> }
>>
>> (class==dialog).<nothing here>.(class=button) { <style> }
>>
>> (class==buttonbar) { direction = right_to_left }
>>
>> (class==button) {
>>  border_top = button_top
>>  border_left = button_left
>>  ...
>> }
>>
>> }
>>
>> for
>>
>> panel { class = dialog ; direction = top_to_bottom
>>  panel {
>>   scroll = auto
>>    text { Blah blah blah... }
>>  }
>>  panel { class = buttonbar ;
>>  panel { class = button ; img { check.png } ;text { OK } ; command =
>> <something> }
>>  panel { class = button ; img { cross.png } ;text { Cancel } ;
>> command = <something>}
>>  }
>> }
>>
>> The exact syntax and semantic of the selectors it to be defined.
>>
>> They may be imperative commands that are applied immediately to all
>> widgets currently in existence or they may be stored in a style
>> database that widgets consult each time they are drawn or some
>> combination of the above (for example the style commands affect a
>> style database in order of appearance but do not affect widgets
>> directly).
>>
>> I guess the styles that appear in the main config (grub.cfg or loaded
>> by loadcfg) should be added together so that scripts that generate
>> different parts of the file can add style bits for their widgets.
>>
>> loadstyle command should reset all widget style properties to default
>> (either widget default or the state after loading config) and then
>> interpret the content of the file as if it was enclosed in style {}.
>>
>> When loadstyle is repeated the widgets should be reset again so that
>> previous style cannot affect the newly loaded style.
>
> Hi,
>
> Perhaps it can be written like this:
>
> class {

perhaps this should be

style {

>  button.text_OK { <style>}

text_OK is quite ugly for a selector that specifies that the property
text should be equal OK.

What if the text contains a space or underscore or the property
contains underscore?

>  dialog.*button { <style> }

perhaps this should be

dialog.*.button

meaning there is one element in between or

dialog.**.button

meaning there can be zero or more elements in between {which is sorely
missing from CSS}

>  buttonbar { direction = right_to_left }
>  button {  border_top = button_top  border_left = button_left }
> }
>
> panel { class = dialog ; direction = top_to_bottom
>  panel {
>   scroll = auto
>    text { Blah blah blah... }
>  }
>  panel { class = buttonbar ;
>  panel { class = button ; img { check.png } ;text { class=text_OK } ;
> command =<something> }
>  panel { class = button ; img { cross.png } ;text { class=text_Cancel
> } ; command = <something>}
>  }
>  }
>

This resolves the syntax issue somewhat but there is still problem
with the order in which the rules are applied.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Sat, Oct 10, 2009 at 12:29 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/9 Bean <bean123ch@gmail.com>:
>> On Fri, Oct 9, 2009 at 11:57 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> I am suggesting an interface that allows style commands like
>>>
>>> style {
>>>
>>> (class==button).(text==OK) { <style> }
>>>
>>> (class==dialog).<nothing here>.(class=button) { <style> }
>>>
>>> (class==buttonbar) { direction = right_to_left }
>>>
>>> (class==button) {
>>>  border_top = button_top
>>>  border_left = button_left
>>>  ...
>>> }
>>>
>>> }
>>>
>>> for
>>>
>>> panel { class = dialog ; direction = top_to_bottom
>>>  panel {
>>>   scroll = auto
>>>    text { Blah blah blah... }
>>>  }
>>>  panel { class = buttonbar ;
>>>  panel { class = button ; img { check.png } ;text { OK } ; command =
>>> <something> }
>>>  panel { class = button ; img { cross.png } ;text { Cancel } ;
>>> command = <something>}
>>>  }
>>> }
>>>
>>> The exact syntax and semantic of the selectors it to be defined.
>>>
>>> They may be imperative commands that are applied immediately to all
>>> widgets currently in existence or they may be stored in a style
>>> database that widgets consult each time they are drawn or some
>>> combination of the above (for example the style commands affect a
>>> style database in order of appearance but do not affect widgets
>>> directly).
>>>
>>> I guess the styles that appear in the main config (grub.cfg or loaded
>>> by loadcfg) should be added together so that scripts that generate
>>> different parts of the file can add style bits for their widgets.
>>>
>>> loadstyle command should reset all widget style properties to default
>>> (either widget default or the state after loading config) and then
>>> interpret the content of the file as if it was enclosed in style {}.
>>>
>>> When loadstyle is repeated the widgets should be reset again so that
>>> previous style cannot affect the newly loaded style.
>>
>> Hi,
>>
>> Perhaps it can be written like this:
>>
>> class {
>
> perhaps this should be
>
> style {
>
>>  button.text_OK { <style>}
>
> text_OK is quite ugly for a selector that specifies that the property
> text should be equal OK.
>
> What if the text contains a space or underscore or the property
> contains underscore?
>
>>  dialog.*button { <style> }
>
> perhaps this should be
>
> dialog.*.button
>
> meaning there is one element in between or
>
> dialog.**.button
>
> meaning there can be zero or more elements in between {which is sorely
> missing from CSS}

Hi,

Do we need to distinguish the situation that exactly one element is in
between ?

>
>>  buttonbar { direction = right_to_left }
>>  button {  border_top = button_top  border_left = button_left }
>> }
>>
>> panel { class = dialog ; direction = top_to_bottom
>>  panel {
>>   scroll = auto
>>    text { Blah blah blah... }
>>  }
>>  panel { class = buttonbar ;
>>  panel { class = button ; img { check.png } ;text { class=text_OK } ;
>> command =<something> }
>>  panel { class = button ; img { cross.png } ;text { class=text_Cancel
>> } ; command = <something>}
>>  }
>>  }
>>
>
> This resolves the syntax issue somewhat but there is still problem
> with the order in which the rules are applied.

We can first try parent*class format, from near to far, then class
itself. If class is not set, use the widget name, for example, in the
following config:

panel
{
  class = aa
  panel {
  class = bb
  panel {
    text { class=cc id=text1 }
  }
  text { id=text2}
}

We scan the following section in order:

text1:
bb.cc
bb.**.cc:
aa.*.cc
aa.**.cc
cc

text2:
aa.text
aa.**.text
text


-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[richardvoigt]

> I am suggesting an interface that allows style commands like
>
> style {
>
> (class==button).(text==OK) { <style> }
>
> (class==dialog).<nothing here>.(class=button) { <style> }
>
> (class==buttonbar) { direction = right_to_left }
>
> (class==button) {
>  border_top = button_top
>  border_left = button_left
>  ...
> }
>
> }

I don't like this.  It's a unit testing nightmare. Matter of fact, so
is auto-layout.  I don't want my bootloader to be a web browser.  I
want it to be reliable and load fast.

At the very least, please keep the actual boot sequencing (the stuff
equivalent to menu.lst of grub-0.97) separate and let the GUI stuff
incorporate them by reference.  Then provide a hotkey (e.g. hold 'R'
during boot) to skip all GUI (and I mean skip everything configurable,
not just text vs graphics) and provide a simple selection with no
nesting, no icons, no borders, no fonts, no colors, no multiple lists,
just everything in one big scrollable list, with access to the command
line.

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/9 richardvoigt@gmail.com <richardvoigt@gmail.com>:
>> I am suggesting an interface that allows style commands like
>>
>> style {
>>
>> (class==button).(text==OK) { <style> }
>>
>> (class==dialog).<nothing here>.(class=button) { <style> }
>>
>> (class==buttonbar) { direction = right_to_left }
>>
>> (class==button) {
>>  border_top = button_top
>>  border_left = button_left
>>  ...
>> }
>>
>> }
>
> I don't like this.  It's a unit testing nightmare. Matter of fact, so
> is auto-layout.  I don't want my bootloader to be a web browser.  I
> want it to be reliable and load fast.
>
> At the very least, please keep the actual boot sequencing (the stuff
> equivalent to menu.lst of grub-0.97) separate and let the GUI stuff
> incorporate them by reference.  Then provide a hotkey (e.g. hold 'R'
> during boot) to skip all GUI (and I mean skip everything configurable,
> not just text vs graphics) and provide a simple selection with no
> nesting, no icons, no borders, no fonts, no colors, no multiple lists,
> just everything in one big scrollable list, with access to the command
> line.

The thing is that people *demand* that things are configurable, and
for grub legacy poorly written (possibly because grub-legacy was hard
to extend) patches for that were created which were not incorporated
into the mainline grub-legacy.

So the choice here is to support configurable menu (and try to strip
features as much as possible to keep the complexity reasonable while
still maintain reasonable flexibility) or accept that several ad-hoc
graphics menu implementations will eventually emerge on the net.

Note also that on non-i386 platforms there is often no VGA text
console so graphics is the only way to display any menu at all, and
you have to deal with fonts and colors then.

For now you can choose to load the old gfxterm (and it is the only
working graphics option now) but I expect that when the new menu
system is considered stable gfxterm will be deprecated.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/9 Bean <bean123ch@gmail.com>:
> On Sat, Oct 10, 2009 at 12:29 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/9 Bean <bean123ch@gmail.com>:
>>> On Fri, Oct 9, 2009 at 11:57 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> I am suggesting an interface that allows style commands like
>>>>
>>>> style {
>>>>
>>>> (class==button).(text==OK) { <style> }
>>>>
>>>> (class==dialog).<nothing here>.(class=button) { <style> }
>>>>
>>>> (class==buttonbar) { direction = right_to_left }
>>>>
>>>> (class==button) {
>>>>  border_top = button_top
>>>>  border_left = button_left
>>>>  ...
>>>> }
>>>>
>>>> }
>>>>
>>>> for
>>>>
>>>> panel { class = dialog ; direction = top_to_bottom
>>>>  panel {
>>>>   scroll = auto
>>>>    text { Blah blah blah... }
>>>>  }
>>>>  panel { class = buttonbar ;
>>>>  panel { class = button ; img { check.png } ;text { OK } ; command =
>>>> <something> }
>>>>  panel { class = button ; img { cross.png } ;text { Cancel } ;
>>>> command = <something>}
>>>>  }
>>>> }
>>>>
>>>> The exact syntax and semantic of the selectors it to be defined.
>>>>
>>>> They may be imperative commands that are applied immediately to all
>>>> widgets currently in existence or they may be stored in a style
>>>> database that widgets consult each time they are drawn or some
>>>> combination of the above (for example the style commands affect a
>>>> style database in order of appearance but do not affect widgets
>>>> directly).
>>>>
>>>> I guess the styles that appear in the main config (grub.cfg or loaded
>>>> by loadcfg) should be added together so that scripts that generate
>>>> different parts of the file can add style bits for their widgets.
>>>>
>>>> loadstyle command should reset all widget style properties to default
>>>> (either widget default or the state after loading config) and then
>>>> interpret the content of the file as if it was enclosed in style {}.
>>>>
>>>> When loadstyle is repeated the widgets should be reset again so that
>>>> previous style cannot affect the newly loaded style.
>>>
>>> Hi,
>>>
>>> Perhaps it can be written like this:
>>>
>>> class {
>>
>> perhaps this should be
>>
>> style {
>>
>>>  button.text_OK { <style>}
>>
>> text_OK is quite ugly for a selector that specifies that the property
>> text should be equal OK.
>>
>> What if the text contains a space or underscore or the property
>> contains underscore?
>>
>>>  dialog.*button { <style> }
>>
>> perhaps this should be
>>
>> dialog.*.button
>>
>> meaning there is one element in between or
>>
>> dialog.**.button
>>
>> meaning there can be zero or more elements in between {which is sorely
>> missing from CSS}
>
> Hi,
>
> Do we need to distinguish the situation that exactly one element is in
> between ?
>
>>
>>>  buttonbar { direction = right_to_left }
>>>  button {  border_top = button_top  border_left = button_left }
>>> }
>>>
>>> panel { class = dialog ; direction = top_to_bottom
>>>  panel {
>>>   scroll = auto
>>>    text { Blah blah blah... }
>>>  }
>>>  panel { class = buttonbar ;
>>>  panel { class = button ; img { check.png } ;text { class=text_OK } ;
>>> command =<something> }
>>>  panel { class = button ; img { cross.png } ;text { class=text_Cancel
>>> } ; command = <something>}
>>>  }
>>>  }
>>>
>>
>> This resolves the syntax issue somewhat but there is still problem
>> with the order in which the rules are applied.
>
> We can first try parent*class format, from near to far, then class
> itself. If class is not set, use the widget name, for example, in the
> following config:
>
> panel
> {
>  class = aa
>  panel {
>  class = bb
>  panel {
>    text { class=cc id=text1 }
>  }
>  text { id=text2}
> }
>
> We scan the following section in order:
>
> text1:
> bb.cc
> bb.**.cc:
> aa.*.cc
> aa.**.cc
> cc

I would guess it should be

* /* everything */
text /* = **.text */
cc /* class specified */
aa.**.text
aa.**.cc
bb.**.text /* nearer start*/
bb.**.cc
aa.*.text /* less starry */
aa.*,cc
bb.text
bb.cc
aa.bb..text /* more elements specified in the path */
aa.bb.cc

meaning that a property can be set by any of the above but the later
styles (lower in the list) can override properties set earlier.

This is similar to what X props or CSS would do - the resulting
properties do not depend on the order of styling in text but on how
"specific" the selector is.

This requires a style store separate from the widgets but likely
results in somewhat tidier and better predicatble behaviour than
setting the properties directly on the widgets. The separate style
store also means that you can save the state before loading a style
and reset it later quite easily.

Overriding styles in this system is problematic, that's why the
properties should be reset when a different style is loaded.

The properties set directly on the widgets should be probably
consulted first, before the * style, and it should be possible to
restore them when the style is changed.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[richardvoigt]

On Fri, Oct 9, 2009 at 12:09 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/9 richardvoigt@gmail.com <richardvoigt@gmail.com>:
>>> I am suggesting an interface that allows style commands like
>>>
>>> style {
>>>
>>> (class==button).(text==OK) { <style> }
>>>
>>> (class==dialog).<nothing here>.(class=button) { <style> }
>>>
>>> (class==buttonbar) { direction = right_to_left }
>>>
>>> (class==button) {
>>>  border_top = button_top
>>>  border_left = button_left
>>>  ...
>>> }
>>>
>>> }
>>
>> I don't like this.  It's a unit testing nightmare. Matter of fact, so
>> is auto-layout.  I don't want my bootloader to be a web browser.  I
>> want it to be reliable and load fast.
>>
>> At the very least, please keep the actual boot sequencing (the stuff
>> equivalent to menu.lst of grub-0.97) separate and let the GUI stuff
>> incorporate them by reference.  Then provide a hotkey (e.g. hold 'R'
>> during boot) to skip all GUI (and I mean skip everything configurable,
>> not just text vs graphics) and provide a simple selection with no
>> nesting, no icons, no borders, no fonts, no colors, no multiple lists,
>> just everything in one big scrollable list, with access to the command
>> line.
>
> The thing is that people *demand* that things are configurable, and
> for grub legacy poorly written (possibly because grub-legacy was hard
> to extend) patches for that were created which were not incorporated
> into the mainline grub-legacy.
>
> So the choice here is to support configurable menu (and try to strip
> features as much as possible to keep the complexity reasonable while
> still maintain reasonable flexibility) or accept that several ad-hoc
> graphics menu implementations will eventually emerge on the net.

Or you can stop trying to solve all the world's problems (and getting
an equivalent number of bugs), and design something that lends itself
to extension.

You've already got modules.  I think that if you provide the following
few functions, people will make mutually compatible extensions that
could then be merged into the main tree as desired:

Some data structure for holding the boot sequence commands, like grub
legacy's menu.lst but without the look-and-feel stuff.
Enumeration of available boot sequences (and possibly bootable media
not listed in the user's configuration).
A function for executing a particular boot sequence by id-string.

A function for printing text in text-mode.

A class for holding a screen-buffer. (readable attributes such as
width and height)
A function for presenting the screen-buffer, and returning after a key
is pressed or timeout (or possibly if bootable media is inserted).
A function for filling a rectangular subregion with a specific color.
A function for drawing a box (flags for which sides to draw, color of
sides, and single-or-double line, and raster-combining op such as XOR
to help with highlighting selected items).
A function for drawing a bitmap.
A function for drawing a string (specify color).

A function for obtaining the user's stored GUI configuration (content
is specific to the extension).
And a global setting that specifies which GUI extension is to be loaded.

You can provide a couple prebuilt extensions such as simple scrolling
text list selectable with arrow keys ala grub-legacy (no GUI
configuration) and a fancier one more like rEFIt with one horizontal
list of kernel icons above and a set of tools below (GUI configuration
is the set of items to place in the toolbar, all others go in the
kernel list).  These are small enough in scope to get right and cover
completely with tests.

Yes, fancier menus will emerge out on the net.  Yes, they'll be
incompatible and have some duplication of effort in terms of
auto-layout.  But every one of the auto-layout routines will be far
simpler, because it doesn't have to let the user choose how to divide
space, etc.  Each only has to accommodate more items in the
already-defined layout.  Plus, users can always fallback to a good
version and recovery from a messed-up GUI configuration will be made
easier.

And, you can work on an extension which is the infinitely-flexible
pseudo-CSS pseudo-HTML autolayout engine you're already started on.
But I'm suspicious that it'll never be finished because the scope is
so large.

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Sat, Oct 10, 2009 at 1:27 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/9 Bean <bean123ch@gmail.com>:
>> On Sat, Oct 10, 2009 at 12:29 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> 2009/10/9 Bean <bean123ch@gmail.com>:
>>>> On Fri, Oct 9, 2009 at 11:57 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>> I am suggesting an interface that allows style commands like
>>>>>
>>>>> style {
>>>>>
>>>>> (class==button).(text==OK) { <style> }
>>>>>
>>>>> (class==dialog).<nothing here>.(class=button) { <style> }
>>>>>
>>>>> (class==buttonbar) { direction = right_to_left }
>>>>>
>>>>> (class==button) {
>>>>>  border_top = button_top
>>>>>  border_left = button_left
>>>>>  ...
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>> for
>>>>>
>>>>> panel { class = dialog ; direction = top_to_bottom
>>>>>  panel {
>>>>>   scroll = auto
>>>>>    text { Blah blah blah... }
>>>>>  }
>>>>>  panel { class = buttonbar ;
>>>>>  panel { class = button ; img { check.png } ;text { OK } ; command =
>>>>> <something> }
>>>>>  panel { class = button ; img { cross.png } ;text { Cancel } ;
>>>>> command = <something>}
>>>>>  }
>>>>> }
>>>>>
>>>>> The exact syntax and semantic of the selectors it to be defined.
>>>>>
>>>>> They may be imperative commands that are applied immediately to all
>>>>> widgets currently in existence or they may be stored in a style
>>>>> database that widgets consult each time they are drawn or some
>>>>> combination of the above (for example the style commands affect a
>>>>> style database in order of appearance but do not affect widgets
>>>>> directly).
>>>>>
>>>>> I guess the styles that appear in the main config (grub.cfg or loaded
>>>>> by loadcfg) should be added together so that scripts that generate
>>>>> different parts of the file can add style bits for their widgets.
>>>>>
>>>>> loadstyle command should reset all widget style properties to default
>>>>> (either widget default or the state after loading config) and then
>>>>> interpret the content of the file as if it was enclosed in style {}.
>>>>>
>>>>> When loadstyle is repeated the widgets should be reset again so that
>>>>> previous style cannot affect the newly loaded style.
>>>>
>>>> Hi,
>>>>
>>>> Perhaps it can be written like this:
>>>>
>>>> class {
>>>
>>> perhaps this should be
>>>
>>> style {
>>>
>>>>  button.text_OK { <style>}
>>>
>>> text_OK is quite ugly for a selector that specifies that the property
>>> text should be equal OK.
>>>
>>> What if the text contains a space or underscore or the property
>>> contains underscore?
>>>
>>>>  dialog.*button { <style> }
>>>
>>> perhaps this should be
>>>
>>> dialog.*.button
>>>
>>> meaning there is one element in between or
>>>
>>> dialog.**.button
>>>
>>> meaning there can be zero or more elements in between {which is sorely
>>> missing from CSS}
>>
>> Hi,
>>
>> Do we need to distinguish the situation that exactly one element is in
>> between ?
>>
>>>
>>>>  buttonbar { direction = right_to_left }
>>>>  button {  border_top = button_top  border_left = button_left }
>>>> }
>>>>
>>>> panel { class = dialog ; direction = top_to_bottom
>>>>  panel {
>>>>   scroll = auto
>>>>    text { Blah blah blah... }
>>>>  }
>>>>  panel { class = buttonbar ;
>>>>  panel { class = button ; img { check.png } ;text { class=text_OK } ;
>>>> command =<something> }
>>>>  panel { class = button ; img { cross.png } ;text { class=text_Cancel
>>>> } ; command = <something>}
>>>>  }
>>>>  }
>>>>
>>>
>>> This resolves the syntax issue somewhat but there is still problem
>>> with the order in which the rules are applied.
>>
>> We can first try parent*class format, from near to far, then class
>> itself. If class is not set, use the widget name, for example, in the
>> following config:
>>
>> panel
>> {
>>  class = aa
>>  panel {
>>  class = bb
>>  panel {
>>    text { class=cc id=text1 }
>>  }
>>  text { id=text2}
>> }
>>
>> We scan the following section in order:
>>
>> text1:
>> bb.cc
>> bb.**.cc:
>> aa.*.cc
>> aa.**.cc
>> cc
>
> I would guess it should be
>
> * /* everything */
> text /* = **.text */
> cc /* class specified */
> aa.**.text
> aa.**.cc
> bb.**.text /* nearer start*/
> bb.**.cc
> aa.*.text /* less starry */
> aa.*,cc
> bb.text
> bb.cc
> aa.bb..text /* more elements specified in the path */
> aa.bb.cc
>
> meaning that a property can be set by any of the above but the later
> styles (lower in the list) can override properties set earlier.
>
> This is similar to what X props or CSS would do - the resulting
> properties do not depend on the order of styling in text but on how
> "specific" the selector is.
>
> This requires a style store separate from the widgets but likely
> results in somewhat tidier and better predicatble behaviour than
> setting the properties directly on the widgets. The separate style
> store also means that you can save the state before loading a style
> and reset it later quite easily.
>
> Overriding styles in this system is problematic, that's why the
> properties should be reset when a different style is loaded.
>
> The properties set directly on the widgets should be probably
> consulted first, before the * style, and it should be possible to
> restore them when the style is changed.

Hi,

Currently, the menu system don't store class property in widget, this
make it easier to change theme, we just reload the class tree and
reinit the screen. It checks local properties first, if not found,
check the class tree for default value, so the scan order should be
reversed, it quits as soon as one match is found.

For starters, we can just implement two level pattern parent*class, as
each property would need to scan the tree for matches, deep level
would mean a lot of iteration and could have a impact on performance.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Sat, Oct 10, 2009 at 2:28 AM, richardvoigt@gmail.com
<richardvoigt@gmail.com> wrote:
> On Fri, Oct 9, 2009 at 12:09 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/9 richardvoigt@gmail.com <richardvoigt@gmail.com>:
>>>> I am suggesting an interface that allows style commands like
>>>>
>>>> style {
>>>>
>>>> (class==button).(text==OK) { <style> }
>>>>
>>>> (class==dialog).<nothing here>.(class=button) { <style> }
>>>>
>>>> (class==buttonbar) { direction = right_to_left }
>>>>
>>>> (class==button) {
>>>>  border_top = button_top
>>>>  border_left = button_left
>>>>  ...
>>>> }
>>>>
>>>> }
>>>
>>> I don't like this.  It's a unit testing nightmare. Matter of fact, so
>>> is auto-layout.  I don't want my bootloader to be a web browser.  I
>>> want it to be reliable and load fast.
>>>
>>> At the very least, please keep the actual boot sequencing (the stuff
>>> equivalent to menu.lst of grub-0.97) separate and let the GUI stuff
>>> incorporate them by reference.  Then provide a hotkey (e.g. hold 'R'
>>> during boot) to skip all GUI (and I mean skip everything configurable,
>>> not just text vs graphics) and provide a simple selection with no
>>> nesting, no icons, no borders, no fonts, no colors, no multiple lists,
>>> just everything in one big scrollable list, with access to the command
>>> line.
>>
>> The thing is that people *demand* that things are configurable, and
>> for grub legacy poorly written (possibly because grub-legacy was hard
>> to extend) patches for that were created which were not incorporated
>> into the mainline grub-legacy.
>>
>> So the choice here is to support configurable menu (and try to strip
>> features as much as possible to keep the complexity reasonable while
>> still maintain reasonable flexibility) or accept that several ad-hoc
>> graphics menu implementations will eventually emerge on the net.
>
> Or you can stop trying to solve all the world's problems (and getting
> an equivalent number of bugs), and design something that lends itself
> to extension.
>
> You've already got modules.  I think that if you provide the following
> few functions, people will make mutually compatible extensions that
> could then be merged into the main tree as desired:
>
> Some data structure for holding the boot sequence commands, like grub
> legacy's menu.lst but without the look-and-feel stuff.
> Enumeration of available boot sequences (and possibly bootable media
> not listed in the user's configuration).
> A function for executing a particular boot sequence by id-string.
>
> A function for printing text in text-mode.
>
> A class for holding a screen-buffer. (readable attributes such as
> width and height)
> A function for presenting the screen-buffer, and returning after a key
> is pressed or timeout (or possibly if bootable media is inserted).
> A function for filling a rectangular subregion with a specific color.
> A function for drawing a box (flags for which sides to draw, color of
> sides, and single-or-double line, and raster-combining op such as XOR
> to help with highlighting selected items).
> A function for drawing a bitmap.
> A function for drawing a string (specify color).
>
> A function for obtaining the user's stored GUI configuration (content
> is specific to the extension).
> And a global setting that specifies which GUI extension is to be loaded.
>
> You can provide a couple prebuilt extensions such as simple scrolling
> text list selectable with arrow keys ala grub-legacy (no GUI
> configuration) and a fancier one more like rEFIt with one horizontal
> list of kernel icons above and a set of tools below (GUI configuration
> is the set of items to place in the toolbar, all others go in the
> kernel list).  These are small enough in scope to get right and cover
> completely with tests.
>
> Yes, fancier menus will emerge out on the net.  Yes, they'll be
> incompatible and have some duplication of effort in terms of
> auto-layout.  But every one of the auto-layout routines will be far
> simpler, because it doesn't have to let the user choose how to divide
> space, etc.  Each only has to accommodate more items in the
> already-defined layout.  Plus, users can always fallback to a good
> version and recovery from a messed-up GUI configuration will be made
> easier.
>
> And, you can work on an extension which is the infinitely-flexible
> pseudo-CSS pseudo-HTML autolayout engine you're already started on.
> But I'm suspicious that it'll never be finished because the scope is
> so large.

Hi,

Actually the menu system is split into different modules, you can use
it to build your own ui:

region:
low level drawing api, use to construct ui that work in both text and
graphic mode

config loader:
loads tree structure config file

widget:
widget infrastructure function

ui component:
widgets

Users can extend ui by writing new widget, some of the complex task
like layout manager is already handled by the widget manager.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/9 richardvoigt@gmail.com <richardvoigt@gmail.com>:
> On Fri, Oct 9, 2009 at 12:09 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/9 richardvoigt@gmail.com <richardvoigt@gmail.com>:
>>>> I am suggesting an interface that allows style commands like
>>>>
>>>> style {
>>>>
>>>> (class==button).(text==OK) { <style> }
>>>>
>>>> (class==dialog).<nothing here>.(class=button) { <style> }
>>>>
>>>> (class==buttonbar) { direction = right_to_left }
>>>>
>>>> (class==button) {
>>>>  border_top = button_top
>>>>  border_left = button_left
>>>>  ...
>>>> }
>>>>
>>>> }
>>>
>>> I don't like this.  It's a unit testing nightmare. Matter of fact, so
>>> is auto-layout.  I don't want my bootloader to be a web browser.  I
>>> want it to be reliable and load fast.
>>>
>>> At the very least, please keep the actual boot sequencing (the stuff
>>> equivalent to menu.lst of grub-0.97) separate and let the GUI stuff
>>> incorporate them by reference.  Then provide a hotkey (e.g. hold 'R'
>>> during boot) to skip all GUI (and I mean skip everything configurable,
>>> not just text vs graphics) and provide a simple selection with no
>>> nesting, no icons, no borders, no fonts, no colors, no multiple lists,
>>> just everything in one big scrollable list, with access to the command
>>> line.
>>
>> The thing is that people *demand* that things are configurable, and
>> for grub legacy poorly written (possibly because grub-legacy was hard
>> to extend) patches for that were created which were not incorporated
>> into the mainline grub-legacy.
>>
>> So the choice here is to support configurable menu (and try to strip
>> features as much as possible to keep the complexity reasonable while
>> still maintain reasonable flexibility) or accept that several ad-hoc
>> graphics menu implementations will eventually emerge on the net.
>
> Or you can stop trying to solve all the world's problems (and getting
> an equivalent number of bugs), and design something that lends itself
> to extension.
>
> You've already got modules.  I think that if you provide the following
> few functions, people will make mutually compatible extensions that
> could then be merged into the main tree as desired:
>
> Some data structure for holding the boot sequence commands, like grub
> legacy's menu.lst but without the look-and-feel stuff.
> Enumeration of available boot sequences (and possibly bootable media
> not listed in the user's configuration).
> A function for executing a particular boot sequence by id-string.

What do you mean by:

- boot seqence

- bootable media

- structure for holding boot sequence commands

I suspect you can think of the new (and old) menu configuration as a
structure to hold boot sequence commands if by boot sequence you mean
something like:
  linux /boot/vmlinuz root=/dev/sda1 ro
  initrd /boot/initrd.gz

In the new menu configuration the style which specifies how this is
drawn can be separate form the menu configuration.

>
> A function for printing text in text-mode.
>
> A class for holding a screen-buffer. (readable attributes such as
> width and height)
> A function for presenting the screen-buffer, and returning after a key
> is pressed or timeout (or possibly if bootable media is inserted).
> A function for filling a rectangular subregion with a specific color.
> A function for drawing a box (flags for which sides to draw, color of
> sides, and single-or-double line, and raster-combining op such as XOR
> to help with highlighting selected items).
> A function for drawing a bitmap.
> A function for drawing a string (specify color).

We already have these functions in video subsystem.

Just having them does not make a nice menu magically appear on your
screen. That's what the new menu system is about.

>
> A function for obtaining the user's stored GUI configuration (content
> is specific to the extension).
> And a global setting that specifies which GUI extension is to be loaded.

We need a gui extension that actually works, even if it is the old
console menu or gfxterm. They still do have configuration and layout
that have to work reasonably for them to be usable but they are not
customizable at all. This causes problems. For example the key
bindings that include the Ctrl modifier do not work on Apple EFI and
grub itself has to be patched to change these, they cannot be set in a
configuration file.

>
> You can provide a couple prebuilt extensions such as simple scrolling
> text list selectable with arrow keys ala grub-legacy (no GUI
> configuration) and a fancier one more like rEFIt with one horizontal
> list of kernel icons above and a set of tools below (GUI configuration
> is the set of items to place in the toolbar, all others go in the
> kernel list).  These are small enough in scope to get right and cover
> completely with tests.

Why should we bother?

gfxterm is there but people complain it's too limited and even the
rEFIt author acknowledges the UI is too limited and inflexible so we
need something more general than that.

>
> Yes, fancier menus will emerge out on the net.  Yes, they'll be
> incompatible and have some duplication of effort in terms of
> auto-layout.  But every one of the auto-layout routines will be far

There is no need for numerous extensions if the menu system in grub
can do what most people want.

> simpler, because it doesn't have to let the user choose how to divide
> space, etc.  Each only has to accommodate more items in the

Why so?

You either manage screen space or your menu overflows on one edge when
you have too many (or too long) items.

> already-defined layout.  Plus, users can always fallback to a good
> version and recovery from a messed-up GUI configuration will be made
> easier.

Why should fallback in a more general system be difficult? You still
have the command line and you can store and use multiple
configurations, that's not going to change.

>
> And, you can work on an extension which is the infinitely-flexible
> pseudo-CSS pseudo-HTML autolayout engine you're already started on.
> But I'm suspicious that it'll never be finished because the scope is
> so large.

There are numerous toolkits far more complex than this, and they are
finished and working.

I am also actively trying to keep this one as simple as possible.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/9 Bean <bean123ch@gmail.com>:
> On Sat, Oct 10, 2009 at 1:27 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/9 Bean <bean123ch@gmail.com>:
>>> On Sat, Oct 10, 2009 at 12:29 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> 2009/10/9 Bean <bean123ch@gmail.com>:
>>>>> On Fri, Oct 9, 2009 at 11:57 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>>> I am suggesting an interface that allows style commands like
>>>>>>
>>>>>> style {
>>>>>>
>>>>>> (class==button).(text==OK) { <style> }
>>>>>>
>>>>>> (class==dialog).<nothing here>.(class=button) { <style> }
>>>>>>
>>>>>> (class==buttonbar) { direction = right_to_left }
>>>>>>
>>>>>> (class==button) {
>>>>>> áborder_top = button_top
>>>>>> áborder_left = button_left
>>>>>> á...
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>
>>>>>> for
>>>>>>
>>>>>> panel { class = dialog ; direction = top_to_bottom
>>>>>> ápanel {
>>>>>> á scroll = auto
>>>>>> á átext { Blah blah blah... }
>>>>>> á}
>>>>>> ápanel { class = buttonbar ;
>>>>>> ápanel { class = button ; img { check.png } ;text { OK } ; command =
>>>>>> <something> }
>>>>>> ápanel { class = button ; img { cross.png } ;text { Cancel } ;
>>>>>> command = <something>}
>>>>>> á}
>>>>>> }
>>>>>>
>>>>>> The exact syntax and semantic of the selectors it to be defined.
>>>>>>
>>>>>> They may be imperative commands that are applied immediately to all
>>>>>> widgets currently in existence or they may be stored in a style
>>>>>> database that widgets consult each time they are drawn or some
>>>>>> combination of the above (for example the style commands affect a
>>>>>> style database in order of appearance but do not affect widgets
>>>>>> directly).
>>>>>>
>>>>>> I guess the styles that appear in the main config (grub.cfg or loaded
>>>>>> by loadcfg) should be added together so that scripts that generate
>>>>>> different parts of the file can add style bits for their widgets.
>>>>>>
>>>>>> loadstyle command should reset all widget style properties to default
>>>>>> (either widget default or the state after loading config) and then
>>>>>> interpret the content of the file as if it was enclosed in style {}.
>>>>>>
>>>>>> When loadstyle is repeated the widgets should be reset again so that
>>>>>> previous style cannot affect the newly loaded style.
>>>>>
>>>>> Hi,
>>>>>
>>>>> Perhaps it can be written like this:
>>>>>
>>>>> class {
>>>>
>>>> perhaps this should be
>>>>
>>>> style {
>>>>
>>>>> ábutton.text_OK { <style>}
>>>>
>>>> text_OK is quite ugly for a selector that specifies that the property
>>>> text should be equal OK.
>>>>
>>>> What if the text contains a space or underscore or the property
>>>> contains underscore?
>>>>
>>>>> ádialog.*button { <style> }
>>>>
>>>> perhaps this should be
>>>>
>>>> dialog.*.button
>>>>
>>>> meaning there is one element in between or
>>>>
>>>> dialog.**.button
>>>>
>>>> meaning there can be zero or more elements in between {which is sorely
>>>> missing from CSS}
>>>
>>> Hi,
>>>
>>> Do we need to distinguish the situation that exactly one element is in
>>> between ?
>>>
>>>>
>>>>> ábuttonbar { direction = right_to_left }
>>>>> ábutton { áborder_top = button_top áborder_left = button_left }
>>>>> }
>>>>>
>>>>> panel { class = dialog ; direction = top_to_bottom
>>>>> ápanel {
>>>>> á scroll = auto
>>>>> á átext { Blah blah blah... }
>>>>> á}
>>>>> ápanel { class = buttonbar ;
>>>>> ápanel { class = button ; img { check.png } ;text { class=text_OK } ;
>>>>> command =<something> }
>>>>> ápanel { class = button ; img { cross.png } ;text { class=text_Cancel
>>>>> } ; command = <something>}
>>>>> á}
>>>>> á}
>>>>>
>>>>
>>>> This resolves the syntax issue somewhat but there is still problem
>>>> with the order in which the rules are applied.
>>>
>>> We can first try parent*class format, from near to far, then class
>>> itself. If class is not set, use the widget name, for example, in the
>>> following config:
>>>
>>> panel
>>> {
>>> áclass = aa
>>> ápanel {
>>> áclass = bb
>>> ápanel {
>>> á átext { class=cc id=text1 }
>>> á}
>>> átext { id=text2}
>>> }
>>>
>>> We scan the following section in order:
>>>
>>> text1:
>>> bb.cc
>>> bb.**.cc:
>>> aa.*.cc
>>> aa.**.cc
>>> cc
>>
>> I would guess it should be
>>
>> * /* everything */
>> text /* = **.text */
>> cc /* class specified */
>> aa.**.text
>> aa.**.cc
>> bb.**.text /* nearer start*/
>> bb.**.cc
>> aa.*.text /* less starry */
>> aa.*,cc
>> bb.text
>> bb.cc
>> aa.bb..text /* more elements specified in the path */
>> aa.bb.cc
>>
>> meaning that a property can be set by any of the above but the later
>> styles (lower in the list) can override properties set earlier.
>>
>> This is similar to what X props or CSS would do - the resulting
>> properties do not depend on the order of styling in text but on how
>> "specific" the selector is.
>>
>> This requires a style store separate from the widgets but likely
>> results in somewhat tidier and better predicatble behaviour than
>> setting the properties directly on the widgets. The separate style
>> store also means that you can save the state before loading a style
>> and reset it later quite easily.
>>
>> Overriding styles in this system is problematic, that's why the
>> properties should be reset when a different style is loaded.
>>
>> The properties set directly on the widgets should be probably
>> consulted first, before the * style, and it should be possible to
>> restore them when the style is changed.
>
> Hi,
>
> Currently, the menu system don't store class property in widget, this
> make it easier to change theme, we just reload the class tree and
> reinit the screen. It checks local properties first, if not found,
> check the class tree for default value, so the scan order should be
> reversed, it quits as soon as one match is found.
>
> For starters, we can just implement two level pattern parent*class, as
> each property would need to scan the tree for matches, deep level
> would mean a lot of iteration and could have a impact on performance.

I don't think this is too much of a problem. How deep a typical layout
will be? Ten levels? Do ten pointer dereferences slow down grub? There
are components in the current system that are much slower (ie fonts
and drawing) so we should not really care.

Even if this becomes problem in the future given a reasonable
interface to the style resolver the matching can be optimized later.

It seems that the paths are in fact very simple:

 - there is a list of zero or more classes. A class may be either one
that is explicitly specified on a panel or "" (anonymous panel)
 - at the end there is an element type (panel, edit, text, image, ...)
and an optional class

So the interface to the style resolver should accept this list of
classes in some form and information on the final element and the
resolver should return back the properties it knows about for this
path (return a structure holding these or set them directly on the
final element if passed to it or something).

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Sat, Oct 10, 2009 at 4:41 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/9 Bean <bean123ch@gmail.com>:
>> On Sat, Oct 10, 2009 at 1:27 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> 2009/10/9 Bean <bean123ch@gmail.com>:
>>>> On Sat, Oct 10, 2009 at 12:29 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>> 2009/10/9 Bean <bean123ch@gmail.com>:
>>>>>> On Fri, Oct 9, 2009 at 11:57 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>>>> I am suggesting an interface that allows style commands like
>>>>>>>
>>>>>>> style {
>>>>>>>
>>>>>>> (class==button).(text==OK) { <style> }
>>>>>>>
>>>>>>> (class==dialog).<nothing here>.(class=button) { <style> }
>>>>>>>
>>>>>>> (class==buttonbar) { direction = right_to_left }
>>>>>>>
>>>>>>> (class==button) {
>>>>>>> áborder_top = button_top
>>>>>>> áborder_left = button_left
>>>>>>> á...
>>>>>>> }
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> for
>>>>>>>
>>>>>>> panel { class = dialog ; direction = top_to_bottom
>>>>>>> ápanel {
>>>>>>> á scroll = auto
>>>>>>> á átext { Blah blah blah... }
>>>>>>> á}
>>>>>>> ápanel { class = buttonbar ;
>>>>>>> ápanel { class = button ; img { check.png } ;text { OK } ; command =
>>>>>>> <something> }
>>>>>>> ápanel { class = button ; img { cross.png } ;text { Cancel } ;
>>>>>>> command = <something>}
>>>>>>> á}
>>>>>>> }
>>>>>>>
>>>>>>> The exact syntax and semantic of the selectors it to be defined.
>>>>>>>
>>>>>>> They may be imperative commands that are applied immediately to all
>>>>>>> widgets currently in existence or they may be stored in a style
>>>>>>> database that widgets consult each time they are drawn or some
>>>>>>> combination of the above (for example the style commands affect a
>>>>>>> style database in order of appearance but do not affect widgets
>>>>>>> directly).
>>>>>>>
>>>>>>> I guess the styles that appear in the main config (grub.cfg or loaded
>>>>>>> by loadcfg) should be added together so that scripts that generate
>>>>>>> different parts of the file can add style bits for their widgets.
>>>>>>>
>>>>>>> loadstyle command should reset all widget style properties to default
>>>>>>> (either widget default or the state after loading config) and then
>>>>>>> interpret the content of the file as if it was enclosed in style {}.
>>>>>>>
>>>>>>> When loadstyle is repeated the widgets should be reset again so that
>>>>>>> previous style cannot affect the newly loaded style.
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Perhaps it can be written like this:
>>>>>>
>>>>>> class {
>>>>>
>>>>> perhaps this should be
>>>>>
>>>>> style {
>>>>>
>>>>>> ábutton.text_OK { <style>}
>>>>>
>>>>> text_OK is quite ugly for a selector that specifies that the property
>>>>> text should be equal OK.
>>>>>
>>>>> What if the text contains a space or underscore or the property
>>>>> contains underscore?
>>>>>
>>>>>> ádialog.*button { <style> }
>>>>>
>>>>> perhaps this should be
>>>>>
>>>>> dialog.*.button
>>>>>
>>>>> meaning there is one element in between or
>>>>>
>>>>> dialog.**.button
>>>>>
>>>>> meaning there can be zero or more elements in between {which is sorely
>>>>> missing from CSS}
>>>>
>>>> Hi,
>>>>
>>>> Do we need to distinguish the situation that exactly one element is in
>>>> between ?
>>>>
>>>>>
>>>>>> ábuttonbar { direction = right_to_left }
>>>>>> ábutton { áborder_top = button_top áborder_left = button_left }
>>>>>> }
>>>>>>
>>>>>> panel { class = dialog ; direction = top_to_bottom
>>>>>> ápanel {
>>>>>> á scroll = auto
>>>>>> á átext { Blah blah blah... }
>>>>>> á}
>>>>>> ápanel { class = buttonbar ;
>>>>>> ápanel { class = button ; img { check.png } ;text { class=text_OK } ;
>>>>>> command =<something> }
>>>>>> ápanel { class = button ; img { cross.png } ;text { class=text_Cancel
>>>>>> } ; command = <something>}
>>>>>> á}
>>>>>> á}
>>>>>>
>>>>>
>>>>> This resolves the syntax issue somewhat but there is still problem
>>>>> with the order in which the rules are applied.
>>>>
>>>> We can first try parent*class format, from near to far, then class
>>>> itself. If class is not set, use the widget name, for example, in the
>>>> following config:
>>>>
>>>> panel
>>>> {
>>>> áclass = aa
>>>> ápanel {
>>>> áclass = bb
>>>> ápanel {
>>>> á átext { class=cc id=text1 }
>>>> á}
>>>> átext { id=text2}
>>>> }
>>>>
>>>> We scan the following section in order:
>>>>
>>>> text1:
>>>> bb.cc
>>>> bb.**.cc:
>>>> aa.*.cc
>>>> aa.**.cc
>>>> cc
>>>
>>> I would guess it should be
>>>
>>> * /* everything */
>>> text /* = **.text */
>>> cc /* class specified */
>>> aa.**.text
>>> aa.**.cc
>>> bb.**.text /* nearer start*/
>>> bb.**.cc
>>> aa.*.text /* less starry */
>>> aa.*,cc
>>> bb.text
>>> bb.cc
>>> aa.bb..text /* more elements specified in the path */
>>> aa.bb.cc
>>>
>>> meaning that a property can be set by any of the above but the later
>>> styles (lower in the list) can override properties set earlier.
>>>
>>> This is similar to what X props or CSS would do - the resulting
>>> properties do not depend on the order of styling in text but on how
>>> "specific" the selector is.
>>>
>>> This requires a style store separate from the widgets but likely
>>> results in somewhat tidier and better predicatble behaviour than
>>> setting the properties directly on the widgets. The separate style
>>> store also means that you can save the state before loading a style
>>> and reset it later quite easily.
>>>
>>> Overriding styles in this system is problematic, that's why the
>>> properties should be reset when a different style is loaded.
>>>
>>> The properties set directly on the widgets should be probably
>>> consulted first, before the * style, and it should be possible to
>>> restore them when the style is changed.
>>
>> Hi,
>>
>> Currently, the menu system don't store class property in widget, this
>> make it easier to change theme, we just reload the class tree and
>> reinit the screen. It checks local properties first, if not found,
>> check the class tree for default value, so the scan order should be
>> reversed, it quits as soon as one match is found.
>>
>> For starters, we can just implement two level pattern parent*class, as
>> each property would need to scan the tree for matches, deep level
>> would mean a lot of iteration and could have a impact on performance.
>
> I don't think this is too much of a problem. How deep a typical layout
> will be? Ten levels? Do ten pointer dereferences slow down grub? There
> are components in the current system that are much slower (ie fonts
> and drawing) so we should not really care.
>
> Even if this becomes problem in the future given a reasonable
> interface to the style resolver the matching can be optimized later.
>
> It seems that the paths are in fact very simple:
>
>  - there is a list of zero or more classes. A class may be either one
> that is explicitly specified on a panel or "" (anonymous panel)
>  - at the end there is an element type (panel, edit, text, image, ...)
> and an optional class
>
> So the interface to the style resolver should accept this list of
> classes in some form and information on the final element and the
> resolver should return back the properties it knows about for this
> path (return a structure holding these or set them directly on the
> final element if passed to it or something).

Hi,

To support full path, except the last element, each element can appear
or not independent of others, for N level, this is 2^(N-1), for
example, four class aa, bb, cc, dd, we need to scan:

aa.bb.cc.dd
aa.bb.dd
aa.cc.dd
aa.dd
bb.cc.dd
bb.dd
cc.dd
dd

This is for every property. For every widget, the layout manger would
read at least margin_*, padding_*, attach_*, width, height, that's 16
property, widget like panel would need to read border_*, left/top/.. ,
an extra of 15 property, the number can go out of control rapidly.
Anyway, how often do we need patterns like aa.bb.cc.dd ?

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/10 Bean <bean123ch@gmail.com>:
> On Sat, Oct 10, 2009 at 4:41 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/9 Bean <bean123ch@gmail.com>:
>>> On Sat, Oct 10, 2009 at 1:27 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> 2009/10/9 Bean <bean123ch@gmail.com>:
>>>>> On Sat, Oct 10, 2009 at 12:29 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>>> 2009/10/9 Bean <bean123ch@gmail.com>:
>>>>>>> On Fri, Oct 9, 2009 at 11:57 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>>>>> I am suggesting an interface that allows style commands like
>>>>>>>>
>>>>>>>> style {
>>>>>>>>
>>>>>>>> (class==button).(text==OK) { <style> }
>>>>>>>>
>>>>>>>> (class==dialog).<nothing here>.(class=button) { <style> }
>>>>>>>>
>>>>>>>> (class==buttonbar) { direction = right_to_left }
>>>>>>>>
>>>>>>>> (class==button) {
>>>>>>>> áborder_top = button_top
>>>>>>>> áborder_left = button_left
>>>>>>>> á...
>>>>>>>> }
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> for
>>>>>>>>
>>>>>>>> panel { class = dialog ; direction = top_to_bottom
>>>>>>>> ápanel {
>>>>>>>> á scroll = auto
>>>>>>>> á átext { Blah blah blah... }
>>>>>>>> á}
>>>>>>>> ápanel { class = buttonbar ;
>>>>>>>> ápanel { class = button ; img { check.png } ;text { OK } ; command =
>>>>>>>> <something> }
>>>>>>>> ápanel { class = button ; img { cross.png } ;text { Cancel } ;
>>>>>>>> command = <something>}
>>>>>>>> á}
>>>>>>>> }
>>>>>>>>
>>>>>>>> The exact syntax and semantic of the selectors it to be defined.
>>>>>>>>
>>>>>>>> They may be imperative commands that are applied immediately to all
>>>>>>>> widgets currently in existence or they may be stored in a style
>>>>>>>> database that widgets consult each time they are drawn or some
>>>>>>>> combination of the above (for example the style commands affect a
>>>>>>>> style database in order of appearance but do not affect widgets
>>>>>>>> directly).
>>>>>>>>
>>>>>>>> I guess the styles that appear in the main config (grub.cfg or loaded
>>>>>>>> by loadcfg) should be added together so that scripts that generate
>>>>>>>> different parts of the file can add style bits for their widgets.
>>>>>>>>
>>>>>>>> loadstyle command should reset all widget style properties to default
>>>>>>>> (either widget default or the state after loading config) and then
>>>>>>>> interpret the content of the file as if it was enclosed in style {}.
>>>>>>>>
>>>>>>>> When loadstyle is repeated the widgets should be reset again so that
>>>>>>>> previous style cannot affect the newly loaded style.
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Perhaps it can be written like this:
>>>>>>>
>>>>>>> class {
>>>>>>
>>>>>> perhaps this should be
>>>>>>
>>>>>> style {
>>>>>>
>>>>>>> ábutton.text_OK { <style>}
>>>>>>
>>>>>> text_OK is quite ugly for a selector that specifies that the property
>>>>>> text should be equal OK.
>>>>>>
>>>>>> What if the text contains a space or underscore or the property
>>>>>> contains underscore?
>>>>>>
>>>>>>> ádialog.*button { <style> }
>>>>>>
>>>>>> perhaps this should be
>>>>>>
>>>>>> dialog.*.button
>>>>>>
>>>>>> meaning there is one element in between or
>>>>>>
>>>>>> dialog.**.button
>>>>>>
>>>>>> meaning there can be zero or more elements in between {which is sorely
>>>>>> missing from CSS}
>>>>>
>>>>> Hi,
>>>>>
>>>>> Do we need to distinguish the situation that exactly one element is in
>>>>> between ?
>>>>>
>>>>>>
>>>>>>> ábuttonbar { direction = right_to_left }
>>>>>>> ábutton { áborder_top = button_top áborder_left = button_left }
>>>>>>> }
>>>>>>>
>>>>>>> panel { class = dialog ; direction = top_to_bottom
>>>>>>> ápanel {
>>>>>>> á scroll = auto
>>>>>>> á átext { Blah blah blah... }
>>>>>>> á}
>>>>>>> ápanel { class = buttonbar ;
>>>>>>> ápanel { class = button ; img { check.png } ;text { class=text_OK } ;
>>>>>>> command =<something> }
>>>>>>> ápanel { class = button ; img { cross.png } ;text { class=text_Cancel
>>>>>>> } ; command = <something>}
>>>>>>> á}
>>>>>>> á}
>>>>>>>
>>>>>>
>>>>>> This resolves the syntax issue somewhat but there is still problem
>>>>>> with the order in which the rules are applied.
>>>>>
>>>>> We can first try parent*class format, from near to far, then class
>>>>> itself. If class is not set, use the widget name, for example, in the
>>>>> following config:
>>>>>
>>>>> panel
>>>>> {
>>>>> áclass = aa
>>>>> ápanel {
>>>>> áclass = bb
>>>>> ápanel {
>>>>> á átext { class=cc id=text1 }
>>>>> á}
>>>>> átext { id=text2}
>>>>> }
>>>>>
>>>>> We scan the following section in order:
>>>>>
>>>>> text1:
>>>>> bb.cc
>>>>> bb.**.cc:
>>>>> aa.*.cc
>>>>> aa.**.cc
>>>>> cc
>>>>
>>>> I would guess it should be
>>>>
>>>> * /* everything */
>>>> text /* = **.text */
>>>> cc /* class specified */
>>>> aa.**.text
>>>> aa.**.cc
>>>> bb.**.text /* nearer start*/
>>>> bb.**.cc
>>>> aa.*.text /* less starry */
>>>> aa.*,cc
>>>> bb.text
>>>> bb.cc
>>>> aa.bb..text /* more elements specified in the path */
>>>> aa.bb.cc
>>>>
>>>> meaning that a property can be set by any of the above but the later
>>>> styles (lower in the list) can override properties set earlier.
>>>>
>>>> This is similar to what X props or CSS would do - the resulting
>>>> properties do not depend on the order of styling in text but on how
>>>> "specific" the selector is.
>>>>
>>>> This requires a style store separate from the widgets but likely
>>>> results in somewhat tidier and better predicatble behaviour than
>>>> setting the properties directly on the widgets. The separate style
>>>> store also means that you can save the state before loading a style
>>>> and reset it later quite easily.
>>>>
>>>> Overriding styles in this system is problematic, that's why the
>>>> properties should be reset when a different style is loaded.
>>>>
>>>> The properties set directly on the widgets should be probably
>>>> consulted first, before the * style, and it should be possible to
>>>> restore them when the style is changed.
>>>
>>> Hi,
>>>
>>> Currently, the menu system don't store class property in widget, this
>>> make it easier to change theme, we just reload the class tree and
>>> reinit the screen. It checks local properties first, if not found,
>>> check the class tree for default value, so the scan order should be
>>> reversed, it quits as soon as one match is found.
>>>
>>> For starters, we can just implement two level pattern parent*class, as
>>> each property would need to scan the tree for matches, deep level
>>> would mean a lot of iteration and could have a impact on performance.
>>
>> I don't think this is too much of a problem. How deep a typical layout
>> will be? Ten levels? Do ten pointer dereferences slow down grub? There
>> are components in the current system that are much slower (ie fonts
>> and drawing) so we should not really care.
>>
>> Even if this becomes problem in the future given a reasonable
>> interface to the style resolver the matching can be optimized later.
>>
>> It seems that the paths are in fact very simple:
>>
>>  - there is a list of zero or more classes. A class may be either one
>> that is explicitly specified on a panel or "" (anonymous panel)
>>  - at the end there is an element type (panel, edit, text, image, ...)
>> and an optional class
>>
>> So the interface to the style resolver should accept this list of
>> classes in some form and information on the final element and the
>> resolver should return back the properties it knows about for this
>> path (return a structure holding these or set them directly on the
>> final element if passed to it or something).
>
> Hi,
>
> To support full path, except the last element, each element can appear
> or not independent of others, for N level, this is 2^(N-1), for
> example, four class aa, bb, cc, dd, we need to scan:
>
> aa.bb.cc.dd
> aa.bb.dd
> aa.cc.dd
> aa.dd
> bb.cc.dd
> bb.dd
> cc.dd
> dd
>
> This is for every property. For every widget, the layout manger would
> read at least margin_*, padding_*, attach_*, width, height, that's 16
> property, widget like panel would need to read border_*, left/top/.. ,
> an extra of 15 property, the number can go out of control rapidly.
> Anyway, how often do we need patterns like aa.bb.cc.dd ?

I would put it differently: is single level selector enough? Are you
sure you will never want to select an element on which somebody forgot
to put a class?

For me the answer is no. So I am not sure how many levels I need. I am
sure one is insufficient and I doubt a fixed number like two levels
would do.

Note however that you need not check combinations that do not exist in
the style.

The "specificity" rule gives ordering independent of the actual
element matched against the style (with the exception of a.**.b which
may designate a shorter or longer path depending on the actual
element).

Let's ignore the ** issue for now and sort the list of style rules by
specificity.

Let's assume that the style resolver gets a pointer to the element
matched and this element contains the class name, element type, and
parent pointer in its common data.

As a first step you can count the number of parent elements and skip
any style rules that specify too many elements.

Now you create a zeroed structure that contains *all* style properties
that an element can have, and a bitmap which says which are set.

You walk the list of rules (which can have similar structures
attached) and add the properties from the rules. When the structure is
full or there are no more rules you are done.

You can save this structure in the element until style changes.

It would be nice to have this structure extensible but since there are
no bindings for a scripting language there is no point. Any extension
requires recompiling grub anyway. The structure should perhaps include
version (or size or something) if multiple modules use it so that a
module that expects more fields does not write outside of the
structure.

When there are bindings to a scripting language this structure should
be replaced by a hash implemented in the runtime of that language (any
structure of key-value pairs where values are easily retrieved by key
and it is also easily determined if a value for a particular key
exists).

The ** issue can be ignored (= the behavior is undefined in that case)
or a special check can be included for this case.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Add command menu_start, menu_popup, menu_toggle_mode and menu_refresh.

The new demo shows a menu bar at the left, you can use UP/DOWN key to
navigate, the menu items are:

graphic mode/text mode
This allows you to switch between text mode and graphic mode dynamically.

term
open a popup window that contain a terminal. enter command to execute,
press ESC to close the popup window and return to the main menu

theme
Allow you to change theme, you can select one of three themes in the
popup menu, then press enter to apply, use ESC if you want to skip it.

halt
shutdown the computer

reboot
reboot the computer

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

Hello

2009/10/10 Bean <bean123ch@gmail.com>:
> Hi,
>
> Update:
>
> Add command menu_start, menu_popup, menu_toggle_mode and menu_refresh.

This is very good, it's possible to run something with the menu now.


I wonder why the popup menu shows on the same screen as the main menu.
AFAIK it is impossible to return to the main menu without closing the
popup first. There does not seem to be any protection from the popup
overlapping the main menu (which would be ugly) and if there were the
main menu would needlessly occupy space in case the popup contained
more content (think the long help texts that distributions include in
syslinux).

I suggest that the popup should replace the "screen" element and when
it is closed the previous screen should be restored. It might be nice
to include the command line as the first screen under the main menu.


Is it possible to include the menu in the main config file?

I am not sure this would be that much useful because a font is
required for menu in graphics mode anyway so there are very few cases
when a single file would be enough. It might be nice for people who do
have text mode, though.


The terminal is somewhat odd.

The tab character does not seem to work in the terminal. When I write
"ls (" and press tab nothing happens.

Pressing space (or any other key) in text mode seems to draw the
terminal cursor all over the terminal area momentarily.

Pressing backspace at the prompt (when there is nothing typed or
everything is already deleted) seems to break the terminal.

When I type help it waits some seconds and then shows like 2/3-screen
of text. This is because scrolling always brings last line somewhere
into 2/3 of the screen and leaves the last 1/3 blank. I know gfxterm
is already slow but the new terminal seems even slower. The new
terminal does not even show the scrolled part of the text at all. This
would be useful if we had less/more. It is true the scrolling in
gfxterm is abysmally slow but at least it shows the text.


Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Sun, Oct 11, 2009 at 6:54 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> Hello
>
> 2009/10/10 Bean <bean123ch@gmail.com>:
>> Hi,
>>
>> Update:
>>
>> Add command menu_start, menu_popup, menu_toggle_mode and menu_refresh.
>
> This is very good, it's possible to run something with the menu now.
>
>
> I wonder why the popup menu shows on the same screen as the main menu.
> AFAIK it is impossible to return to the main menu without closing the
> popup first. There does not seem to be any protection from the popup
> overlapping the main menu (which would be ugly) and if there were the
> main menu would needlessly occupy space in case the popup contained
> more content (think the long help texts that distributions include in
> syslinux).
>
> I suggest that the popup should replace the "screen" element and when
> it is closed the previous screen should be restored. It might be nice
> to include the command line as the first screen under the main menu.

Hi,

Sometimes it's desired to place the popup alongside the current
screen. For example, we can use this to implement the submenu, which
is pop near the current menu. Anyway, to replace screen, you can use a
non transparent panel as the top widget of popup:

panel
{
  width = 100%
  height = 100%
  background = ",,black,#0"
}

>
>
> Is it possible to include the menu in the main config file?
>
> I am not sure this would be that much useful because a font is
> required for menu in graphics mode anyway so there are very few cases
> when a single file would be enough. It might be nice for people who do
> have text mode, though.
>
>
> The terminal is somewhat odd.
>
> The tab character does not seem to work in the terminal. When I write
> "ls (" and press tab nothing happens.

The tab completion function from normal.mod yet haven't been integrated yet.

>
> Pressing space (or any other key) in text mode seems to draw the
> terminal cursor all over the terminal area momentarily.

Right, I should hide the cursor while updating the screen.

>
> Pressing backspace at the prompt (when there is nothing typed or
> everything is already deleted) seems to break the terminal.

The term would execute the line only if it starts with prompt "grub>
", otherwise it's just an editor, this means you can use UP/PAGEUP to
go back to previous content easier. when you use backspace at prompt,
the prompt is changed so it can't be identified anymore, you can use
DOWN to start a new line and a new prompt would be printed.

>
> When I type help it waits some seconds and then shows like 2/3-screen
> of text. This is because scrolling always brings last line somewhere
> into 2/3 of the screen and leaves the last 1/3 blank. I know gfxterm
> is already slow but the new terminal seems even slower. The new
> terminal does not even show the scrolled part of the text at all. This
> would be useful if we had less/more. It is true the scrolling in
> gfxterm is abysmally slow but at least it shows the text.

Currently the terminal always return dummy width 0x7f, so the line
would be very long in help command, I can return a more reasonable
value.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/11 Bean <bean123ch@gmail.com>:
> On Sun, Oct 11, 2009 at 6:54 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> Hello
>>
>> 2009/10/10 Bean <bean123ch@gmail.com>:
>>> Hi,
>>>
>>> Update:
>>>
>>> Add command menu_start, menu_popup, menu_toggle_mode and menu_refresh.
>>
>> This is very good, it's possible to run something with the menu now.
>>
>>
>> I wonder why the popup menu shows on the same screen as the main menu.
>> AFAIK it is impossible to return to the main menu without closing the
>> popup first. There does not seem to be any protection from the popup
>> overlapping the main menu (which would be ugly) and if there were the
>> main menu would needlessly occupy space in case the popup contained
>> more content (think the long help texts that distributions include in
>> syslinux).
>>
>> I suggest that the popup should replace the "screen" element and when
>> it is closed the previous screen should be restored. It might be nice
>> to include the command line as the first screen under the main menu.
>
> Hi,
>
> Sometimes it's desired to place the popup alongside the current
> screen. For example, we can use this to implement the submenu, which

It's not because then you have to manually ensure that it does not
overlap any previous or future popup and does not fall off the screen
edge either. We don't have window management because there is no
concurrency and we don't have overlap support so no multiple windows,
please.

> is pop near the current menu. Anyway, to replace screen, you can use a
> non transparent panel as the top widget of popup:
>
> panel
> {
>  width = 100%
>  height = 100%
>  background = ",,black,#0"
> }
>
>>
>>
>> Is it possible to include the menu in the main config file?
>>
>> I am not sure this would be that much useful because a font is
>> required for menu in graphics mode anyway so there are very few cases
>> when a single file would be enough. It might be nice for people who do
>> have text mode, though.
>>
>>
>> The terminal is somewhat odd.
>>
>> The tab character does not seem to work in the terminal. When I write
>> "ls (" and press tab nothing happens.
>
> The tab completion function from normal.mod yet haven't been integrated yet.
>
>>
>> Pressing space (or any other key) in text mode seems to draw the
>> terminal cursor all over the terminal area momentarily.
>
> Right, I should hide the cursor while updating the screen.

The other point is it need not be repainted. What happened to the
"repaint only changed parts of the screen" feature?

>>
>> Pressing backspace at the prompt (when there is nothing typed or
>> everything is already deleted) seems to break the terminal.
>
> The term would execute the line only if it starts with prompt "grub>
> ", otherwise it's just an editor, this means you can use UP/PAGEUP to
> go back to previous content easier. when you use backspace at prompt,
> the prompt is changed so it can't be identified anymore, you can use
> DOWN to start a new line and a new prompt would be printed.

This is interesting but people don't expect that a prompt can be
removed so this is quite confusing.
If this terminal is supposed to be usable this issue should be resolved.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Optimize update algorithm for term widget, now it should only update
the necessary regions.

Fix prompt handling in term, you can't use backspace to erase prompt
or use left to move before it, home would jump to position after the
prompt.

BTW, menu branch has been merged with master, new code would push to
the master branch directly.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Add sub menu support, generate widgets dynamically using menu entries.

Now grub.cfg should look like this:

menuentry "AAA" {
  set root=(hd0,1)
  chainloader +1
}

menuentry "BBB" --class ubuntu {
  true
}

. /menu/menu.cfg

The menu have three items, AAA, BBB and Tools, which is a menu
appended in menu.cfg.

Tools are a submenu, its content is defined using menu section:

menu {
  Tools {
    "Toggle Mode" {
      command = menu_toggle_mode
    }

    "Terminal" {
      command = "menu_popup term_window"
    }

    "Change Theme" {
      Default {
        command="load_config /menu/blue.txt\nmenu_refresh"
      }

      Green {
        command="load_config /menu/green.txt\nmenu_refresh"
      }

      White {
        command="load_config /menu/white.txt\nmenu_refresh"
      }
    }

    "Layout Demo" {
      command = "menu_popup layout_test"
    }

    Halt {
      command = "halt"
    }

    Reboot {
      command = "reboot"
    }
  }
}

merge_config command would append this with user defined menu items.

The screen section is very simple now:

screen {
  panel {
    extend = 1
    valign = center
    halign = center

    panel {
      class = frame
      id = __menu__
    }
  }
}

command menu_create would scan screen for id __menu__, and add widgets
according to the menu content. The generated widget entry looks like
this:

panel
{
  class = select
  command = COMMAND
  image { class =  CLASS }
  text { text = TITLE }
}

The submenu is this:

panel
{
  class = frame
  command = "menu_popup -r menu_tree N"
}

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Add mapkey section. For example:

mapkey {
  f5 = ctrl-x
}

maps f5 key to ctrl-x, this is important for platforms like EFI as
ctrl-x can't be input.

key name should be lowercase, it can be single character, f1 to f10,
ctrl-a to ctrl-z, left, right, up, down, home, end, delete, page_up,
page_down, esc, tab, backspace and space.

Add onkey section, which allow you to assign a function when a key is
pressed. For example ,this is the onkey section for the demo:

onkey {
  c = "menu_popup term_window"
  e = "menu_popup edit_window edit.text=command"
  f7 = "menu_popup layout_test"
  f8 = menu_toggle_mode
  f9 = halt
  f10 = reboot
}

c open a terminal window, e open a edit box to edit the current
command, use ctrl-x to save it. f7 runs the layout demo test, f8
toggle between text and graphic mode, f9 shutdown, f10 reboot.

Data binding for popup windows, for example, in the above example,

menu_popup edit_window edit.text=command

property text in the edit widget in the popup dialog binds to the
command property of current node, this is used to implement the edit
function.

Add two property attach_hcenter and attach_vcenter for layout manager.
The top widget of popup window must use absolute position, as widget
are already placed in screen and can't be moved without refresh. But
it's not easy to put the widget in the middle of screen using
attach_left/right/top/bottom, the new property attach_hcenter and
attach_vcenter defines the offset from the center of screen.

Support TAB completion for term widget.

Misc optimization for graphic updates, now it should run quite smooth.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Add dialog support, it allows you to write a template and call it with
different parameters, for example:

dialog_edit {
  panel {
    parameters = "text=edit.text"
    class = frame
    width = 80%
    attach_hcenter = 0
    attach_vcenter = 0

    edit {
      lines = 10
    }
  }
}

The parameters property control the mapping between parameter and
internal property name. To use it to edit current command:

menu_edit dialog_edit text=command

It also allows you to edit other properties, for example, the demo add
a hotkey t to edit the title:

t = "menu_edit dialog_edit text=title\nmenu_refresh"

The generated menu also uses templates, one for submenu, and one for menuitem:

menu_template {
  panel {
    class = frame
  }
}

item_template {
  panel {
    parameters = "class=image.class:title=text.text"
    class = select
    image {}
    text {}
  }
}

The names of the template is passed to menu_create command:

menu_create menu_template item_template.

Smart popup window. The sub menu would pop to the direction with the
most space, which would make sure it won't be truncated by the border.
For example, if the parent menu is at the top of screen, sub menu pops
at the bottom, if it's at the bottom, sub menu pops at the top.

add command menu_next_node, menu_prev_node, menu_next_anchor and
menu_prev_anchor, you can assign these to other keys. The demo adds
the two terminal example. Inside terminal, direction key and TAB are
all used, so you need to assign another hotkey to switch between the
two window. The demo uses f6:

f6 = menu_next_anchor

Set maximum text mode in EFI.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

Hello

2009/10/17 Bean <bean123ch@gmail.com>:
> Hi,
>
> Update:
>
> Add sub menu support, generate widgets dynamically using menu entries.

The example is very complex and I don't quite understand what is the
advantage of this baroque scheme over generating the menus in grub.d
in files like 00_header or 10_linux.

For example, each menuentry for loading a linux kernel is generated by
a function in 10_linux which in turn calls functions from
grub-mkconfig_lib. Thus it is possible to create arbitrarily complex
menu entries without additional C code in grub or user-edited
configuration. I don't see why these shell scripts cannot include all
the panels and stuff needed for the new menu and have to be generated
by C code in grub.

>
> Now grub.cfg should look like this:
>
> menuentry "AAA" {
>  set root=(hd0,1)
>  chainloader +1
> }
>
> menuentry "BBB" --class ubuntu {
>  true
> }
>
> . /menu/menu.cfg
>
> The menu have three items, AAA, BBB and Tools, which is a menu
> appended in menu.cfg.
>
> Tools are a submenu, its content is defined using menu section:
>
> menu {
>  Tools {
>    "Toggle Mode" {
>      command = menu_toggle_mode
>    }
>
>    "Terminal" {
>      command = "menu_popup term_window"
>    }
>
>    "Change Theme" {
>      Default {
>        command="load_config /menu/blue.txt\nmenu_refresh"
>      }
>
>      Green {
>        command="load_config /menu/green.txt\nmenu_refresh"
>      }
>
>      White {
>        command="load_config /menu/white.txt\nmenu_refresh"
>      }
>    }
>
>    "Layout Demo" {
>      command = "menu_popup layout_test"
>    }
>
>    Halt {
>      command = "halt"
>    }
>
>    Reboot {
>      command = "reboot"
>    }
>  }
> }
>
> merge_config command would append this with user defined menu items.
>
> The screen section is very simple now:
>
> screen {
>  panel {
>    extend = 1
>    valign = center
>    halign = center
>
>    panel {
>      class = frame
>      id = __menu__
>    }
>  }
> }

So you invent a new property here just to bind the menu to a panel. If
you insist then screen should be a panel { id = __screen__ }.

>
> command menu_create would scan screen for id __menu__, and add widgets
> according to the menu content. The generated widget entry looks like
> this:
>
> panel
> {
>  class = select
>  command = COMMAND
>  image { class =  CLASS }
>  text { text = TITLE }
> }

And if I want a slightly different structure I have to patch and
recompile grub. I also wonder how do you specify the image bitmap here
because it's the sole content of the image so it should not be
specified by style.

>
> The submenu is this:
>
> panel
> {
>  class = frame
>  command = "menu_popup -r menu_tree N"
> }
>

I have no idea what the above is supposed to mean. Care to explain?

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/18 Bean <bean123ch@gmail.com>:
> Hi,
>
> Update:
>
> Add mapkey section. For example:
>
> mapkey {
>  f5 = ctrl-x
> }

Does this also generate a mapkey text which you can dump into a text
box so that people know what is mapped to what (and the same for the
default bindings and grub version/last git commit)?

Wouldn't it be more practical and transparent to just make the
mappings configurable?

That is write the current mappings as key->function assignments and
then allow change mappings / add new mappings.

>
> maps f5 key to ctrl-x, this is important for platforms like EFI as
> ctrl-x can't be input.
>
> key name should be lowercase, it can be single character, f1 to f10,
> ctrl-a to ctrl-z, left, right, up, down, home, end, delete, page_up,
> page_down, esc, tab, backspace and space.
>
> Add onkey section, which allow you to assign a function when a key is
> pressed. For example ,this is the onkey section for the demo:
>
> onkey {
>  c = "menu_popup term_window"
>  e = "menu_popup edit_window edit.text=command"
>  f7 = "menu_popup layout_test"
>  f8 = menu_toggle_mode
>  f9 = halt
>  f10 = reboot
> }

This should be merged with the mapkey into a single key mapping function.

>
> c open a terminal window, e open a edit box to edit the current
> command, use ctrl-x to save it. f7 runs the layout demo test, f8
> toggle between text and graphic mode, f9 shutdown, f10 reboot.
>
> Data binding for popup windows, for example, in the above example,
>
> menu_popup edit_window edit.text=command
>
> property text in the edit widget in the popup dialog binds to the
> command property of current node, this is used to implement the edit
> function.
>
> Add two property attach_hcenter and attach_vcenter for layout manager.

What is the actual use case for windows which are not managed in the
layout and thus potentially overlap other windows in a system where
window overlapping is not handled?

> The top widget of popup window must use absolute position, as widget
> are already placed in screen and can't be moved without refresh. But
> it's not easy to put the widget in the middle of screen using
> attach_left/right/top/bottom, the new property attach_hcenter and
> attach_vcenter defines the offset from the center of screen.

Can't you just make the popup fullscreen?

IMHO it rids us of quite a few things  that allow people to shoot
themselves in the foot and require documentation and maintenance while
not removing anything particularly useful.

>
> Support TAB completion for term widget.

That's very nice.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/20 Bean <bean123ch@gmail.com>:
> Hi,
>
> Update:
>
> Add dialog support, it allows you to write a template and call it with
> different parameters, for example:
>
> dialog_edit {
>  panel {
>    parameters = "text=edit.text"
>    class = frame
>    width = 80%
>    attach_hcenter = 0
>    attach_vcenter = 0
>
>    edit {
>      lines = 10
>    }
>  }
> }

I can see this used for the edit boxen and text mesasge dialogs which
would be quite similar.

Also the templating seems quite flexible and versatile.

However, can't this be done with a shell function?

Both the grub.d scripts and grub.cfg can define a function with a few
parameters to achieve pretty much the same results.

IIRC one of the sample menu.cfg files defined functions as part of
grub configuration so we do not need another facility for this.

>
> The parameters property control the mapping between parameter and
> internal property name. To use it to edit current command:
>
> menu_edit dialog_edit text=command
>
> It also allows you to edit other properties, for example, the demo add
> a hotkey t to edit the title:
>
> t = "menu_edit dialog_edit text=title\nmenu_refresh"
>
> The generated menu also uses templates, one for submenu, and one for menuitem:
>
> menu_template {
>  panel {
>    class = frame
>  }
> }
>
> item_template {
>  panel {
>    parameters = "class=image.class:title=text.text"
>    class = select
>    image {}
>    text {}
>  }
> }
>
> The names of the template is passed to menu_create command:
>
> menu_create menu_template item_template.
>
> Smart popup window. The sub menu would pop to the direction with the
> most space, which would make sure it won't be truncated by the border.

It won't. You cannot know how much space the "most space" is.

> For example, if the parent menu is at the top of screen, sub menu pops
> at the bottom, if it's at the bottom, sub menu pops at the top.
>
> add command menu_next_node, menu_prev_node, menu_next_anchor and
> menu_prev_anchor, you can assign these to other keys. The demo adds
> the two terminal example. Inside terminal, direction key and TAB are
> all used, so you need to assign another hotkey to switch between the
> two window. The demo uses f6:
>
> f6 = menu_next_anchor

This is an interesting addition but I'm not sure where this would be used.

Normally one terminal is enough so you can just open it fullscreen and
close it when you want to do something else.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Peter Cros]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

I find that the 2 terminal configuration with hotkey switch can be very
useful alternative in some situations (debugging ...) , particularly on
1920x1200 screen.  Single screen popup can be default for normal use.

On Wed, Oct 21, 2009 at 6:31 AM, Michal Suchanek <hramrach@centrum.cz>wrote:

> 2009/10/20 Bean <bean123ch@gmail.com>:
>
> > menu_prev_anchor, you can assign these to other keys. The demo adds
> > the two terminal example. Inside terminal, direction key and TAB are
> > all used, so you need to assign another hotkey to switch between the
> > two window. The demo uses f6:
> >
> > f6 = menu_next_anchor
>
> This is an interesting addition but I'm not sure where this would be used.
>
> Normally one terminal is enough so you can just open it fullscreen and
> close it when you want to do something else.
>
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Cros (pxw)

[-- Attachment #2: Type: text/html, Size: 1659 bytes --]

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Wed, Oct 21, 2009 at 3:06 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> Hello
>
> 2009/10/17 Bean <bean123ch@gmail.com>:
>> Hi,
>>
>> Update:
>>
>> Add sub menu support, generate widgets dynamically using menu entries.
>
> The example is very complex and I don't quite understand what is the
> advantage of this baroque scheme over generating the menus in grub.d
> in files like 00_header or 10_linux.
>
> For example, each menuentry for loading a linux kernel is generated by
> a function in 10_linux which in turn calls functions from
> grub-mkconfig_lib. Thus it is possible to create arbitrarily complex
> menu entries without additional C code in grub or user-edited
> configuration. I don't see why these shell scripts cannot include all
> the panels and stuff needed for the new menu and have to be generated
> by C code in grub.
>

Hi,

Don't forget that menu items can be generated at runtime. For example,
with my osdetect,lua script, it's possible to scan the disk for
existing OS and add them to the menu automatically, so a generic
config file can be used. This is quite useful in removable boot media
like usb and cdrom, as you can't predict in advanced what OS would be
present when the media boots. In this case, the menu have to be
generated dynamically as well.

>>
>> Now grub.cfg should look like this:
>>
>> menuentry "AAA" {
>>  set root=(hd0,1)
>>  chainloader +1
>> }
>>
>> menuentry "BBB" --class ubuntu {
>>  true
>> }
>>
>> . /menu/menu.cfg
>>
>> The menu have three items, AAA, BBB and Tools, which is a menu
>> appended in menu.cfg.
>>
>> Tools are a submenu, its content is defined using menu section:
>>
>> menu {
>>  Tools {
>>    "Toggle Mode" {
>>      command = menu_toggle_mode
>>    }
>>
>>    "Terminal" {
>>      command = "menu_popup term_window"
>>    }
>>
>>    "Change Theme" {
>>      Default {
>>        command="load_config /menu/blue.txt\nmenu_refresh"
>>      }
>>
>>      Green {
>>        command="load_config /menu/green.txt\nmenu_refresh"
>>      }
>>
>>      White {
>>        command="load_config /menu/white.txt\nmenu_refresh"
>>      }
>>    }
>>
>>    "Layout Demo" {
>>      command = "menu_popup layout_test"
>>    }
>>
>>    Halt {
>>      command = "halt"
>>    }
>>
>>    Reboot {
>>      command = "reboot"
>>    }
>>  }
>> }
>>
>> merge_config command would append this with user defined menu items.
>>
>> The screen section is very simple now:
>>
>> screen {
>>  panel {
>>    extend = 1
>>    valign = center
>>    halign = center
>>
>>    panel {
>>      class = frame
>>      id = __menu__
>>    }
>>  }
>> }
>
> So you invent a new property here just to bind the menu to a panel. If
>
 you insist then screen should be a panel { id = __screen__ }.
>

id can be useful in templates to name children widgets having the same name.

>>
>> command menu_create would scan screen for id __menu__, and add widgets
>> according to the menu content. The generated widget entry looks like
>> this:
>>
>> panel
>> {
>>  class = select
>>  command = COMMAND
>>  image { class =  CLASS }
>>  text { text = TITLE }
>> }
>
> And if I want a slightly different structure I have to patch and
> recompile grub. I also wonder how do you specify the image bitmap here
> because it's the sole content of the image so it should not be
> specified by style.
>

See my latest patch, this have already been replaced by templates. You
specify the template names in menu_create command:

menu_create menu_template item_template

item_template {
  panel {
    parameters = "class=image.class:title=text.text"
    class = select
    direction = left_to_right
    image {}
    text { valign = center }
  }
}

In the template, parameters property sets the mapping between external
parameter name and internal properties. for example, this example
shows class is mapped to class property of image widget, and title is
mapped to text property of text widget.

>>
>> The submenu is this:
>>
>> panel
>> {
>>  class = frame
>>  command = "menu_popup -r menu_tree N"
>> }
>>
>
> I have no idea what the above is supposed to mean. Care to explain?

menu_popup create a popup window using template, menu_tree is an
section auto generated by menu_create, N is the index of children
widget. BTW, the syntax has changed in the latest patch to:

menu_popup -ri N menu_tree

The index is moved as option, as we can append assignment after the name.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Wed, Oct 21, 2009 at 3:20 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/18 Bean <bean123ch@gmail.com>:
>> Hi,
>>
>> Update:
>>
>> Add mapkey section. For example:
>>
>> mapkey {
>>  f5 = ctrl-x
>> }
>
> Does this also generate a mapkey text which you can dump into a text
> box so that people know what is mapped to what (and the same for the
> default bindings and grub version/last git commit)?
>
> Wouldn't it be more practical and transparent to just make the
> mappings configurable?
>
> That is write the current mappings as key->function assignments and
> then allow change mappings / add new mappings.
>
>>
>> maps f5 key to ctrl-x, this is important for platforms like EFI as
>> ctrl-x can't be input.
>>
>> key name should be lowercase, it can be single character, f1 to f10,
>> ctrl-a to ctrl-z, left, right, up, down, home, end, delete, page_up,
>> page_down, esc, tab, backspace and space.
>>
>> Add onkey section, which allow you to assign a function when a key is
>> pressed. For example ,this is the onkey section for the demo:
>>
>> onkey {
>>  c = "menu_popup term_window"
>>  e = "menu_popup edit_window edit.text=command"
>>  f7 = "menu_popup layout_test"
>>  f8 = menu_toggle_mode
>>  f9 = halt
>>  f10 = reboot
>> }
>
> This should be merged with the mapkey into a single key mapping function.
>

Hi,

The difference of mapkey and onkey is when they're executed. The order
is as follows:

mapkey
onkey function of current widget
key binding in onkey section

For example in the edit widget, you use ctrl-x to finish current edit.
But in EFI, you can't input ctrl-x. The way to solve this is to map
another key as ctrl-x, which use mapkey function. Adding function in
onkey doesn't help, as by the time it reaches there, the edit widget
has finish handling.

Also, if the key is used by widget, the binding in onkey doesn't help.
This is actually a good thing, for example,  we can add hotkey c to
open a terminal window. This has effect on main menu, but we certainly
don't want it when inside term already. But if we do need to change a
key used by widget, we can map it in mapkey section.

>>
>> c open a terminal window, e open a edit box to edit the current
>> command, use ctrl-x to save it. f7 runs the layout demo test, f8
>> toggle between text and graphic mode, f9 shutdown, f10 reboot.
>>
>> Data binding for popup windows, for example, in the above example,
>>
>> menu_popup edit_window edit.text=command
>>
>> property text in the edit widget in the popup dialog binds to the
>> command property of current node, this is used to implement the edit
>> function.
>>
>> Add two property attach_hcenter and attach_vcenter for layout manager.
>
> What is the actual use case for windows which are not managed in the
> layout and thus potentially overlap other windows in a system where
> window overlapping is not handled?

Popup window. For example, the e hotkey popup a edit box to edit
current command. The top window of popup is placed in screen directly
and not controlled by layout manger.

>
>> The top widget of popup window must use absolute position, as widget
>> are already placed in screen and can't be moved without refresh. But
>> it's not easy to put the widget in the middle of screen using
>> attach_left/right/top/bottom, the new property attach_hcenter and
>> attach_vcenter defines the offset from the center of screen.
>
> Can't you just make the popup fullscreen?
>
> IMHO it rids us of quite a few things  that allow people to shoot
> themselves in the foot and require documentation and maintenance while
> not removing anything particularly useful.

You can configure the sub menu to pop up full screen. But I like it
alongside the parent menu. IMO, this is the most common way to display
a submenu.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Wed, Oct 21, 2009 at 3:31 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/20 Bean <bean123ch@gmail.com>:
>> Hi,
>>
>> Update:
>>
>> Add dialog support, it allows you to write a template and call it with
>> different parameters, for example:
>>
>> dialog_edit {
>>  panel {
>>    parameters = "text=edit.text"
>>    class = frame
>>    width = 80%
>>    attach_hcenter = 0
>>    attach_vcenter = 0
>>
>>    edit {
>>      lines = 10
>>    }
>>  }
>> }
>
> I can see this used for the edit boxen and text mesasge dialogs which
> would be quite similar.
>
> Also the templating seems quite flexible and versatile.
>
> However, can't this be done with a shell function?
>
> Both the grub.d scripts and grub.cfg can define a function with a few
> parameters to achieve pretty much the same results.
>
> IIRC one of the sample menu.cfg files defined functions as part of
> grub configuration so we do not need another facility for this.
>

Hi,

IMO it's more easy to write widget this way, you can still pack it in
shell script as menu_popup support string argument:

menu_popup -s "panel { width=100% height=100% }"

This is fine for short code, but as the widget become more complex,
it's quite difficult to use this notion, especially when you add
command property which requires quotes. There seems to be some issue
with embedded quote handling.

>>
>> The parameters property control the mapping between parameter and
>> internal property name. To use it to edit current command:
>>
>> menu_edit dialog_edit text=command
>>
>> It also allows you to edit other properties, for example, the demo add
>> a hotkey t to edit the title:
>>
>> t = "menu_edit dialog_edit text=title\nmenu_refresh"
>>
>> The generated menu also uses templates, one for submenu, and one for menuitem:
>>
>> menu_template {
>>  panel {
>>    class = frame
>>  }
>> }
>>
>> item_template {
>>  panel {
>>    parameters = "class=image.class:title=text.text"
>>    class = select
>>    image {}
>>    text {}
>>  }
>> }
>>
>> The names of the template is passed to menu_create command:
>>
>> menu_create menu_template item_template.
>>
>> Smart popup window. The sub menu would pop to the direction with the
>> most space, which would make sure it won't be truncated by the border.
>
> It won't. You cannot know how much space the "most space" is.

First I calculate the central point of current node, if it's in the
top-left quadrant, I pop up sub menu at its bottom-right corner, etc.
The handling is quite simple and it should avoid popping up sub menu
off screen.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/21 Bean <bean123ch@gmail.com>:
> On Wed, Oct 21, 2009 at 3:20 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/18 Bean <bean123ch@gmail.com>:
>>> Hi,
>>>
>>> Update:
>>>
>>> Add mapkey section. For example:
>>>
>>> mapkey {
>>>  f5 = ctrl-x
>>> }
>>
>> Does this also generate a mapkey text which you can dump into a text
>> box so that people know what is mapped to what (and the same for the
>> default bindings and grub version/last git commit)?
>>
>> Wouldn't it be more practical and transparent to just make the
>> mappings configurable?
>>
>> That is write the current mappings as key->function assignments and
>> then allow change mappings / add new mappings.
>>
>>>
>>> maps f5 key to ctrl-x, this is important for platforms like EFI as
>>> ctrl-x can't be input.
>>>
>>> key name should be lowercase, it can be single character, f1 to f10,
>>> ctrl-a to ctrl-z, left, right, up, down, home, end, delete, page_up,
>>> page_down, esc, tab, backspace and space.
>>>
>>> Add onkey section, which allow you to assign a function when a key is
>>> pressed. For example ,this is the onkey section for the demo:
>>>
>>> onkey {
>>>  c = "menu_popup term_window"
>>>  e = "menu_popup edit_window edit.text=command"
>>>  f7 = "menu_popup layout_test"
>>>  f8 = menu_toggle_mode
>>>  f9 = halt
>>>  f10 = reboot
>>> }
>>
>> This should be merged with the mapkey into a single key mapping function.
>>
>
> Hi,
>
> The difference of mapkey and onkey is when they're executed. The order
> is as follows:
>
> mapkey
> onkey function of current widget
> key binding in onkey section
>
> For example in the edit widget, you use ctrl-x to finish current edit.
> But in EFI, you can't input ctrl-x. The way to solve this is to map
> another key as ctrl-x, which use mapkey function. Adding function in
> onkey doesn't help, as by the time it reaches there, the edit widget
> has finish handling.
>
> Also, if the key is used by widget, the binding in onkey doesn't help.
> This is actually a good thing, for example,  we can add hotkey c to
> open a terminal window. This has effect on main menu, but we certainly
> don't want it when inside term already. But if we do need to change a
> key used by widget, we can map it in mapkey section.

Why do you need a separate mapping?

The widget either handles the key or not, and it should pass it to its
parent if it does not handle it.

The function in question is either a widget specific function or not
so you know where it should be processed.

I am not sure what is the difference in mapkey and "onkey in current widget".

>
>>>
>>> c open a terminal window, e open a edit box to edit the current
>>> command, use ctrl-x to save it. f7 runs the layout demo test, f8
>>> toggle between text and graphic mode, f9 shutdown, f10 reboot.
>>>
>>> Data binding for popup windows, for example, in the above example,
>>>
>>> menu_popup edit_window edit.text=command
>>>
>>> property text in the edit widget in the popup dialog binds to the
>>> command property of current node, this is used to implement the edit
>>> function.
>>>
>>> Add two property attach_hcenter and attach_vcenter for layout manager.
>>
>> What is the actual use case for windows which are not managed in the
>> layout and thus potentially overlap other windows in a system where
>> window overlapping is not handled?
>
> Popup window. For example, the e hotkey popup a edit box to edit
> current command. The top window of popup is placed in screen directly
> and not controlled by layout manger.

In gfxterm the edit box is fullscreen and some lines still wrap for me
so I think it is the right way to handle these edits. They should get
as much space as possible, there can be (and typically is) quite a bit
of text.

You can add the title of the edited item as a label at the top of the
edit screen perhaps.

>
>>
>>> The top widget of popup window must use absolute position, as widget
>>> are already placed in screen and can't be moved without refresh. But
>>> it's not easy to put the widget in the middle of screen using
>>> attach_left/right/top/bottom, the new property attach_hcenter and
>>> attach_vcenter defines the offset from the center of screen.
>>
>> Can't you just make the popup fullscreen?
>>
>> IMHO it rids us of quite a few things  that allow people to shoot
>> themselves in the foot and require documentation and maintenance while
>> not removing anything particularly useful.
>
> You can configure the sub menu to pop up full screen. But I like it
> alongside the parent menu. IMO, this is the most common way to display
> a submenu.

What's the advantage of having submenu alongside the parent menu?

The disadvantage is complex, error-prone and inefficient layout
algorithm. How do you handle submenus that are larger than the screen
and would not fit in any case, for example. Or submenus that would
just fit if there wasn't any parent menu alongside the submenu. Or
submenus that are as wide/large as the screen but pop up from an item
in the middle of the screen.

Another disadvantage is cluttered screen. Many distributions present
timezone and/or language selection as menus. These are large
multilevel selections because putting all the options into one list is
quite useless, you could navigate all day just to find your timezone
and language. Imagine drawing these with the alongside-menu.

I see no advantage. For clarity you can put the name of the parent
item as a title of the menu screen so you know exactly where you are,
what are your choices, and the screen is not cluttered with other
inaccessible distracting rubbish.

I know that submenus displayed at some random point near the menu item
from which they were activated are often used in GUI toolkits but this
does not make the practice good or desirable. There are many corner
cases which are likely experienced on small screens (and grub may
often use small resolution for compatibility) which are quite
confusing. When there are multiple levels of such menus it gets very
messy and it is getting hard to find a sensible placing for new
submenus. It does not add to readability or anything, you still have
to walk the submenus to see which options are available.

An advantage of a simple menu it it can be also presented as a list of
choices on a dumb terminal (see Debian reportbug as a sample of such
interface or the difference between dpkg dialog and readline
frontends). No need to write a separate menu for that case, new
visualization should suffice.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/21 Bean <bean123ch@gmail.com>:
> On Wed, Oct 21, 2009 at 3:31 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/20 Bean <bean123ch@gmail.com>:
>>> Hi,
>>>
>>> Update:
>>>
>>> Add dialog support, it allows you to write a template and call it with
>>> different parameters, for example:
>>>
>>> dialog_edit {
>>> ápanel {
>>> á áparameters = "text=edit.text"
>>> á áclass = frame
>>> á áwidth = 80%
>>> á áattach_hcenter = 0
>>> á áattach_vcenter = 0
>>>
>>> á áedit {
>>> á á álines = 10
>>> á á}
>>> á}
>>> }
>>
>> I can see this used for the edit boxen and text mesasge dialogs which
>> would be quite similar.
>>
>> Also the templating seems quite flexible and versatile.
>>
>> However, can't this be done with a shell function?
>>
>> Both the grub.d scripts and grub.cfg can define a function with a few
>> parameters to achieve pretty much the same results.
>>
>> IIRC one of the sample menu.cfg files defined functions as part of
>> grub configuration so we do not need another facility for this.
>>
>
> Hi,
>
> IMO it's more easy to write widget this way, you can still pack it in
> shell script as menu_popup support string argument:
>
> menu_popup -s "panel { width=100% height=100% }"
>
> This is fine for short code, but as the widget become more complex,
> it's quite difficult to use this notion, especially when you add
> command property which requires quotes. There seems to be some issue
> with embedded quote handling.
>

Perhaps the notation is broken.

Why do you need the quotes there? The panel should be delimited by its {}.

Then you can write

popup_text() {
 menu_popup -s panel { width = 100% ; height = 100% ; direction = top_to_bottom
  panel { valign = expand ; halign = expand ; text { text = "$1" } }
  panel { halign = expand ; text { text = "OK" }}
 }


Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Oct 22, 2009 at 4:55 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/21 Bean <bean123ch@gmail.com>:
>> On Wed, Oct 21, 2009 at 3:31 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> 2009/10/20 Bean <bean123ch@gmail.com>:
>>>> Hi,
>>>>
>>>> Update:
>>>>
>>>> Add dialog support, it allows you to write a template and call it with
>>>> different parameters, for example:
>>>>
>>>> dialog_edit {
>>>> ápanel {
>>>> á áparameters = "text=edit.text"
>>>> á áclass = frame
>>>> á áwidth = 80%
>>>> á áattach_hcenter = 0
>>>> á áattach_vcenter = 0
>>>>
>>>> á áedit {
>>>> á á álines = 10
>>>> á á}
>>>> á}
>>>> }
>>>
>>> I can see this used for the edit boxen and text mesasge dialogs which
>>> would be quite similar.
>>>
>>> Also the templating seems quite flexible and versatile.
>>>
>>> However, can't this be done with a shell function?
>>>
>>> Both the grub.d scripts and grub.cfg can define a function with a few
>>> parameters to achieve pretty much the same results.
>>>
>>> IIRC one of the sample menu.cfg files defined functions as part of
>>> grub configuration so we do not need another facility for this.
>>>
>>
>> Hi,
>>
>> IMO it's more easy to write widget this way, you can still pack it in
>> shell script as menu_popup support string argument:
>>
>> menu_popup -s "panel { width=100% height=100% }"
>>
>> This is fine for short code, but as the widget become more complex,
>> it's quite difficult to use this notion, especially when you add
>> command property which requires quotes. There seems to be some issue
>> with embedded quote handling.
>>
>
> Perhaps the notation is broken.
>
> Why do you need the quotes there? The panel should be delimited by its {}.
>
> Then you can write

> popup_text() {
> menu_popup -s panel { width = 100% ; height = 100% ; direction = top_to_bottom
> panel { valign = expand ; halign = expand ; text { text = "$1" } }
>  panel { halign = expand ; text { text = "OK" }}
> }

Hi,

The above syntax is not accepted by sh parser, you have to enclose the
widget description it in strings:

popup_text() {
 menu_popup -s "panel { width = 100%  height = 100%  direction =
top_to_bottom panel { valign = expand  halign = expand  text { text =
\"$1\" } }  panel { halign = expand text { text = \"OK\" }}"
}

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Oct 22, 2009 at 4:47 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> 2009/10/21 Bean <bean123ch@gmail.com>:
>> On Wed, Oct 21, 2009 at 3:20 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> 2009/10/18 Bean <bean123ch@gmail.com>:
>>>> Hi,
>>>>
>>>> Update:
>>>>
>>>> Add mapkey section. For example:
>>>>
>>>> mapkey {
>>>>  f5 = ctrl-x
>>>> }
>>>
>>> Does this also generate a mapkey text which you can dump into a text
>>> box so that people know what is mapped to what (and the same for the
>>> default bindings and grub version/last git commit)?
>>>
>>> Wouldn't it be more practical and transparent to just make the
>>> mappings configurable?
>>>
>>> That is write the current mappings as key->function assignments and
>>> then allow change mappings / add new mappings.
>>>
>>>>
>>>> maps f5 key to ctrl-x, this is important for platforms like EFI as
>>>> ctrl-x can't be input.
>>>>
>>>> key name should be lowercase, it can be single character, f1 to f10,
>>>> ctrl-a to ctrl-z, left, right, up, down, home, end, delete, page_up,
>>>> page_down, esc, tab, backspace and space.
>>>>
>>>> Add onkey section, which allow you to assign a function when a key is
>>>> pressed. For example ,this is the onkey section for the demo:
>>>>
>>>> onkey {
>>>>  c = "menu_popup term_window"
>>>>  e = "menu_popup edit_window edit.text=command"
>>>>  f7 = "menu_popup layout_test"
>>>>  f8 = menu_toggle_mode
>>>>  f9 = halt
>>>>  f10 = reboot
>>>> }
>>>
>>> This should be merged with the mapkey into a single key mapping function.
>>>
>>
>> Hi,
>>
>> The difference of mapkey and onkey is when they're executed. The order
>> is as follows:
>>
>> mapkey
>> onkey function of current widget
>> key binding in onkey section
>>
>> For example in the edit widget, you use ctrl-x to finish current edit.
>> But in EFI, you can't input ctrl-x. The way to solve this is to map
>> another key as ctrl-x, which use mapkey function. Adding function in
>> onkey doesn't help, as by the time it reaches there, the edit widget
>> has finish handling.
>>
>> Also, if the key is used by widget, the binding in onkey doesn't help.
>> This is actually a good thing, for example,  we can add hotkey c to
>> open a terminal window. This has effect on main menu, but we certainly
>> don't want it when inside term already. But if we do need to change a
>> key used by widget, we can map it in mapkey section.
>
> Why do you need a separate mapping?
>
> The widget either handles the key or not, and it should pass it to its
> parent if it does not handle it.
>
> The function in question is either a widget specific function or not
> so you know where it should be processed.
>
> I am not sure what is the difference in mapkey and "onkey in current widget".
>

Hi,

Here, function means C function. In config file, all configurable
command is grub command, no command is specific to certain widget.
Widget have a onkey callback function which gives it the chance to
handle the current key press, if it doesn't handle it, it would be
passed to system.

So, you can use mapkey to map a key to the one interested by the
widget. For example, edit control use ctrl-x key to indicate the
finish of edit. If ctrl-x can't be input, you map F5 to it so that you
can finish the edit.

This is similar to the vim style of key handling, that's, each key
defines a specific function. I guess it's possible to use emacs style,
where each function is named with string. But I think that system is a
little overkill, you need to bind every function to some key before
you have a working system, while the current method works out of the
box, you just change the mapping you need.

>>>>
>>>> c open a terminal window, e open a edit box to edit the current
>>>> command, use ctrl-x to save it. f7 runs the layout demo test, f8
>>>> toggle between text and graphic mode, f9 shutdown, f10 reboot.
>>>>
>>>> Data binding for popup windows, for example, in the above example,
>>>>
>>>> menu_popup edit_window edit.text=command
>>>>
>>>> property text in the edit widget in the popup dialog binds to the
>>>> command property of current node, this is used to implement the edit
>>>> function.
>>>>
>>>> Add two property attach_hcenter and attach_vcenter for layout manager.
>>>
>>> What is the actual use case for windows which are not managed in the
>>> layout and thus potentially overlap other windows in a system where
>>> window overlapping is not handled?
>>
>> Popup window. For example, the e hotkey popup a edit box to edit
>> current command. The top window of popup is placed in screen directly
>> and not controlled by layout manger.
>
> In gfxterm the edit box is fullscreen and some lines still wrap for me
> so I think it is the right way to handle these edits. They should get
> as much space as possible, there can be (and typically is) quite a bit
> of text.
>
> You can add the title of the edited item as a label at the top of the
> edit screen perhaps.
>

I'm not sure showing a edit with only one or two lines full screen
have the best look, especially when screen is very large. Although you
can certainly config it that way. The choice is in the theme writer.

>>
>>>
>>>> The top widget of popup window must use absolute position, as widget
>>>> are already placed in screen and can't be moved without refresh. But
>>>> it's not easy to put the widget in the middle of screen using
>>>> attach_left/right/top/bottom, the new property attach_hcenter and
>>>> attach_vcenter defines the offset from the center of screen.
>>>
>>> Can't you just make the popup fullscreen?
>>>
>>> IMHO it rids us of quite a few things  that allow people to shoot
>>> themselves in the foot and require documentation and maintenance while
>>> not removing anything particularly useful.
>>
>> You can configure the sub menu to pop up full screen. But I like it
>> alongside the parent menu. IMO, this is the most common way to display
>> a submenu.
>
> What's the advantage of having submenu alongside the parent menu?
>
> The disadvantage is complex, error-prone and inefficient layout
> algorithm. How do you handle submenus that are larger than the screen
> and would not fit in any case, for example. Or submenus that would
> just fit if there wasn't any parent menu alongside the submenu. Or
> submenus that are as wide/large as the screen but pop up from an item
> in the middle of the screen.
>
> Another disadvantage is cluttered screen. Many distributions present
> timezone and/or language selection as menus. These are large
> multilevel selections because putting all the options into one list is
> quite useless, you could navigate all day just to find your timezone
> and language. Imagine drawing these with the alongside-menu.
>
> I see no advantage. For clarity you can put the name of the parent
> item as a title of the menu screen so you know exactly where you are,
> what are your choices, and the screen is not cluttered with other
> inaccessible distracting rubbish.
>
> I know that submenus displayed at some random point near the menu item
> from which they were activated are often used in GUI toolkits but this
> does not make the practice good or desirable. There are many corner
> cases which are likely experienced on small screens (and grub may
> often use small resolution for compatibility) which are quite
> confusing. When there are multiple levels of such menus it gets very
> messy and it is getting hard to find a sensible placing for new
> submenus. It does not add to readability or anything, you still have
> to walk the submenus to see which options are available.
>
> An advantage of a simple menu it it can be also presented as a list of
> choices on a dumb terminal (see Debian reportbug as a sample of such
> interface or the difference between dpkg dialog and readline
> frontends). No need to write a separate menu for that case, new
> visualization should suffice.

Actually the handling is very simple, by adding -r or --relative
option to menu_popup, it moves the widget in relates to parent using
attach_left/attach_right/attach_top/attach_bottom, instead of the
default location of top left corner. The problem you describe, sub
menu grows out of screen, this can happen even when full screen. It's
the job of scroller, which would scroll the widget into view when
selected. If you insist, I can just add a option to skip -r.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/22 Bean <bean123ch@gmail.com>:
> On Thu, Oct 22, 2009 at 4:47 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/21 Bean <bean123ch@gmail.com>:
>>> On Wed, Oct 21, 2009 at 3:20 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> 2009/10/18 Bean <bean123ch@gmail.com>:
>>>>> Hi,
>>>>>
>>>>> Update:
>>>>>
>>>>> Add mapkey section. For example:
>>>>>
>>>>> mapkey {
>>>>>  f5 = ctrl-x
>>>>> }
>>>>
>>>> Does this also generate a mapkey text which you can dump into a text
>>>> box so that people know what is mapped to what (and the same for the
>>>> default bindings and grub version/last git commit)?
>>>>
>>>> Wouldn't it be more practical and transparent to just make the
>>>> mappings configurable?
>>>>
>>>> That is write the current mappings as key->function assignments and
>>>> then allow change mappings / add new mappings.
>>>>
>>>>>
>>>>> maps f5 key to ctrl-x, this is important for platforms like EFI as
>>>>> ctrl-x can't be input.
>>>>>
>>>>> key name should be lowercase, it can be single character, f1 to f10,
>>>>> ctrl-a to ctrl-z, left, right, up, down, home, end, delete, page_up,
>>>>> page_down, esc, tab, backspace and space.
>>>>>
>>>>> Add onkey section, which allow you to assign a function when a key is
>>>>> pressed. For example ,this is the onkey section for the demo:
>>>>>
>>>>> onkey {
>>>>>  c = "menu_popup term_window"
>>>>>  e = "menu_popup edit_window edit.text=command"
>>>>>  f7 = "menu_popup layout_test"
>>>>>  f8 = menu_toggle_mode
>>>>>  f9 = halt
>>>>>  f10 = reboot
>>>>> }
>>>>
>>>> This should be merged with the mapkey into a single key mapping function.
>>>>
>>>
>>> Hi,
>>>
>>> The difference of mapkey and onkey is when they're executed. The order
>>> is as follows:
>>>
>>> mapkey
>>> onkey function of current widget
>>> key binding in onkey section
>>>
>>> For example in the edit widget, you use ctrl-x to finish current edit.
>>> But in EFI, you can't input ctrl-x. The way to solve this is to map
>>> another key as ctrl-x, which use mapkey function. Adding function in
>>> onkey doesn't help, as by the time it reaches there, the edit widget
>>> has finish handling.
>>>
>>> Also, if the key is used by widget, the binding in onkey doesn't help.
>>> This is actually a good thing, for example,  we can add hotkey c to
>>> open a terminal window. This has effect on main menu, but we certainly
>>> don't want it when inside term already. But if we do need to change a
>>> key used by widget, we can map it in mapkey section.
>>
>> Why do you need a separate mapping?
>>
>> The widget either handles the key or not, and it should pass it to its
>> parent if it does not handle it.
>>
>> The function in question is either a widget specific function or not
>> so you know where it should be processed.
>>
>> I am not sure what is the difference in mapkey and "onkey in current widget".
>>
>
> Hi,
>
> Here, function means C function. In config file, all configurable
> command is grub command, no command is specific to certain widget.
> Widget have a onkey callback function which gives it the chance to
> handle the current key press, if it doesn't handle it, it would be
> passed to system.

if it's handled by the widget it must be a function specific to a
widget, otherwise it would not be handled by a widget but do something
global, even in widget's onkey.

>
> So, you can use mapkey to map a key to the one interested by the
> widget. For example, edit control use ctrl-x key to indicate the
> finish of edit. If ctrl-x can't be input, you map F5 to it so that you
> can finish the edit.
>
> This is similar to the vim style of key handling, that's, each key
> defines a specific function. I guess it's possible to use emacs style,
> where each function is named with string. But I think that system is a
> little overkill, you need to bind every function to some key before
> you have a working system, while the current method works out of the
> box, you just change the mapping you need.

I think that naming the function is the first step to writing out the
mapping in a user readable form so that it can be automatically
included in help texts.

Having the functions named does not mean that grub cannot include a
default map. It just means that the functions mapped by default and
not yet mapped are equal, and they can be mapped and remapped in the
configuration the same way.

Binding functions to key names sucks. Not all keyboards have the same
labels and some people might want to use different input, etc.

>
>>>>>
>>>>> c open a terminal window, e open a edit box to edit the current
>>>>> command, use ctrl-x to save it. f7 runs the layout demo test, f8
>>>>> toggle between text and graphic mode, f9 shutdown, f10 reboot.
>>>>>
>>>>> Data binding for popup windows, for example, in the above example,
>>>>>
>>>>> menu_popup edit_window edit.text=command
>>>>>
>>>>> property text in the edit widget in the popup dialog binds to the
>>>>> command property of current node, this is used to implement the edit
>>>>> function.
>>>>>
>>>>> Add two property attach_hcenter and attach_vcenter for layout manager.
>>>>
>>>> What is the actual use case for windows which are not managed in the
>>>> layout and thus potentially overlap other windows in a system where
>>>> window overlapping is not handled?
>>>
>>> Popup window. For example, the e hotkey popup a edit box to edit
>>> current command. The top window of popup is placed in screen directly
>>> and not controlled by layout manger.
>>
>> In gfxterm the edit box is fullscreen and some lines still wrap for me
>> so I think it is the right way to handle these edits. They should get
>> as much space as possible, there can be (and typically is) quite a bit
>> of text.
>>
>> You can add the title of the edited item as a label at the top of the
>> edit screen perhaps.
>>
>
> I'm not sure showing a edit with only one or two lines full screen
> have the best look, especially when screen is very large. Although you
> can certainly config it that way. The choice is in the theme writer.

You can't know how much text the editor will have. However, there's no
reason to clutter the screen with other unusable elements. I would
rather include the list of keys that can be used in the editor if you
feel the edit screen is too empty.

Also I would like a way to easily scale the layout so that it is the
same size regardless of screen resolution. That is, if I have a
1600x1200 screen and a layout designed for 640x480 it might be useful
to just scale it to fit the on screen.

>
>>>
>>>>
>>>>> The top widget of popup window must use absolute position, as widget
>>>>> are already placed in screen and can't be moved without refresh. But
>>>>> it's not easy to put the widget in the middle of screen using
>>>>> attach_left/right/top/bottom, the new property attach_hcenter and
>>>>> attach_vcenter defines the offset from the center of screen.
>>>>
>>>> Can't you just make the popup fullscreen?
>>>>
>>>> IMHO it rids us of quite a few things  that allow people to shoot
>>>> themselves in the foot and require documentation and maintenance while
>>>> not removing anything particularly useful.
>>>
>>> You can configure the sub menu to pop up full screen. But I like it
>>> alongside the parent menu. IMO, this is the most common way to display
>>> a submenu.
>>
>> What's the advantage of having submenu alongside the parent menu?
>>
>> The disadvantage is complex, error-prone and inefficient layout
>> algorithm. How do you handle submenus that are larger than the screen
>> and would not fit in any case, for example. Or submenus that would
>> just fit if there wasn't any parent menu alongside the submenu. Or
>> submenus that are as wide/large as the screen but pop up from an item
>> in the middle of the screen.
>>
>> Another disadvantage is cluttered screen. Many distributions present
>> timezone and/or language selection as menus. These are large
>> multilevel selections because putting all the options into one list is
>> quite useless, you could navigate all day just to find your timezone
>> and language. Imagine drawing these with the alongside-menu.
>>
>> I see no advantage. For clarity you can put the name of the parent
>> item as a title of the menu screen so you know exactly where you are,
>> what are your choices, and the screen is not cluttered with other
>> inaccessible distracting rubbish.
>>
>> I know that submenus displayed at some random point near the menu item
>> from which they were activated are often used in GUI toolkits but this
>> does not make the practice good or desirable. There are many corner
>> cases which are likely experienced on small screens (and grub may
>> often use small resolution for compatibility) which are quite
>> confusing. When there are multiple levels of such menus it gets very
>> messy and it is getting hard to find a sensible placing for new
>> submenus. It does not add to readability or anything, you still have
>> to walk the submenus to see which options are available.
>>
>> An advantage of a simple menu it it can be also presented as a list of
>> choices on a dumb terminal (see Debian reportbug as a sample of such
>> interface or the difference between dpkg dialog and readline
>> frontends). No need to write a separate menu for that case, new
>> visualization should suffice.
>
> Actually the handling is very simple, by adding -r or --relative
> option to menu_popup, it moves the widget in relates to parent using
> attach_left/attach_right/attach_top/attach_bottom, instead of the
> default location of top left corner. The problem you describe, sub
> menu grows out of screen, this can happen even when full screen. It's
> the job of scroller, which would scroll the widget into view when
> selected. If you insist, I can just add a option to skip -r.

Yes, a menu can be larger than the screen even when it is displayed fullscreen.

The problem is that displaying a large menu that does not fit next to
its parent menu makes the scrolling confusing. Scrolling is typically
not present on these kinds of menus. The other problem is that the
place covered by the parent is what the menu would require to fit
fully on screen which is ineffective. You cannot use the parent menu
while in the sublemenu but it uses screen space.

Thanks

Michal

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Oct 22, 2009 at 3:41 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> Here, function means C function. In config file, all configurable
>> command is grub command, no command is specific to certain widget.
>> Widget have a onkey callback function which gives it the chance to
>> handle the current key press, if it doesn't handle it, it would be
>> passed to system.
>
> if it's handled by the widget it must be a function specific to a
> widget, otherwise it would not be handled by a widget but do something
> global, even in widget's onkey.
>

Hi,

Yep, this is how it's handled now, if the widget doesn't interested in
the key, it return a value of SKIP and the global key mapping is
checked.

>>
>> So, you can use mapkey to map a key to the one interested by the
>> widget. For example, edit control use ctrl-x key to indicate the
>> finish of edit. If ctrl-x can't be input, you map F5 to it so that you
>> can finish the edit.
>>
>> This is similar to the vim style of key handling, that's, each key
>> defines a specific function. I guess it's possible to use emacs style,
>> where each function is named with string. But I think that system is a
>> little overkill, you need to bind every function to some key before
>> you have a working system, while the current method works out of the
>> box, you just change the mapping you need.
>
> I think that naming the function is the first step to writing out the
> mapping in a user readable form so that it can be automatically
> included in help texts.
>
> Having the functions named does not mean that grub cannot include a
> default map. It just means that the functions mapped by default and
> not yet mapped are equal, and they can be mapped and remapped in the
> configuration the same way.
>
> Binding functions to key names sucks. Not all keyboards have the same
> labels and some people might want to use different input, etc.
>

I understand that named method is better than using keys directly. But
the current method works and it's simpler to implement. There are
other area that needs more attention at the moment, so it's not a
priority to change it now.

>>>>>> c open a terminal window, e open a edit box to edit the current
>>>>>> command, use ctrl-x to save it. f7 runs the layout demo test, f8
>>>>>> toggle between text and graphic mode, f9 shutdown, f10 reboot.
>>>>>>
>>>>>> Data binding for popup windows, for example, in the above example,
>>>>>>
>>>>>> menu_popup edit_window edit.text=command
>>>>>>
>>>>>> property text in the edit widget in the popup dialog binds to the
>>>>>> command property of current node, this is used to implement the edit
>>>>>> function.
>>>>>>
>>>>>> Add two property attach_hcenter and attach_vcenter for layout manager.
>>>>>
>>>>> What is the actual use case for windows which are not managed in the
>>>>> layout and thus potentially overlap other windows in a system where
>>>>> window overlapping is not handled?
>>>>
>>>> Popup window. For example, the e hotkey popup a edit box to edit
>>>> current command. The top window of popup is placed in screen directly
>>>> and not controlled by layout manger.
>>>
>>> In gfxterm the edit box is fullscreen and some lines still wrap for me
>>> so I think it is the right way to handle these edits. They should get
>>> as much space as possible, there can be (and typically is) quite a bit
>>> of text.
>>>
>>> You can add the title of the edited item as a label at the top of the
>>> edit screen perhaps.
>>>
>>
>> I'm not sure showing a edit with only one or two lines full screen
>> have the best look, especially when screen is very large. Although you
>> can certainly config it that way. The choice is in the theme writer.
>
> You can't know how much text the editor will have. However, there's no
> reason to clutter the screen with other unusable elements. I would
> rather include the list of keys that can be used in the editor if you
> feel the edit screen is too empty.
>
> Also I would like a way to easily scale the layout so that it is the
> same size regardless of screen resolution. That is, if I have a
> 1600x1200 screen and a layout designed for 640x480 it might be useful
> to just scale it to fit the on screen.
>

You can't scale fonts, for other element, you just use the percentage
notion and it will scale according to the screen size.

>
> Yes, a menu can be larger than the screen even when it is displayed fullscreen.
>
> The problem is that displaying a large menu that does not fit next to
> its parent menu makes the scrolling confusing. Scrolling is typically
> not present on these kinds of menus. The other problem is that the
> place covered by the parent is what the menu would require to fit
> fully on screen which is ineffective. You cannot use the parent menu
> while in the sublemenu but it uses screen space.

The point of displaying the parent menu is to provide navigation clues
to the current location. If the tree level is deep, users can get lost
pretty quickly if all menu looks the same. By displaying the parent
menus, users can go from A to B much easier. And whether to use full
screen or not is the choice of user, we shouldn't enforce one scheme
or another in code.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Peter Cros]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

I don't know what is the testing status for pc machines, but I have
grub-install problem for platform pc on Apple with the current menu source.

commit eb03e2575b2c0b1b4fd83f33a741f6fef3b93339
Author: Bean <bean123ch@gmail.com>
Date:   Wed Oct 21 01:11:27 2009 +0800

Compiling for grub-pc test of menu on Apple, --wth-platform=pc, I get this
stopper in grub-install (after successful make && make install). OS is
ubuntu904 on imac81.


pxw@im:~/src/grub/buildpc$ sudo ./grub-install --no-floppy --force /dev/sda
./grub-install: 312: realpath: not found


( I got the same back from start of the menu tests with git branch master,
the change to realpath problem, then I went to efi tests, no problems).

I had no problem --with-platform=pc from the new Bazaar mirror
bzr branch http://bzr.savannah.gnu.org/r/grub/
 which  compiles installs and boots grub-pc with no errors .

pxw@im:~/src/bzr/trunk$ bzr log -l 1
------------------------------------------------------------
revno: 1768
committer: fzielcke
timestamp: Wed 2009-10-21 12:22:05 +0000
message:
  2009-10-21  Felix Zielcke  <fzielcke@z-51.de>

-------------------


-- 
Cros (pxw)

[-- Attachment #2: Type: text/html, Size: 1413 bytes --]

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Fri, Oct 23, 2009 at 1:59 PM, Peter Cros <pxwpxw8@gmail.com> wrote:
> I don't know what is the testing status for pc machines, but I have
> grub-install problem for platform pc on Apple with the current menu source.
>
> commit eb03e2575b2c0b1b4fd83f33a741f6fef3b93339
> Author: Bean <bean123ch@gmail.com>
> Date:   Wed Oct 21 01:11:27 2009 +0800
>
> Compiling for grub-pc test of menu on Apple, --wth-platform=pc, I get this
> stopper in grub-install (after successful make && make install). OS is
> ubuntu904 on imac81.
>
>
> pxw@im:~/src/grub/buildpc$ sudo ./grub-install --no-floppy --force /dev/sda
> ./grub-install: 312: realpath: not found
>
>
> ( I got the same back from start of the menu tests with git branch master,
> the change to realpath problem, then I went to efi tests, no problems).
>
> I had no problem --with-platform=pc from the new Bazaar mirror
> bzr branch http://bzr.savannah.gnu.org/r/grub/
>  which  compiles installs and boots grub-pc with no errors .

Hi,

My menu patch haven't synced with latest svn yet, perhaps it's some
bug fixed after my last sync. Anyway, I always create iso image when
testing pc mode, so it's possible that there is issue in grub-install
and I don't even noticed.

-- 
Bean

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

Re: [GITGRUB] New menu interface (implementation)

[Peter Cros]

[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]

I can use grub-mkrescue to create an El Torito image and burn CD which boots
and can run menu. Is that what you mean, or is there a way to boot  direct
from iso?

Thanks

On Fri, Oct 23, 2009 at 6:31 PM, Bean <bean123ch@gmail.com> wrote:

> On Fri, Oct 23, 2009 at 1:59 PM, Peter Cros <pxwpxw8@gmail.com> wrote:
> > I don't know what is the testing status for pc machines, but I have
> > grub-install problem for platform pc on Apple with the current menu
> source.
> >
> > commit eb03e2575b2c0b1b4fd83f33a741f6fef3b93339
> > Author: Bean <bean123ch@gmail.com>
> > Date:   Wed Oct 21 01:11:27 2009 +0800
> >
> > Compiling for grub-pc test of menu on Apple, --wth-platform=pc, I get
> this
> > stopper in grub-install (after successful make && make install). OS is
> > ubuntu904 on imac81.
> >
> >
> > pxw@im:~/src/grub/buildpc$ sudo ./grub-install --no-floppy --force
> /dev/sda
> > ./grub-install: 312: realpath: not found
> >
> >
> > ( I got the same back from start of the menu tests with git branch
> master,
> > the change to realpath problem, then I went to efi tests, no problems).
> >
> > I had no problem --with-platform=pc from the new Bazaar mirror
> > bzr branch http://bzr.savannah.gnu.org/r/grub/
> >  which  compiles installs and boots grub-pc with no errors .
>
> Hi,
>
> My menu patch haven't synced with latest svn yet, perhaps it's some
> bug fixed after my last sync. Anyway, I always create iso image when
> testing pc mode, so it's possible that there is issue in grub-install
> and I don't even noticed.
>
> --
> Bean
>
> gitgrub home: http://github.com/grub/grub/
> my fork page: http://github.com/bean123/grub/
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Cros (pxw)

[-- Attachment #2: Type: text/html, Size: 2787 bytes --]

Re: [GITGRUB] New menu interface (implementation)

[Peter Cros]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

On Sat, Oct 24, 2009 at 7:04 PM, Peter Cros <pxwpxw8@gmail.com> wrote:

> I can use grub-mkrescue to create an El Torito image and burn CD which
> boots and can run menu. Is that what you mean, or is there a way to boot
> direct from iso?
>
> Thanks
>
> Nevermind, multiboot /grub.img works, with some bugs in gfx for bios boot
on apple. (font missing no text on gfx, textmode is ok).



-- 
Cros (pxw)

[-- Attachment #2: Type: text/html, Size: 730 bytes --]

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Support transparent icon.

Support command history for term widget, up/down move through history,
ctrl-p/ctrl-n move to previous output lines. you can use history
property to set the number of history lines:

term {
  history = 10
}

If history is not set, default value of 20 is used, history = 0 means
unlimited history.

Support two menu style, you can pop up sub menu alongside parent, or
display it in full screen. Menu style can't be changed dynamically,
but you can edit menu.cfg to select them:

This show sub menu alongside parent:
menu_create menu_template item_template

This shows sub menu full screen:
menu_create menu_template1 item_template

The templates are defined in menu.txt:

menu_template {
  panel {
    class = frame
  }
}

menu_template1 {
  panel {
    absolute = 1
    width = 100%
    height = 100%

    panel {
      id = __child__
      class = frame
      valign = center
      halign = center
      extend = 1
    }
  }
}

-- 
Bean

My repository: https://launchpad.net/burg

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Support password dialog.

In grub.cfg, config users, for example:

set superusers=admin
password admin admin
password user user

In this example, there are two uses admin and user, admin is a superuser.

To set authorized user for a boot item defined with menuentry statement:

menuentry "AA" --users user {
  boot
}

To set authorized user for a boot item defined with menu config:

menu {
  "AA" {
     users = user
     command = true
  }
}

You can also limit commands in onkey section to be run by super users
only, to do this, add * as the first character. For example:

onkey {
  e = "*menu_edit dialog_edit text=command"
  t = "if menu_edit dialog_edit text=title; then menu_refresh; fi"
  c = "*menu_popup term_window"
  f6 = menu_next_anchor
  f7 = "menu_popup layout_test"
  f8 = menu_toggle_mode
  f9 = halt
  f10 = reboot
}

e and c hotkey can only be used by super user.

-- 
Bean

My repository: https://launchpad.net/burg

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Add timeout, progressbar and savedefault.

savedefault:

Variable savedefault set the system default value. If savedefault=1,
save the current boot item.

You can also overwrite the default value for individual items, in
menuentry statement --save option always save this item, and --nosave
never save the item. If neither --save nor --nosave is specified, the
system default in savedefault variable is checked.

In the menu section, use property save=1 or save=0 to achieve the same
effect as --save and --nosave.

You also need to set the environment file, default value is
${prefix}/env, you can also use envfile variable to overwrite it.

timeout:

Use timeout variable to control auto boot. For example:

set timeout=5

it would boot the default item if no key is pressed in 5 seconds. If
timeout=0, boot the default item immediately, although you can press a
key at startup to halt the auto boot. If timeout is not set, auto boot
is disabled.

progressbar:

This works in conjunction with timeout. When a timeout value is set,
you can see the process bar at bottom of screen.

As with this version, all feature from grub legacy has been
implemented. There is a grub.cfg inside the menu directory that shows
some usage:

set superusers=admin
password admin admin
password user user

set timeout=5

set envfile=/menu/env
set savedefault=1
load_env

menuentry Item1 --users user --nosave --class image_tools {
  true
}

menuentry Item2 --save --class image_about {
  true
}

. /menu/menu_efi.cfg


-- 
Bean

My repository: https://launchpad.net/burg

Re: [GITGRUB] New menu interface (implementation)

[Vladimir 'phcoder' Serbinenko]

Bean wrote:
> Hi,
>
> Update:
>
> Add timeout, progressbar and savedefault.
>
> savedefault:
>
> Variable savedefault set the system default value. If savedefault=1,
> save the current boot item.
>
> You can also overwrite the default value for individual items, in
> menuentry statement --save option always save this item, and --nosave
> never save the item. If neither --save nor --nosave is specified, the
> system default in savedefault variable is checked.
>
>   
Why do you need this over having a normal save_env? I don't see any
reason to prefer an ad-hoc here over general solution
> In the menu section, use property save=1 or save=0 to achieve the same
> effect as --save and --nosave.
>
> You also need to set the environment file, default value is
> ${prefix}/env, you can also use envfile variable to overwrite it.
>
> timeout:
>
> Use timeout variable to control auto boot. For example:
>
> set timeout=5
>
> it would boot the default item if no key is pressed in 5 seconds. If
> timeout=0, boot the default item immediately, although you can press a
> key at startup to halt the auto boot. If timeout is not set, auto boot
> is disabled.
>
> progressbar:
>
> This works in conjunction with timeout. When a timeout value is set,
> you can see the process bar at bottom of screen.
>
> As with this version, all feature from grub legacy has been
> implemented. There is a grub.cfg inside the menu directory that shows
> some usage:
>
> set superusers=admin
> password admin admin
> password user user
>
> set timeout=5
>
> set envfile=/menu/env
> set savedefault=1
> load_env
>
> menuentry Item1 --users user --nosave --class image_tools {
>   true
> }
>
> menuentry Item2 --save --class image_about {
>   true
> }
>
> . /menu/menu_efi.cfg
>
>
>   


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Oct 29, 2009 at 5:12 AM, Vladimir 'phcoder' Serbinenko
<phcoder@gmail.com> wrote:
> Bean wrote:
>> Hi,
>>
>> Update:
>>
>> Add timeout, progressbar and savedefault.
>>
>> savedefault:
>>
>> Variable savedefault set the system default value. If savedefault=1,
>> save the current boot item.
>>
>> You can also overwrite the default value for individual items, in
>> menuentry statement --save option always save this item, and --nosave
>> never save the item. If neither --save nor --nosave is specified, the
>> system default in savedefault variable is checked.
>>
>>
> Why do you need this over having a normal save_env? I don't see any
> reason to prefer an ad-hoc here over general solution

Hi,

This is more convenient than adding a save_env command to every entry.
Users can just set savedefault=1 and all items are saved by default,
remove it and it's not saved anymore. They can also config each item
individually with --save and --nosave option, which is similar to
adding a save_env command at the beginning, but easier to edit.

-- 
Bean

My repository: https://launchpad.net/burg

Re: [GITGRUB] New menu interface (implementation)

[Vladimir 'phcoder' Serbinenko]

Bean wrote:
> On Thu, Oct 29, 2009 at 5:12 AM, Vladimir 'phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
>   
>> Bean wrote:
>>     
>>> Hi,
>>>
>>> Update:
>>>
>>> Add timeout, progressbar and savedefault.
>>>
>>> savedefault:
>>>
>>> Variable savedefault set the system default value. If savedefault=1,
>>> save the current boot item.
>>>
>>> You can also overwrite the default value for individual items, in
>>> menuentry statement --save option always save this item, and --nosave
>>> never save the item. If neither --save nor --nosave is specified, the
>>> system default in savedefault variable is checked.
>>>
>>>
>>>       
>> Why do you need this over having a normal save_env? I don't see any
>> reason to prefer an ad-hoc here over general solution
>>     
>
> Hi,
>
> This is more convenient than adding a save_env command to every entry.
> Users can just set savedefault=1 and all items are saved by default,
> remove it and it's not saved anymore. They can also config each item
> individually with --save and --nosave option, which is similar to
> adding a save_env command at the beginning, but easier to edit.
>
>   
It may be more convinient in this case but when you start adding ad-hoc
structures to any programming languages you end up only clobbering it.
This is why a simple language C became more widespread than clobbered
Ada. If you want to execute code on running entries you will need signals


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Oct 29, 2009 at 5:10 PM, Vladimir 'phcoder' Serbinenko
<phcoder@gmail.com> wrote:
> Bean wrote:
>> On Thu, Oct 29, 2009 at 5:12 AM, Vladimir 'phcoder' Serbinenko
>> <phcoder@gmail.com> wrote:
>>
>>> Bean wrote:
>>>
>>>> Hi,
>>>>
>>>> Update:
>>>>
>>>> Add timeout, progressbar and savedefault.
>>>>
>>>> savedefault:
>>>>
>>>> Variable savedefault set the system default value. If savedefault=1,
>>>> save the current boot item.
>>>>
>>>> You can also overwrite the default value for individual items, in
>>>> menuentry statement --save option always save this item, and --nosave
>>>> never save the item. If neither --save nor --nosave is specified, the
>>>> system default in savedefault variable is checked.
>>>>
>>>>
>>>>
>>> Why do you need this over having a normal save_env? I don't see any
>>> reason to prefer an ad-hoc here over general solution
>>>
>>
>> Hi,
>>
>> This is more convenient than adding a save_env command to every entry.
>> Users can just set savedefault=1 and all items are saved by default,
>> remove it and it's not saved anymore. They can also config each item
>> individually with --save and --nosave option, which is similar to
>> adding a save_env command at the beginning, but easier to edit.
>>
>>
> It may be more convinient in this case but when you start adding ad-hoc
> structures to any programming languages you end up only clobbering it.
> This is why a simple language C became more widespread than clobbered
> Ada. If you want to execute code on running entries you will need signals

Hi,

But menuentry statement is already changed for similar reason. Colin
adds --class option, you add --users option, why would add another
option --save and --nosave be any difference ?

BTW, the save_env method doesn't works menu items generated
dynamically. For example, the menu items added by osdetect.lua or sub
menu items by menu_create.

-- 
Bean

My repository: https://launchpad.net/burg

Re: [GITGRUB] New menu interface (implementation)

[Vladimir 'phcoder' Serbinenko]

Bean wrote:
> On Thu, Oct 29, 2009 at 5:10 PM, Vladimir 'phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
>   
>> Bean wrote:
>>     
>>> On Thu, Oct 29, 2009 at 5:12 AM, Vladimir 'phcoder' Serbinenko
>>> <phcoder@gmail.com> wrote:
>>>
>>>       
>>>> Bean wrote:
>>>>
>>>>         
>>>>> Hi,
>>>>>
>>>>> Update:
>>>>>
>>>>> Add timeout, progressbar and savedefault.
>>>>>
>>>>> savedefault:
>>>>>
>>>>> Variable savedefault set the system default value. If savedefault=1,
>>>>> save the current boot item.
>>>>>
>>>>> You can also overwrite the default value for individual items, in
>>>>> menuentry statement --save option always save this item, and --nosave
>>>>> never save the item. If neither --save nor --nosave is specified, the
>>>>> system default in savedefault variable is checked.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> Why do you need this over having a normal save_env? I don't see any
>>>> reason to prefer an ad-hoc here over general solution
>>>>
>>>>         
>>> Hi,
>>>
>>> This is more convenient than adding a save_env command to every entry.
>>> Users can just set savedefault=1 and all items are saved by default,
>>> remove it and it's not saved anymore. They can also config each item
>>> individually with --save and --nosave option, which is similar to
>>> adding a save_env command at the beginning, but easier to edit.
>>>
>>>
>>>       
>> It may be more convinient in this case but when you start adding ad-hoc
>> structures to any programming languages you end up only clobbering it.
>> This is why a simple language C became more widespread than clobbered
>> Ada. If you want to execute code on running entries you will need signals
>>     
>
> Hi,
>
> But menuentry statement is already changed for similar reason. Colin
> adds --class option, you add --users option, why would add another
> option --save and --nosave be any difference ?
>
>   
--class is an attribute to control the appearence and --users are to
make sure that no part of secured entry is executed
> BTW, the save_env method doesn't works menu items generated
> dynamically. For example, the menu items added by osdetect.lua or sub
> menu items by menu_create.
>
>   
Then it's a bug that should be fixed and not swept under the carpet


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Oct 29, 2009 at 5:33 PM, Vladimir 'phcoder' Serbinenko
<phcoder@gmail.com> wrote:
>> BTW, the save_env method doesn't works menu items generated
>> dynamically. For example, the menu items added by osdetect.lua or sub
>> menu items by menu_create.
>>
>>
> Then it's a bug that should be fixed and not swept under the carpet

Hi,

It's not a bug, we can't just add save_env default in every auto
generated item, what if users don't want to auto save ? At best, we
need to add a variable to control its behavior, for example
savedefault=1. But then, we can just check the savedefault variable to
decide whether to save or not, no need to use save_env at all.

Also, with save_env, the command needs to be inserted by
grub-mkconfig, it's not easy to edit the menu file by hand because you
need to insert it in every item. Also, for grub-mkconfig generated
item, it's either all on or all off, you can't save some of the items.

BTW, this actually quite similar to --users. To authorized a user, you
don't need a option, for example, you can add this to every entry that
needs authorization:

if password_check user1,user2; then
 command
fi

---
Bean

My repository: https://launchpad.net/burg

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Support enter key in edit. You can use enter key to break a line into
two. Use backspace at the beginning of a line to join two lines into
one.

Support md5 password. Use utility grub-mkpasswd to generate md5
password, for example:

grub-mkpasswd 123456

Output:
$1$qn6KtRs$nO9.aB.p85BBI2w.KYko6.

The use this in grub.cfg:

password --md5 admin '$1$qn6KtRs$nO9.aB.p85BBI2w.KYko6.'

Don't forget the '' otherwise $ would be used to expand variable.

-- 
Bean

My repository: https://launchpad.net/burg

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

New handler class menu_viewer, new menu system is now a menu viewer
handler. (emenu.mod)
Remove reader handler class.
New module lib.mod containing helper functions. Move common function
for normal.mod to lib.mod.
Move the menu out of normal.mod as standalone menu viewer. (nmenu.mod)
Use common history function to handle command history in new menu system.
Rename textmenu module as txtrgn, gfxmenu module as gfxrgn.
configfile can be used to open sub menu in both new and old menu viewer.

To start the new menu system, add these lines at the end of grub.cfg (pc mode):

set gfxmode="640x480"
set gfxfont="Unifont Regular 16"
loadfont /menu/unifont.pf2
insmod vbe
insmod png
insmod coreui
load_config /menu/default.txt

default.txt is the theme file for new menu. Without the load_config
command, it starts the old menu viewer. When new menu is started, it
checks gfxmode variable, if it's set, it attempts to start graphic
mode, otherwise it uses text mode.

-- 
Bean

My repository: https://launchpad.net/burg

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Sync with upstream r1810, also fix a few compile error of grub-mkisofs
in mingw and ubuntu karmic.

-- 
Bean

My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg

mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))

[Robert Millan]

On Mon, Nov 09, 2009 at 11:55:11PM +0800, Bean wrote:
> Sync with upstream r1810,

Nice.

> also fix a few compile error of grub-mkisofs
> in mingw and ubuntu karmic.

Could you perhaps send a patch for those compile fixes?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))

[Bean]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

On Tue, Nov 10, 2009 at 12:16 AM, Robert Millan <rmh@aybabtu.com> wrote:
> On Mon, Nov 09, 2009 at 11:55:11PM +0800, Bean wrote:
>> Sync with upstream r1810,
>
> Nice.
>
>> also fix a few compile error of grub-mkisofs
>> in mingw and ubuntu karmic.
>
> Could you perhaps send a patch for those compile fixes?

Hi,

Here is it, the compile error:

MINGW don't have fnmatch.h, add fnmatch.h to include
MINGW don't define S_IROTH, S_IRGRP and u_char
MINGW don't have lstat, getuid and getgid.
Some system such as ubuntu karmic define write using
warn_unused_result attribute, which cause a warning when return value
of write is not used. As grub compile with -Werror, this turn into
error, to work around it, use something like this:

 ssize_t tmp = write(bcat, buf, 2048);
 (void) tmp;

My branch also remove trailing blanks, but i use -w option to skip
those in the diff file.

BTW, my mingw version is 3.4.5 from windows host, it'd be nice if
someone can verify the result with newer version.

-- 
Bean

My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg

[-- Attachment #2: mkisofs.diff --]
[-- Type: application/octet-stream, Size: 5990 bytes --]

=== modified file 'util/mkisofs/eltorito.c'
--- util/mkisofs/eltorito.c	2009-11-08 22:54:27 +0000
+++ util/mkisofs/eltorito.c	2009-11-09 15:39:57 +0000
@@ -111,7 +111,8 @@
     }
     
     buf = (char *) e_malloc( 2048 );
-    write(bcat, buf, 2048);
+    ssize_t tmp = write(bcat, buf, 2048);
+    (void) tmp;
     close(bcat);
     free(bootpath);
 } /* init_boot_catalog(... */
@@ -268,8 +269,9 @@
     /* 
      * write out 
      */
-    write(bootcat, &valid_desc, 32);
-    write(bootcat, &default_desc, 32);
+    ssize_t tmp = write(bootcat, &valid_desc, 32);
+    tmp = write(bootcat, &default_desc, 32);
+    (void) tmp;
     close(bootcat);
 } /* get_torito_desc(... */
 

=== modified file 'util/mkisofs/exclude.h'

=== modified file 'util/mkisofs/fnmatch.c'
--- util/mkisofs/fnmatch.c	2009-11-08 22:52:08 +0000
+++ util/mkisofs/fnmatch.c	2009-11-09 14:48:38 +0000
@@ -24,7 +24,7 @@
 #endif
 
 #include <errno.h>
-#include <fnmatch.h>
+#include "fnmatch.h"
 
 #ifndef	__STDC__
 #define	const

=== modified file 'util/mkisofs/hash.c'

=== added file 'util/mkisofs/include/fnmatch.h'
--- util/mkisofs/include/fnmatch.h	1970-01-01 00:00:00 +0000
+++ util/mkisofs/include/fnmatch.h	2009-11-09 14:53:34 +0000
@@ -0,0 +1,72 @@
+/* Copyright (C) 1991-93,96,97,98,99,2001,2004 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, write to the Free
+   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+   02111-1307 USA.  */
+
+#ifndef	_FNMATCH_H
+#define	_FNMATCH_H	1
+
+#ifdef	__cplusplus
+extern "C" {
+#endif
+
+#ifndef const
+# if (defined __STDC__ && __STDC__) || defined __cplusplus
+#  define __const	const
+# else
+#  define __const
+# endif
+#endif
+
+/* We #undef these before defining them because some losing systems
+   (HP-UX A.08.07 for example) define these in <unistd.h>.  */
+#undef	FNM_PATHNAME
+#undef	FNM_NOESCAPE
+#undef	FNM_PERIOD
+
+/* Bits set in the FLAGS argument to `fnmatch'.  */
+#define	FNM_PATHNAME	(1 << 0) /* No wildcard can ever match `/'.  */
+#define	FNM_NOESCAPE	(1 << 1) /* Backslashes don't quote special chars.  */
+#define	FNM_PERIOD	(1 << 2) /* Leading `.' is matched only explicitly.  */
+
+#if !defined _POSIX_C_SOURCE || _POSIX_C_SOURCE < 2 || defined _GNU_SOURCE
+# define FNM_FILE_NAME	 FNM_PATHNAME	/* Preferred GNU name.  */
+# define FNM_LEADING_DIR (1 << 3)	/* Ignore `/...' after a match.  */
+# define FNM_CASEFOLD	 (1 << 4)	/* Compare without regard to case.  */
+# define FNM_EXTMATCH	 (1 << 5)	/* Use ksh-like extended matching. */
+#endif
+
+/* Value returned by `fnmatch' if STRING does not match PATTERN.  */
+#define	FNM_NOMATCH	1
+
+/* This value is returned if the implementation does not support
+   `fnmatch'.  Since this is not the case here it will never be
+   returned but the conformance test suites still require the symbol
+   to be defined.  */
+#ifdef _XOPEN_SOURCE
+# define FNM_NOSYS	(-1)
+#endif
+
+/* Match NAME against the filename pattern PATTERN,
+   returning zero if it matches, FNM_NOMATCH if not.  */
+extern int fnmatch (__const char *__pattern, __const char *__name,
+		    int __flags);
+
+#ifdef	__cplusplus
+}
+#endif
+
+#endif /* fnmatch.h */

=== modified file 'util/mkisofs/joliet.c'

=== modified file 'util/mkisofs/match.c'
--- util/mkisofs/match.c	2009-11-08 22:54:27 +0000
+++ util/mkisofs/match.c	2009-11-09 15:46:04 +0000
@@ -144,4 +144,3 @@
 {
   return (j_mat[0] != NULL);
 }
-

=== modified file 'util/mkisofs/match.h'

=== modified file 'util/mkisofs/mkisofs.c'

=== modified file 'util/mkisofs/mkisofs.h'
--- util/mkisofs/mkisofs.h	2009-11-08 22:54:27 +0000
+++ util/mkisofs/mkisofs.h	2009-11-09 15:29:59 +0000
@@ -48,6 +48,13 @@
 #define NON_UNIXFS
 #endif /* _WIN32 */
 
+#ifdef __MINGW32__
+#define S_IROTH		004
+#define S_IRGRP		040
+#undef u_char
+#define u_char		unsigned char
+#endif
+
 #include <string.h>
 #include <sys/types.h>
 #include <sys/stat.h>

=== modified file 'util/mkisofs/multi.c'
--- util/mkisofs/multi.c	2009-11-08 22:52:08 +0000
+++ util/mkisofs/multi.c	2009-11-09 15:29:47 +0000
@@ -1210,4 +1210,3 @@
   
   return 1;
 }
-

=== modified file 'util/mkisofs/name.c'

=== modified file 'util/mkisofs/rock.c'
--- util/mkisofs/rock.c	2009-11-08 22:54:27 +0000
+++ util/mkisofs/rock.c	2009-11-09 15:40:31 +0000
@@ -480,7 +480,8 @@
     OK_flag = 1;
 
     zipfile = fopen(whole_name, "rb");
-    fread(header, 1, sizeof(header), zipfile);
+    ssize_t tmp = fread(header, 1, sizeof(header), zipfile);
+    (void) tmp;
 
     /* Check some magic numbers from gzip. */
     if(header[0] != 0x1f || header[1] != 0x8b || header[2] != 8) OK_flag = 0;

=== modified file 'util/mkisofs/tree.c'
--- util/mkisofs/tree.c	2009-11-08 22:54:27 +0000
+++ util/mkisofs/tree.c	2009-11-09 15:29:16 +0000
@@ -147,7 +147,11 @@
 int
 FDECL2(lstat_filter, char *, path, struct stat *, st)
 {
+#ifdef __MINGW32__
+  int result = stat(path, st);
+#else
   int result = lstat(path, st);
+#endif
   if (result >= 0 && rationalize)
     stat_fix(st);
   return result;
@@ -1880,8 +1884,13 @@
 	}
       else
 	{
+#ifdef __MINGW32__
+	  fstatbuf.st_uid = 0;
+	  fstatbuf.st_gid = 0;
+#else
 	  fstatbuf.st_uid = getuid();
 	  fstatbuf.st_gid = getgid();
+#endif
 	}
       fstatbuf.st_ctime = current_time;
       fstatbuf.st_mtime = current_time;

=== modified file 'util/mkisofs/write.c'

Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))

[Robert Millan]

On Tue, Nov 10, 2009 at 12:46:06AM +0800, Bean wrote:
> 
> MINGW don't have fnmatch.h, add fnmatch.h to include
> MINGW don't define S_IROTH, S_IRGRP and u_char
> MINGW don't have lstat, getuid and getgid.

I started making some adjustments to these, and it was basically rewritten.  I
verified current trunk cross-compiles for mingw32.  The only caveat is I had to
use --disable-grub-mkfont.  Please try it out.

> BTW, my mingw version is 3.4.5 from windows host, it'd be nice if
> someone can verify the result with newer version.

I assume you mean your GCC version (mingw32 is still at 3.13).  Note that
we don't support building GRUB with GCC < 4.1.3 anymore.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)))

[Robert Millan]

On Tue, Nov 10, 2009 at 12:46:06AM +0800, Bean wrote:
> Some system such as ubuntu karmic define write using
> warn_unused_result attribute, which cause a warning when return value
> of write is not used. As grub compile with -Werror, this turn into
> error, to work around it, use something like this:
> 
>  ssize_t tmp = write(bcat, buf, 2048);
>  (void) tmp;

Isn't "(void) write (bcat, buf, 2048)" enough?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)))

[Felix Zielcke]

Am Montag, den 09.11.2009, 21:04 +0100 schrieb Robert Millan:
> On Tue, Nov 10, 2009 at 12:46:06AM +0800, Bean wrote:
> > Some system such as ubuntu karmic define write using
> > warn_unused_result attribute, which cause a warning when return
> value
> > of write is not used. As grub compile with -Werror, this turn into
> > error, to work around it, use something like this:
> > 
> >  ssize_t tmp = write(bcat, buf, 2048);
> >  (void) tmp;
> 
> Isn't "(void) write (bcat, buf, 2048)" enough? 

Why not just check the return code and print a warning (or maybe even
error) for tmp != 2048?

-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)))

[Colin Watson]

On Mon, Nov 09, 2009 at 09:04:50PM +0100, Robert Millan wrote:
> On Tue, Nov 10, 2009 at 12:46:06AM +0800, Bean wrote:
> > Some system such as ubuntu karmic define write using
> > warn_unused_result attribute, which cause a warning when return value
> > of write is not used. As grub compile with -Werror, this turn into
> > error, to work around it, use something like this:
> > 
> >  ssize_t tmp = write(bcat, buf, 2048);
> >  (void) tmp;
> 
> Isn't "(void) write (bcat, buf, 2048)" enough?

You'd think so, but sadly that doesn't affect gcc warn_unused_result.
Usually I do something like 'if (write (...) < 0) /* ignore error */;'.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)))

[Robert Millan]

On Mon, Nov 09, 2009 at 09:10:33PM +0100, Felix Zielcke wrote:
> Am Montag, den 09.11.2009, 21:04 +0100 schrieb Robert Millan:
> > On Tue, Nov 10, 2009 at 12:46:06AM +0800, Bean wrote:
> > > Some system such as ubuntu karmic define write using
> > > warn_unused_result attribute, which cause a warning when return
> > value
> > > of write is not used. As grub compile with -Werror, this turn into
> > > error, to work around it, use something like this:
> > > 
> > >  ssize_t tmp = write(bcat, buf, 2048);
> > >  (void) tmp;
> > 
> > Isn't "(void) write (bcat, buf, 2048)" enough? 
> 
> Why not just check the return code and print a warning (or maybe even
> error) for tmp != 2048?

Of course... shame on us.  A proper fix was so easy and we were still
looking for the workaround :-)  Thanks Felix.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))

[Bean]

On Tue, Nov 10, 2009 at 4:03 AM, Robert Millan <rmh@aybabtu.com> wrote:
> On Tue, Nov 10, 2009 at 12:46:06AM +0800, Bean wrote:
>>
>> MINGW don't have fnmatch.h, add fnmatch.h to include
>> MINGW don't define S_IROTH, S_IRGRP and u_char
>> MINGW don't have lstat, getuid and getgid.
>
> I started making some adjustments to these, and it was basically rewritten.  I
> verified current trunk cross-compiles for mingw32.  The only caveat is I had to
> use --disable-grub-mkfont.  Please try it out.
>
>> BTW, my mingw version is 3.4.5 from windows host, it'd be nice if
>> someone can verify the result with newer version.
>
> I assume you mean your GCC version (mingw32 is still at 3.13).  Note that
> we don't support building GRUB with GCC < 4.1.3 anymore.

Hi,

I merge with r1818 and it can compile without error now.

-- 
Bean

My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg