2009/9/3 Bean <bean12...@gmail.com>:
> On Thu, Sep 3, 2009 at 3:43 AM, Michal Suchanek<hramr...@centrum.cz> wrote:
>> 2009/9/2 Bean <bean12...@gmail.com>:
>>> On Thu, Sep 3, 2009 at 1:25 AM, Michal Suchanek<hramr...@centrum.cz> wrote:
>>>> 2009/9/2 Bean <bean12...@gmail.com>:
>>>>> On Wed, Sep 2, 2009 at 11:27 PM, Michal Suchanek<hramr...@centrum.cz>
>>>>> 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.
And how would you place the menu items then? At random?
Thanks
Michal
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
