Re: [GITGRUB] New menu interface

[Bean]

On Thu, Sep 3, 2009 at 3:43 AM, Michal Suchanek<address@hidden> wrote:
> 2009/9/2 Bean <address@hidden>:
>> On Thu, Sep 3, 2009 at 1:25 AM, Michal Suchanek<address@hidden> wrote:
>>> 2009/9/2 Bean <address@hidden>:
>>>> On Wed, Sep 2, 2009 at 11:27 PM, Michal Suchanek<address@hidden> wrote:
>>>>> How will it fit screen? What if the image is 4:3 and  the screen is
>>>>> 5:4 or widescreen?
>>>>
>>>> It'd scale to fit the new proportion, although the image perhaps won't
>>>> look nice in this case. We could choose one of the following rendering
>>>> method based on option:
>>>>
>>>> Center
>>>> Scaling (full)
>>>> Scaling (keep ratio)
>>>> Tiling
>>>
>>> Other common uses are
>>>
>>> Scaling (cover) - keep aspect but cover the whole area (with parts of
>>> the picture sticking out of the viewport) - useful with a
>>> non-intrusive background like a photo of fallen leaves or the like
>>>
>>> Left, Right, TopLeft, BottomRight, ... - for side and corner decorations.
>>
>> Hi,
>>
>> Sounds good, and it shouldn't be difficult to implement.
>>
>>>
>>>>
>>>>> Percentages are a good start. However, if you make your menu
>>>>> percentage based adding new items or new menu areas is still
>>>>> problematic.
>>>>
>>>> Actually I've though of another representation, using the font metrics
>>>> as base unit,  something like this:
>>>>
>>>> + menu {
>>>>  x = 10%
>>>>  y = 10%
>>>>  width = 30c
>>>>  height = 30c
>>>> }
>>>
>>> Does that c represent the width of the character "c"? What about
>>> proportional fonts?
>>
>> The suffix c means character. For proportional fonts, it's the average
>> width of font used by the current component.
>
> Still why would you want an object about 30 characters wide? You
> either want an object that can accommodate its content or an object
> that fills available space. An object "about 30 characters wide" is
> useless in my view.

Hi,

For example, we might want to limit the width of edit box to display
at most 30 characters, in this case 30c is quite useful.

And the c unit is usable in both text and graphic mode. If we write
y=2c, y is 2 character height, this looks acceptable in both text and
graphics mode, but y=2 is extremely narrow in graphic mode. In fact, c
is the unit used in the current gfxterm.

> If it's height you can be sure you can put 30 menu items in there then
> (but then it would be in some units on fount height not width)

For y and height property, c is calculated using font height instead of width.

>
>>
>>>
>>> I think it is OK if the layout manager was in Lua if that makes
>>> hacking on it easier but you still need the support functions for a
>>> fully functional layout manager in C for that to work.
>>
>> Yeah, I think it'd be better to implement to whole framework in C at
>> first. LUA could be used to write custom component that extends the
>> function of existing components.
>>
>
> Actually the code in video subsystem that is required for writing a
> layout manager is already there or easy to add.
>
> - get_viewport - get available area
> - set_viewport - limit drawing to selected component
> - get_text_width
> - get_font_height - find out the size of a rectangle needed to draw a
> specific string
>
> What is needed is parser for some configuration format that can store
> arbitrary attributes which can then be interpreted by the layout
> manager.

We can select the layout manager using layout property. Although for
simple interface, I don't think layout manager is necessary, as there
won't be too many components on screen.

-- 
Bean

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