grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GITGRUB] New menu interface (implementation)


From: Bean
Subject: Re: [GITGRUB] New menu interface (implementation)
Date: Wed, 7 Oct 2009 00:35:08 +0800

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).
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.

-- 
Bean

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]