Re: [GITGRUB] New menu interface (implementation)

[Bean <bean123ch@gmail.com>]

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

Hi,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

to

image = "/menu/ubunti.png"

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

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

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

-- 
Bean

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