* Re: [GITGRUB] New menu interface (implementation)
2009-10-06 16:35 ` Bean
@ 2009-10-06 18:41 ` Michal Suchanek
2009-10-06 22:16 ` Michal Suchanek
2009-10-06 22:59 ` Michal Suchanek
2 siblings, 0 replies; 175+ messages in thread
From: Michal Suchanek @ 2009-10-06 18:41 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-06 16:35 ` Bean
2009-10-06 18:41 ` Michal Suchanek
@ 2009-10-06 22:16 ` Michal Suchanek
2009-10-07 6:05 ` Bean
2009-10-06 22:59 ` Michal Suchanek
2 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-06 22:16 UTC (permalink / raw)
To: The development of GRUB 2
[-- 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"
}
}
}
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-06 22:16 ` Michal Suchanek
@ 2009-10-07 6:05 ` Bean
2009-10-07 8:54 ` Michal Suchanek
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-07 6:05 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-07 6:05 ` Bean
@ 2009-10-07 8:54 ` Michal Suchanek
2009-10-07 10:54 ` Bean
2009-10-07 10:57 ` Bean
0 siblings, 2 replies; 175+ messages in thread
From: Michal Suchanek @ 2009-10-07 8:54 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-07 8:54 ` Michal Suchanek
@ 2009-10-07 10:54 ` Bean
2009-10-07 10:57 ` Bean
1 sibling, 0 replies; 175+ messages in thread
From: Bean @ 2009-10-07 10:54 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-07 8:54 ` Michal Suchanek
2009-10-07 10:54 ` Bean
@ 2009-10-07 10:57 ` Bean
2009-10-07 13:05 ` Michal Suchanek
1 sibling, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-07 10:57 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-07 10:57 ` Bean
@ 2009-10-07 13:05 ` Michal Suchanek
2009-10-07 21:13 ` Michal Suchanek
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-07 13:05 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-07 13:05 ` Michal Suchanek
@ 2009-10-07 21:13 ` Michal Suchanek
2009-10-08 4:20 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-07 21:13 UTC (permalink / raw)
To: The development of GRUB 2
[-- 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"
}
}
}
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-07 21:13 ` Michal Suchanek
@ 2009-10-08 4:20 ` Bean
2009-10-08 5:21 ` Bean
2009-10-08 11:18 ` Michal Suchanek
0 siblings, 2 replies; 175+ messages in thread
From: Bean @ 2009-10-08 4:20 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-08 4:20 ` Bean
@ 2009-10-08 5:21 ` Bean
2009-10-08 11:26 ` Michal Suchanek
2009-10-08 11:18 ` Michal Suchanek
1 sibling, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-08 5:21 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-08 5:21 ` Bean
@ 2009-10-08 11:26 ` Michal Suchanek
2009-10-08 13:26 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-08 11:26 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-08 11:26 ` Michal Suchanek
@ 2009-10-08 13:26 ` Bean
2009-10-08 21:34 ` Michal Suchanek
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-08 13:26 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-08 13:26 ` Bean
@ 2009-10-08 21:34 ` Michal Suchanek
2009-10-09 3:45 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-08 21:34 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-08 21:34 ` Michal Suchanek
@ 2009-10-09 3:45 ` Bean
2009-10-09 11:52 ` Michal Suchanek
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-09 3:45 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 3:45 ` Bean
@ 2009-10-09 11:52 ` Michal Suchanek
2009-10-09 12:48 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-09 11:52 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 11:52 ` Michal Suchanek
@ 2009-10-09 12:48 ` Bean
2009-10-09 14:20 ` Michal Suchanek
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-09 12:48 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 12:48 ` Bean
@ 2009-10-09 14:20 ` Michal Suchanek
2009-10-09 14:54 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-09 14:20 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 14:20 ` Michal Suchanek
@ 2009-10-09 14:54 ` Bean
2009-10-09 15:57 ` Michal Suchanek
2009-10-09 15:58 ` Bean
0 siblings, 2 replies; 175+ messages in thread
From: Bean @ 2009-10-09 14:54 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 14:54 ` Bean
@ 2009-10-09 15:57 ` Michal Suchanek
2009-10-09 16:17 ` Bean
2009-10-09 16:56 ` richardvoigt
2009-10-09 15:58 ` Bean
1 sibling, 2 replies; 175+ messages in thread
From: Michal Suchanek @ 2009-10-09 15:57 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 15:57 ` Michal Suchanek
@ 2009-10-09 16:17 ` Bean
2009-10-09 16:29 ` Michal Suchanek
2009-10-09 16:56 ` richardvoigt
1 sibling, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-09 16:17 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 16:17 ` Bean
@ 2009-10-09 16:29 ` Michal Suchanek
2009-10-09 16:48 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-09 16:29 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 16:29 ` Michal Suchanek
@ 2009-10-09 16:48 ` Bean
2009-10-09 17:27 ` Michal Suchanek
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-09 16:48 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 16:48 ` Bean
@ 2009-10-09 17:27 ` Michal Suchanek
2009-10-09 18:32 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-09 17:27 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 17:27 ` Michal Suchanek
@ 2009-10-09 18:32 ` Bean
2009-10-09 20:41 ` Michal Suchanek
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-09 18:32 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 18:32 ` Bean
@ 2009-10-09 20:41 ` Michal Suchanek
2009-10-10 3:43 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-09 20:41 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 20:41 ` Michal Suchanek
@ 2009-10-10 3:43 ` Bean
2009-10-10 11:22 ` Michal Suchanek
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-10 3:43 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-10 3:43 ` Bean
@ 2009-10-10 11:22 ` Michal Suchanek
2009-10-10 19:21 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-10 11:22 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-10 11:22 ` Michal Suchanek
@ 2009-10-10 19:21 ` Bean
2009-10-10 22:54 ` Michal Suchanek
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-10 19:21 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-10 19:21 ` Bean
@ 2009-10-10 22:54 ` Michal Suchanek
2009-10-11 3:58 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-10 22:54 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-10 22:54 ` Michal Suchanek
@ 2009-10-11 3:58 ` Bean
2009-10-11 10:03 ` Michal Suchanek
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-11 3:58 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-11 3:58 ` Bean
@ 2009-10-11 10:03 ` Michal Suchanek
2009-10-16 20:47 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-11 10:03 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-11 10:03 ` Michal Suchanek
@ 2009-10-16 20:47 ` Bean
2009-10-17 20:01 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-16 20:47 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-16 20:47 ` Bean
@ 2009-10-17 20:01 ` Bean
2009-10-18 17:01 ` Bean
2009-10-20 19:06 ` [GITGRUB] New menu interface (implementation) Michal Suchanek
0 siblings, 2 replies; 175+ messages in thread
From: Bean @ 2009-10-17 20:01 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-17 20:01 ` Bean
@ 2009-10-18 17:01 ` Bean
2009-10-20 14:52 ` Bean
2009-10-20 19:20 ` Michal Suchanek
2009-10-20 19:06 ` [GITGRUB] New menu interface (implementation) Michal Suchanek
1 sibling, 2 replies; 175+ messages in thread
From: Bean @ 2009-10-18 17:01 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-18 17:01 ` Bean
@ 2009-10-20 14:52 ` Bean
2009-10-20 19:31 ` Michal Suchanek
2009-10-20 19:20 ` Michal Suchanek
1 sibling, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-20 14:52 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-20 14:52 ` Bean
@ 2009-10-20 19:31 ` Michal Suchanek
2009-10-21 1:01 ` Peter Cros
2009-10-21 4:07 ` Bean
0 siblings, 2 replies; 175+ messages in thread
From: Michal Suchanek @ 2009-10-20 19:31 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-20 19:31 ` Michal Suchanek
@ 2009-10-21 1:01 ` Peter Cros
2009-10-21 4:07 ` Bean
1 sibling, 0 replies; 175+ messages in thread
From: Peter Cros @ 2009-10-21 1:01 UTC (permalink / raw)
To: The development of GRUB 2
[-- 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 --]
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-20 19:31 ` Michal Suchanek
2009-10-21 1:01 ` Peter Cros
@ 2009-10-21 4:07 ` Bean
2009-10-21 20:55 ` Michal Suchanek
1 sibling, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-21 4:07 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-21 4:07 ` Bean
@ 2009-10-21 20:55 ` Michal Suchanek
2009-10-22 3:47 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-21 20:55 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-21 20:55 ` Michal Suchanek
@ 2009-10-22 3:47 ` Bean
0 siblings, 0 replies; 175+ messages in thread
From: Bean @ 2009-10-22 3:47 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-18 17:01 ` Bean
2009-10-20 14:52 ` Bean
@ 2009-10-20 19:20 ` Michal Suchanek
2009-10-21 3:45 ` Bean
1 sibling, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-20 19:20 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-20 19:20 ` Michal Suchanek
@ 2009-10-21 3:45 ` Bean
2009-10-21 20:47 ` Michal Suchanek
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-21 3:45 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-21 3:45 ` Bean
@ 2009-10-21 20:47 ` Michal Suchanek
2009-10-22 4:34 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-21 20:47 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-21 20:47 ` Michal Suchanek
@ 2009-10-22 4:34 ` Bean
2009-10-22 7:41 ` Michal Suchanek
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-22 4:34 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-22 4:34 ` Bean
@ 2009-10-22 7:41 ` Michal Suchanek
2009-10-22 8:15 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-22 7:41 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-22 7:41 ` Michal Suchanek
@ 2009-10-22 8:15 ` Bean
2009-10-23 5:59 ` Peter Cros
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-22 8:15 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-22 8:15 ` Bean
@ 2009-10-23 5:59 ` Peter Cros
2009-10-23 7:31 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Peter Cros @ 2009-10-23 5:59 UTC (permalink / raw)
To: The development of GRUB 2
[-- 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 --]
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-23 5:59 ` Peter Cros
@ 2009-10-23 7:31 ` Bean
2009-10-24 8:04 ` Peter Cros
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-23 7:31 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-23 7:31 ` Bean
@ 2009-10-24 8:04 ` Peter Cros
2009-10-25 14:27 ` Peter Cros
0 siblings, 1 reply; 175+ messages in thread
From: Peter Cros @ 2009-10-24 8:04 UTC (permalink / raw)
To: The development of GRUB 2
[-- 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 --]
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-24 8:04 ` Peter Cros
@ 2009-10-25 14:27 ` Peter Cros
2009-10-26 18:24 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Peter Cros @ 2009-10-25 14:27 UTC (permalink / raw)
To: The development of GRUB 2
[-- 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 --]
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-25 14:27 ` Peter Cros
@ 2009-10-26 18:24 ` Bean
2009-10-27 17:34 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-26 18:24 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-26 18:24 ` Bean
@ 2009-10-27 17:34 ` Bean
2009-10-28 20:29 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-27 17:34 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-27 17:34 ` Bean
@ 2009-10-28 20:29 ` Bean
2009-10-28 21:12 ` Vladimir 'phcoder' Serbinenko
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-28 20:29 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-28 20:29 ` Bean
@ 2009-10-28 21:12 ` Vladimir 'phcoder' Serbinenko
2009-10-29 3:24 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2009-10-28 21:12 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-28 21:12 ` Vladimir 'phcoder' Serbinenko
@ 2009-10-29 3:24 ` Bean
2009-10-29 9:10 ` Vladimir 'phcoder' Serbinenko
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-29 3:24 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-29 3:24 ` Bean
@ 2009-10-29 9:10 ` Vladimir 'phcoder' Serbinenko
2009-10-29 9:25 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2009-10-29 9:10 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-29 9:10 ` Vladimir 'phcoder' Serbinenko
@ 2009-10-29 9:25 ` Bean
2009-10-29 9:33 ` Vladimir 'phcoder' Serbinenko
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-29 9:25 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-29 9:25 ` Bean
@ 2009-10-29 9:33 ` Vladimir 'phcoder' Serbinenko
2009-10-29 9:52 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2009-10-29 9:33 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-29 9:33 ` Vladimir 'phcoder' Serbinenko
@ 2009-10-29 9:52 ` Bean
2009-10-30 12:07 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-29 9:52 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-29 9:52 ` Bean
@ 2009-10-30 12:07 ` Bean
2009-11-01 17:16 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-30 12:07 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-30 12:07 ` Bean
@ 2009-11-01 17:16 ` Bean
2009-11-09 15:55 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-11-01 17:16 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-11-01 17:16 ` Bean
@ 2009-11-09 15:55 ` Bean
2009-11-09 16:16 ` mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)) Robert Millan
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-11-09 15:55 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))
2009-11-09 15:55 ` Bean
@ 2009-11-09 16:16 ` Robert Millan
2009-11-09 16:46 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Robert Millan @ 2009-11-09 16:16 UTC (permalink / raw)
To: The development of GNU GRUB
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."
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))
2009-11-09 16:16 ` mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)) Robert Millan
@ 2009-11-09 16:46 ` Bean
2009-11-09 20:03 ` Robert Millan
2009-11-09 20:04 ` warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))) Robert Millan
0 siblings, 2 replies; 175+ messages in thread
From: Bean @ 2009-11-09 16:46 UTC (permalink / raw)
To: The development of GNU GRUB
[-- 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'
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))
2009-11-09 16:46 ` Bean
@ 2009-11-09 20:03 ` Robert Millan
2009-11-10 13:51 ` Bean
2009-11-09 20:04 ` warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))) Robert Millan
1 sibling, 1 reply; 175+ messages in thread
From: Robert Millan @ 2009-11-09 20:03 UTC (permalink / raw)
To: The development of GNU GRUB
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."
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))
2009-11-09 20:03 ` Robert Millan
@ 2009-11-10 13:51 ` Bean
0 siblings, 0 replies; 175+ messages in thread
From: Bean @ 2009-11-10 13:51 UTC (permalink / raw)
To: The development of GNU GRUB
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)))
2009-11-09 16:46 ` Bean
2009-11-09 20:03 ` Robert Millan
@ 2009-11-09 20:04 ` Robert Millan
2009-11-09 20:10 ` Felix Zielcke
2009-11-09 20:20 ` Colin Watson
1 sibling, 2 replies; 175+ messages in thread
From: Robert Millan @ 2009-11-09 20:04 UTC (permalink / raw)
To: The development of GNU GRUB
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."
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)))
2009-11-09 20:04 ` warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))) Robert Millan
@ 2009-11-09 20:10 ` Felix Zielcke
2009-11-09 21:07 ` Robert Millan
2009-11-09 20:20 ` Colin Watson
1 sibling, 1 reply; 175+ messages in thread
From: Felix Zielcke @ 2009-11-09 20:10 UTC (permalink / raw)
To: The development of GNU GRUB
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)))
2009-11-09 20:10 ` Felix Zielcke
@ 2009-11-09 21:07 ` Robert Millan
0 siblings, 0 replies; 175+ messages in thread
From: Robert Millan @ 2009-11-09 21:07 UTC (permalink / raw)
To: The development of GNU GRUB
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."
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)))
2009-11-09 20:04 ` warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))) Robert Millan
2009-11-09 20:10 ` Felix Zielcke
@ 2009-11-09 20:20 ` Colin Watson
1 sibling, 0 replies; 175+ messages in thread
From: Colin Watson @ 2009-11-09 20:20 UTC (permalink / raw)
To: The development of GNU GRUB
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]
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-17 20:01 ` Bean
2009-10-18 17:01 ` Bean
@ 2009-10-20 19:06 ` Michal Suchanek
2009-10-21 3:21 ` Bean
1 sibling, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-20 19:06 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-20 19:06 ` [GITGRUB] New menu interface (implementation) Michal Suchanek
@ 2009-10-21 3:21 ` Bean
0 siblings, 0 replies; 175+ messages in thread
From: Bean @ 2009-10-21 3:21 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 15:57 ` Michal Suchanek
2009-10-09 16:17 ` Bean
@ 2009-10-09 16:56 ` richardvoigt
2009-10-09 17:09 ` Michal Suchanek
1 sibling, 1 reply; 175+ messages in thread
From: richardvoigt @ 2009-10-09 16:56 UTC (permalink / raw)
To: The development of GRUB 2
> 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.
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 16:56 ` richardvoigt
@ 2009-10-09 17:09 ` Michal Suchanek
2009-10-09 18:28 ` richardvoigt
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-09 17:09 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 17:09 ` Michal Suchanek
@ 2009-10-09 18:28 ` richardvoigt
2009-10-09 18:49 ` Bean
2009-10-09 20:22 ` Michal Suchanek
0 siblings, 2 replies; 175+ messages in thread
From: richardvoigt @ 2009-10-09 18:28 UTC (permalink / raw)
To: The development of GRUB 2
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.
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 18:28 ` richardvoigt
@ 2009-10-09 18:49 ` Bean
2009-10-09 20:22 ` Michal Suchanek
1 sibling, 0 replies; 175+ messages in thread
From: Bean @ 2009-10-09 18:49 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 18:28 ` richardvoigt
2009-10-09 18:49 ` Bean
@ 2009-10-09 20:22 ` Michal Suchanek
1 sibling, 0 replies; 175+ messages in thread
From: Michal Suchanek @ 2009-10-09 20:22 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 14:54 ` Bean
2009-10-09 15:57 ` Michal Suchanek
@ 2009-10-09 15:58 ` Bean
1 sibling, 0 replies; 175+ messages in thread
From: Bean @ 2009-10-09 15:58 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-08 4:20 ` Bean
2009-10-08 5:21 ` Bean
@ 2009-10-08 11:18 ` Michal Suchanek
2009-10-08 13:07 ` Bean
1 sibling, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-08 11:18 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-08 11:18 ` Michal Suchanek
@ 2009-10-08 13:07 ` Bean
2009-10-08 21:46 ` Michal Suchanek
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-08 13:07 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-08 13:07 ` Bean
@ 2009-10-08 21:46 ` Michal Suchanek
2009-10-09 3:34 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-08 21:46 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-08 21:46 ` Michal Suchanek
@ 2009-10-09 3:34 ` Bean
2009-10-09 11:48 ` Michal Suchanek
0 siblings, 1 reply; 175+ messages in thread
From: Bean @ 2009-10-09 3:34 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 3:34 ` Bean
@ 2009-10-09 11:48 ` Michal Suchanek
2009-10-09 12:34 ` Bean
0 siblings, 1 reply; 175+ messages in thread
From: Michal Suchanek @ 2009-10-09 11:48 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 175+ messages in thread* Re: [GITGRUB] New menu interface (implementation)
2009-10-09 11:48 ` Michal Suchanek
@ 2009-10-09 12:34 ` Bean
0 siblings, 0 replies; 175+ messages in thread
From: Bean @ 2009-10-09 12:34 UTC (permalink / raw)
To: The development of GRUB 2
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/
^ permalink raw reply [flat|nested] 175+ messages in thread
* Re: [GITGRUB] New menu interface (implementation)
2009-10-06 16:35 ` Bean
2009-10-06 18:41 ` Michal Suchanek
2009-10-06 22:16 ` Michal Suchanek
@ 2009-10-06 22:59 ` Michal Suchanek
2 siblings, 0 replies; 175+ messages in thread
From: Michal Suchanek @ 2009-10-06 22:59 UTC (permalink / raw)
To: The development of GRUB 2
[-- 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"
}
}
}
^ permalink raw reply [flat|nested] 175+ messages in thread
