Re: [GITGRUB] New menu interface (implementation)
> Hi, > > I think you've overlooked a detail about grub's menu layout. The > smallest elements, text and image, both have fixed size, The largest > element, the screen, also have fixed size, therefore, we need to > adjust the middle layers to fit both ends, it's not as simple as it > seems. > > There are two method to calculate the size of window. It can be > calculate using children widget, with auto layout, or parent widget, > with x,y,width,height coordinate, as the smallest and largest element > are fixed, we need to switch from children determined size to parent > determined size at some point during the walk of ui tree. > > For operation system, the switch is at the window boundary. Consider > web browser. Inside the browser, elements are placed with layout > manager, no coordinate is needed, but the browser itself is placed on > the screen using x,y,width,height coordinate by the OS. For some OS > like chrome, it seems to incorporate the concept of using the whole > screen as browser. The menu system support both method, it's just a > matter of how you define the border, that's, when to switch from > x,y,width,height positioning to layout manager positioning. > > Therefore, it needs to have two set of margin properties: > > inner_*, outer_* : calculate from children to parent I think that "margin" and "padding" are the standard names for this spacing measurements (distance from content to border) and (distance from border to bounding box), respectively. Also in some systems padding of adjacent elements can overlap. > attach_* : calculate from parent to children > > -- > Bean > > gitgrub home: http://github.com/grub/grub/ > my fork page: http://github.com/bean123/grub/ > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
On Mon, Oct 5, 2009 at 9:40 PM, Michal Suchanek wrote:
> 2009/10/5 Bean :
>> On Mon, Oct 5, 2009 at 5:07 PM, Michal Suchanek wrote:
>>> 2009/10/5 Bean :
On Mon, Oct 5, 2009 at 6:20 AM, Michal Suchanek
wrote:
> Hello
>
> I tried to get some borders into the previous demo but I got overlapping
> panels.
>
> This should not happen because it is not supported. That's what the
> layout manager is for.
Hi,
I think you misunderstand the meaning of margin_* properties. It means
that the widget is always at a constant distance from parent widget.
Once it's set, their position is fixed, it's not subject to the layout
manger. This is used to create sticky panels like docks. For example:
panel
{
panel { id="aa" margin_bottom=0 }
panel { id="bb" }
panel { id="cc" }
panel { id="dd"}
}
aa's location is fixed, bb, cc and dd's location is calculated by the
panel, they can overlap with aa.
The sticky panel also doesn't move when view port is scrolled to
display active item.
>>>
>>> No, dock is easily created like
>>>
>>> panel
>>> {
>>> panel { id="aa" margin_bottom=0 }
>>> panel {
>>> panel { id="bb" }
>>> panel { id="cc" }
>>> panel { id="dd"}
>>> }
>>> }
>>>
>>> A panel should never be removed from layout management, it then
>>> becomes pointless.
>>
>> Hi,
>>
>> Sometimes it's useful to have absolute address, for example to adjust
>> the window according to the background image, it's quite tricky to do
>> this with dynamic positioning. If you want everything to be controlled
>
> How is it hard to measure the place where you want to place the
> element on the background bitmap and use that place as the margin (or
> outer space as you call it) and then align the element to the border
> from which you measured (as in valign = bottom)?
>
> You measure and enter the exact same value as you do with fixed
> positioning but the layout manages makes sure that another element
> does not cover your precisely positioned element.
>
>> by the layout manger, just don't use the property and wrap panels
>> around widgets.
>
> That does not work because I want to insert spacing which the layout
> manager does not do automatically.
>
>>
>> From your previous description, I think your meaning of margin is some
>> kind of space left around the border of panel, I think that could be
>> useful as well, but perhaps with a different name, I'm considering the
>> following properties:
>>
>> inner_left, inner_right, inner_top, inner_bottom: space reserved
>> inside the border
>> outer_left, outer_right, outer_top, outer_bottom: space reserved
>> outside the border
>>
>> Perhaps the naming of margin_* property is a little misleading,
>> perhaps I can rename them distance_* to remind it they're used as
>> fixed distance to borders of parent.
>
> Yes. margin is normally used for spacing, not absolute positioning.
> However, spacing and alignment can be used together to force an
> absolute position without the need for yet another property.
Hi,
I think you've overlooked a detail about grub's menu layout. The
smallest elements, text and image, both have fixed size, The largest
element, the screen, also have fixed size, therefore, we need to
adjust the middle layers to fit both ends, it's not as simple as it
seems.
There are two method to calculate the size of window. It can be
calculate using children widget, with auto layout, or parent widget,
with x,y,width,height coordinate, as the smallest and largest element
are fixed, we need to switch from children determined size to parent
determined size at some point during the walk of ui tree.
For operation system, the switch is at the window boundary. Consider
web browser. Inside the browser, elements are placed with layout
manager, no coordinate is needed, but the browser itself is placed on
the screen using x,y,width,height coordinate by the OS. For some OS
like chrome, it seems to incorporate the concept of using the whole
screen as browser. The menu system support both method, it's just a
matter of how you define the border, that's, when to switch from
x,y,width,height positioning to layout manager positioning.
Therefore, it needs to have two set of margin properties:
inner_*, outer_* : calculate from children to parent
attach_* : calculate from parent to children
--
Bean
gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
On Tue, Oct 6, 2009 at 1:52 AM, richardvo...@gmail.com wrote: >> Perhaps the naming of margin_* property is a little misleading, >> perhaps I can rename them distance_* to remind it they're used as >> fixed distance to borders of parent. > > That's undoubtedly the problem. > > For example, Motif uses the term "attach" to achieve fixed distance > from the edge of the parent (or from a sibling component). > > See e.g. http://www.cs.cf.ac.uk/Dave/X_lecture/node8.html Hi, Oh, attach is a better name, thanks for the tip. -- Bean gitgrub home: http://github.com/grub/grub/ my fork page: http://github.com/bean123/grub/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
On Mon, Oct 5, 2009 at 9:33 PM, Michal Suchanek wrote:
> 2009/10/5 Bean :
>> On Mon, Oct 5, 2009 at 5:07 PM, Michal Suchanek wrote:
>>> A panel should never be removed from layout management, it then
>>> becomes pointless.
>>>
>>> A top-aligned panel should be done with alignment, and should be only
>>> possible in horizontal panels like this:
>>>
>>> panel{
>>> direction = left_to_right
>>> panel{ id ="bb" ;valign = center}
>>> panel{ id ="bb" ; valign = top}
>>> panel{ id ="bb" ; valign = bottom}
>>> }
>>> }
>>>
>>> In a top to bottom or bottom to top the first panel is aligned to
>>> bottom/top side of the panel automatically.
>>
>> Hi,
>>
>> Actually, I just through of a possible issue with children assigned
>> alignment. For the parent panel, there is a halign property, For
>> example, if parent width is 50, each child's width is 10, there are
>> three halign values:
>>
>> halign = right
>> b1 b2 b3 empty
>> 10 10 10 20
>>
>> halign = center
>> b1 empty b2 empty b3
>> 10 10 10 10 10
>
> This can be done with
>
> b1 hspace b2 hspace b3
> 20% 20% 20% 20% 20%
>
> but why would you want such spacing?
>
> Normally you would want the panels take up most space possibly with
> some small spacing or the outer panel shrink around the inner panels.
>
>>
>> halign = right
>
> Perhaps use direction?
> Why do you want the empty space there?
>
> There are infinite possibilities of alignment so we should choose an
> alignment method that allows for commonly used alignments and perhaps
> some less common but useful, not all alignments that somebody can
> possibly think of.
>
Hi,
Consider the outer box as screen, whose size is fixed. If we want the
panels to span the whole screen instead of cluster at the left side,
then halign is quite useful, you can check out the demo to see how the
windows are placed.
>> empty b1 b2 b3
>> 20 10 10 10
>>
>> halign is obviously not belonged to children, so you might write it as:
>>
>> panel{
>> direction = left_to_right
>> halign = center
>> panel{ id ="bb" ;valign = center}
>> panel{ id ="bb" ; valign = top}
>> panel{ id ="bb" ; valign = bottom}
>> }
>> }
>>
>> But then there is problem, as panel can be children as well, for example:
>>
>> panel {
>> id = "top"
>> direction = top_to_bottom
>>
>> panel{
>> id = "aa"
>> direction = left_to_right
>> halign = center
>> panel{ id ="bb" ;valign = center}
>> panel{ id ="bb" ; valign = top}
>> panel{ id ="bb" ; valign = bottom}
>> }
>> }
>> }
>>
>> In this case, should halign of aa be used to control its own alignment
>> from top, or that of its children ?
>
> It should be used to align itself, obviously as you want to control
> the alignment of each child separately and if halign = center was
> applied to all this would not be possible.
Right, perhaps it's more natural that the valign/halign are used for
the widget itself, but I still think it's useful to control parent's
alignment strategy, perhaps with a new property.
--
Bean
gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
PXE booting: no such disk
I'm trying to follow the instructions on this wiki page: http://grub.enbug.org/PXEBOOT and I'm getting "error: no such disk", followed by the "grub rescue>" prompt. If I try `pxe --info` on that prompt, I get: "error: no pxe environment" I'm using "grub-pc 1.97~beta3-1ubuntu7" from Ubuntu Karmic 9.10, and the latest gpxe boot disk as the PXE stack. If I try with my laptop's PXE stack instead, it hangs *before* the "grub rescue>" prompt. I've seen in moddep.lst that pxe depends on bufio, and pxecmd depends on extcmd, so I *also* tried with grub-mkimage --output=core.img --prefix="(pxe)/boot/grub" bufio pxe extcmd pxecmd bug again, to no avail. Any ideas? Thank you, Alkis Georgopoulos ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
GRUB 1.97~beta4
Hi, Version 1.97~beta4 of GNU GRUB has been released. -- 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." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
> Perhaps the naming of margin_* property is a little misleading, > perhaps I can rename them distance_* to remind it they're used as > fixed distance to borders of parent. That's undoubtedly the problem. For example, Motif uses the term "attach" to achieve fixed distance from the edge of the parent (or from a sibling component). See e.g. http://www.cs.cf.ac.uk/Dave/X_lecture/node8.html ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
2009/10/5 Bean :
> On Mon, Oct 5, 2009 at 5:07 PM, Michal Suchanek wrote:
>> 2009/10/5 Bean :
>>> On Mon, Oct 5, 2009 at 6:20 AM, Michal Suchanek wrote:
Hello
I tried to get some borders into the previous demo but I got overlapping
panels.
This should not happen because it is not supported. That's what the
layout manager is for.
>>>
>>> Hi,
>>>
>>> I think you misunderstand the meaning of margin_* properties. It means
>>> that the widget is always at a constant distance from parent widget.
>>> Once it's set, their position is fixed, it's not subject to the layout
>>> manger. This is used to create sticky panels like docks. For example:
>>>
>>> panel
>>> {
>>> panel { id="aa" margin_bottom=0 }
>>> panel { id="bb" }
>>> panel { id="cc" }
>>> panel { id="dd"}
>>> }
>>>
>>> aa's location is fixed, bb, cc and dd's location is calculated by the
>>> panel, they can overlap with aa.
>>>
>>> The sticky panel also doesn't move when view port is scrolled to
>>> display active item.
>>
>> No, dock is easily created like
>>
>> panel
>> {
>> panel { id="aa" margin_bottom=0 }
>> panel {
>> panel { id="bb" }
>> panel { id="cc" }
>> panel { id="dd"}
>> }
>> }
>>
>> A panel should never be removed from layout management, it then
>> becomes pointless.
>
> Hi,
>
> Sometimes it's useful to have absolute address, for example to adjust
> the window according to the background image, it's quite tricky to do
> this with dynamic positioning. If you want everything to be controlled
How is it hard to measure the place where you want to place the
element on the background bitmap and use that place as the margin (or
outer space as you call it) and then align the element to the border
from which you measured (as in valign = bottom)?
You measure and enter the exact same value as you do with fixed
positioning but the layout manages makes sure that another element
does not cover your precisely positioned element.
> by the layout manger, just don't use the property and wrap panels
> around widgets.
That does not work because I want to insert spacing which the layout
manager does not do automatically.
>
> From your previous description, I think your meaning of margin is some
> kind of space left around the border of panel, I think that could be
> useful as well, but perhaps with a different name, I'm considering the
> following properties:
>
> inner_left, inner_right, inner_top, inner_bottom: space reserved
> inside the border
> outer_left, outer_right, outer_top, outer_bottom: space reserved
> outside the border
>
> Perhaps the naming of margin_* property is a little misleading,
> perhaps I can rename them distance_* to remind it they're used as
> fixed distance to borders of parent.
Yes. margin is normally used for spacing, not absolute positioning.
However, spacing and alignment can be used together to force an
absolute position without the need for yet another property.
Thanks
Michal
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
2009/10/5 Bean :
> On Mon, Oct 5, 2009 at 5:07 PM, Michal Suchanek wrote:
>> A panel should never be removed from layout management, it then
>> becomes pointless.
>>
>> A top-aligned panel should be done with alignment, and should be only
>> possible in horizontal panels like this:
>>
>> panel{
>> direction = left_to_right
>> panel{ id ="bb" ;valign = center}
>> panel{ id ="bb" ; valign = top}
>> panel{ id ="bb" ; valign = bottom}
>> }
>> }
>>
>> In a top to bottom or bottom to top the first panel is aligned to
>> bottom/top side of the panel automatically.
>
> Hi,
>
> Actually, I just through of a possible issue with children assigned
> alignment. For the parent panel, there is a halign property, For
> example, if parent width is 50, each child's width is 10, there are
> three halign values:
>
> halign = right
> b1 b2 b3 empty
> 10 10 10 20
>
> halign = center
> b1 empty b2 empty b3
> 10 10 10 10 10
This can be done with
b1 hspace b2 hspace b3
20% 20% 20% 20% 20%
but why would you want such spacing?
Normally you would want the panels take up most space possibly with
some small spacing or the outer panel shrink around the inner panels.
>
> halign = right
Perhaps use direction?
Why do you want the empty space there?
There are infinite possibilities of alignment so we should choose an
alignment method that allows for commonly used alignments and perhaps
some less common but useful, not all alignments that somebody can
possibly think of.
> empty b1 b2 b3
> 20 10 10 10
>
> halign is obviously not belonged to children, so you might write it as:
>
> panel{
> direction = left_to_right
> halign = center
> panel{ id ="bb" ;valign = center}
> panel{ id ="bb" ; valign = top}
> panel{ id ="bb" ; valign = bottom}
> }
> }
>
> But then there is problem, as panel can be children as well, for example:
>
> panel {
> id = "top"
> direction = top_to_bottom
>
> panel{
> id = "aa"
> direction = left_to_right
> halign = center
> panel{ id ="bb" ;valign = center}
> panel{ id ="bb" ; valign = top}
> panel{ id ="bb" ; valign = bottom}
> }
> }
> }
>
> In this case, should halign of aa be used to control its own alignment
> from top, or that of its children ?
It should be used to align itself, obviously as you want to control
the alignment of each child separately and if halign = center was
applied to all this would not be possible.
Thanks
Michal
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
On Mon, Oct 5, 2009 at 5:07 PM, Michal Suchanek wrote:
> A panel should never be removed from layout management, it then
> becomes pointless.
>
> A top-aligned panel should be done with alignment, and should be only
> possible in horizontal panels like this:
>
> panel{
> direction = left_to_right
> panel{ id ="bb" ;valign = center}
> panel{ id ="bb" ; valign = top}
> panel{ id ="bb" ; valign = bottom}
> }
> }
>
> In a top to bottom or bottom to top the first panel is aligned to
> bottom/top side of the panel automatically.
Hi,
Actually, I just through of a possible issue with children assigned
alignment. For the parent panel, there is a halign property, For
example, if parent width is 50, each child's width is 10, there are
three halign values:
halign = right
b1 b2 b3 empty
10 10 10 20
halign = center
b1 empty b2 empty b3
101010 10 10
halign = right
empty b1 b2 b3
20 10 10 10
halign is obviously not belonged to children, so you might write it as:
panel{
direction = left_to_right
halign = center
panel{ id ="bb" ;valign = center}
panel{ id ="bb" ; valign = top}
panel{ id ="bb" ; valign = bottom}
}
}
But then there is problem, as panel can be children as well, for example:
panel {
id = "top"
direction = top_to_bottom
panel{
id = "aa"
direction = left_to_right
halign = center
panel{ id ="bb" ;valign = center}
panel{ id ="bb" ; valign = top}
panel{ id ="bb" ; valign = bottom}
}
}
}
In this case, should halign of aa be used to control its own alignment
from top, or that of its children ?
--
Bean
gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
On Mon, Oct 5, 2009 at 5:07 PM, Michal Suchanek wrote:
> 2009/10/5 Bean :
>> On Mon, Oct 5, 2009 at 6:20 AM, Michal Suchanek wrote:
>>> Hello
>>>
>>> I tried to get some borders into the previous demo but I got overlapping
>>> panels.
>>>
>>> This should not happen because it is not supported. That's what the
>>> layout manager is for.
>>
>> Hi,
>>
>> I think you misunderstand the meaning of margin_* properties. It means
>> that the widget is always at a constant distance from parent widget.
>> Once it's set, their position is fixed, it's not subject to the layout
>> manger. This is used to create sticky panels like docks. For example:
>>
>> panel
>> {
>> panel { id="aa" margin_bottom=0 }
>> panel { id="bb" }
>> panel { id="cc" }
>> panel { id="dd"}
>> }
>>
>> aa's location is fixed, bb, cc and dd's location is calculated by the
>> panel, they can overlap with aa.
>>
>> The sticky panel also doesn't move when view port is scrolled to
>> display active item.
>
> No, dock is easily created like
>
> panel
> {
> panel { id="aa" margin_bottom=0 }
> panel {
> panel { id="bb" }
> panel { id="cc" }
> panel { id="dd"}
> }
> }
>
> A panel should never be removed from layout management, it then
> becomes pointless.
Hi,
Sometimes it's useful to have absolute address, for example to adjust
the window according to the background image, it's quite tricky to do
this with dynamic positioning. If you want everything to be controlled
by the layout manger, just don't use the property and wrap panels
around widgets.
>From your previous description, I think your meaning of margin is some
kind of space left around the border of panel, I think that could be
useful as well, but perhaps with a different name, I'm considering the
following properties:
inner_left, inner_right, inner_top, inner_bottom: space reserved
inside the border
outer_left, outer_right, outer_top, outer_bottom: space reserved
outside the border
Perhaps the naming of margin_* property is a little misleading,
perhaps I can rename them distance_* to remind it they're used as
fixed distance to borders of parent.
>
> A top-aligned panel should be done with alignment, and should be only
> possible in horizontal panels like this:
>
> panel{
> direction = left_to_right
> panel{ id ="bb" ;valign = center}
> panel{ id ="bb" ; valign = top}
> panel{ id ="bb" ; valign = bottom}
> }
> }
>
> In a top to bottom or bottom to top the first panel is aligned to
> bottom/top side of the panel automatically.
In the currently implementation, valign is for the parent widget
panel{
direction = left_to_right
valign = center
panel{ id ="bb"}
panel{ id ="bb"}
panel{ id ="bb"}
}
}
Align all child vertically, but I guess this can be implemented per child.
--
Bean
gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
2009/10/5 Bean : > On Mon, Oct 5, 2009 at 5:57 AM, Michal Suchanek wrote: >> There are panels above it so it is not left to right. >> >> The margin should increase the outer size of the widget so that when >> space is allocated for it the margin is taken into account but not >> stick it to the bottom. That's what alignment (valign) is for. > > Hi, > > To add space between widgets whose location is calculated by layout > manger, use hspace and vspace, margin_bottom is used to indicate that It does not add space between the elements contained in a panel and the border of the panel. Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
2009/10/5 Bean :
> On Mon, Oct 5, 2009 at 6:20 AM, Michal Suchanek wrote:
>> Hello
>>
>> I tried to get some borders into the previous demo but I got overlapping
>> panels.
>>
>> This should not happen because it is not supported. That's what the
>> layout manager is for.
>
> Hi,
>
> I think you misunderstand the meaning of margin_* properties. It means
> that the widget is always at a constant distance from parent widget.
> Once it's set, their position is fixed, it's not subject to the layout
> manger. This is used to create sticky panels like docks. For example:
>
> panel
> {
> panel { id="aa" margin_bottom=0 }
> panel { id="bb" }
> panel { id="cc" }
> panel { id="dd"}
> }
>
> aa's location is fixed, bb, cc and dd's location is calculated by the
> panel, they can overlap with aa.
>
> The sticky panel also doesn't move when view port is scrolled to
> display active item.
No, dock is easily created like
panel
{
panel { id="aa" margin_bottom=0 }
panel {
panel { id="bb" }
panel { id="cc" }
panel { id="dd"}
}
}
A panel should never be removed from layout management, it then
becomes pointless.
A top-aligned panel should be done with alignment, and should be only
possible in horizontal panels like this:
panel{
direction = left_to_right
panel{ id ="bb" ;valign = center}
panel{ id ="bb" ; valign = top}
panel{ id ="bb" ; valign = bottom}
}
}
In a top to bottom or bottom to top the first panel is aligned to
bottom/top side of the panel automatically.
The margin property should not force a fixed position because it
breaks layout to the point that elements overlap and it's completely
pointless to have fixed position since position can be specified with
margins and alignment once width is fixed to include margins.
Thanks
Michal
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
