Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

Hello

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

We do. It improves readability.

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

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

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


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

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

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

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

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

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

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

All my attempts failed miserably.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks

Michal