[Top][All Lists]

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

Re: [GITGRUB] New menu interface (implementation)

From: Michal Suchanek
Subject: Re: [GITGRUB] New menu interface (implementation)
Date: Sun, 20 Sep 2009 10:30:04 +0200

2009/9/19 Bean <address@hidden>:
> On Sat, Sep 19, 2009 at 10:38 PM, Michal Suchanek <address@hidden> wrote:
>> Hello
>> 2009/9/16 Bean <address@hidden>:
>>> set gfxmode="640x480"
>>> loadfont /unifont.pf2
>>> ismod vbe
>>> insmod png
>>> menutest
>>> It runs four tests, it would pause after each test, press any key to 
>>> continue.
>>> 1, It starts with text mode with three rects, the second rect have 3
>>> texts, but the last one is outside the view port and therefore not
>>> visible.
>>> 2. It moves the second rect to the top and change the view port, now
>>> the third text is visible but the first is hidden.
>>> 3-4 rerun the following test in graphic mode. If /r1.png, /r2.png, or
>>> /r3.png exists, the image will replace the corresponding rect box.
>> Is it possible to change the demo so that the second rectangle does
>> not get to top?
>> To me it is not obvious where it is raised.
>> If it is not possible it's fine with me, I do not think that
>> overlapping elements have to be supported but if they are not the demo
>> should look different, right?
> Hi,
> The second rectangle is raised as we update it. Normally this is what
> we want as the current selected item should be raised to top. If you
> want to keep the third rect on top, just update it as well:
>  grub_menu_region_update (&head, r2, 0, 0, r2->common.width,
> r2->common.height);
>  grub_menu_region_update (&head, r3, 0, 0, r3->common.width,
> r3->common.height);
>  grub_menu_region_apply_update (head);
>> why does the menu system have a glyph drawing function?
>> Is the one in font.c not suitable?
> The one in font.c is not usable, as it draws the whole glyph, but in
> the menu system, sometimes we only want to update a portion of it.

Couldn't you use viewport on the target for this?

This would be a problem if you allowed overlapping but since you do
not all regions are rectangular and setting up the viewport is easy.

>> Why are there two methods for returning text width and height, one in
>> gfx_region in pixels, the other in text_region in characters? Does
>> size in characters make any sense? There might be proportional fonts
>> or at least fonts of different size in the future.
> For example, we need to find out the length of string "HELLO" so that
> we can align it to the center of screen. In graphic mode, this would
> be the pixel width, but in text mode, it's the number of characters,
> 5.

So the text region is intended for drawing on text screen and the
graphics region on graphics screen. I assume the check for pure text
mode is there to choose which one is used.

However, wouldn't this switch in coordinate system complicate further
extending of the menu system with additional components?

With these different coordinates every compound component would likely
have to check which kind of rectangle is currently in use.

Still it might work - borders have to be drawn differently, pictures
currently don't work, and alignment should work with any units (and
it's easier to see rounding errors if the units are large).

There is slight issue with element placement, though, If somebody uses
pixel coordinates for placing elements then the offsets will suddenly
become huge in text mode. Shouldn't the layouts be more portable?



reply via email to

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