Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

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

That sounds reasonable.

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

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

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

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

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


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

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

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

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

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

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

Thanks

Michal