Re: [GITGRUB] New menu interface

[Michal Suchanek]

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.

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)

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

Thanks

Michal