Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/6 Bean <address@hidden>:
> On Tue, Oct 6, 2009 at 11:18 PM, Michal Suchanek <address@hidden> wrote:
>> 2009/10/6 Bean <address@hidden>:
>>> On Tue, Oct 6, 2009 at 7:46 PM, Michal Suchanek <address@hidden> 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