[Top][All Lists]

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

Re: [GITGRUB] New menu interface (second draft)

From: Bean
Subject: Re: [GITGRUB] New menu interface (second draft)
Date: Tue, 8 Sep 2009 19:14:58 +0800

On Tue, Sep 8, 2009 at 4:14 PM, Michal Suchanek<address@hidden> wrote:
> 2009/9/7 Bean <address@hidden>:
>> Hi,
>> After considering the discussion of first post, I come up with the
>> second draft for new menu interface implementation.
>> First, the basic drawing unit is now region, there are four types:
>> text
>> Single line of text, have alignment attribute.
>> image
>> An image, have scaling and alignment attribute.
>> rect
>> A rectangle area filled with background color.
>> viewport
>> A viewport in the container box. This is used for strolling.
>> The whole ui are composed of the above regions, components add their
>> drawing regions to a global tree which handles region updates for
>> them.
>> One of the shortcoming of Colin's graphic patch is that the update
>> process is not optimized. The screen flickers a lot without double
>> buffer. Double buffer eats up a lot of memory, which is a problem in
>> platforms like OpenFirmware. And even with double buffer, the
>> redrawing process takes time and response is quite slow. The new menu
>> interface split ui into small regions which uses different update
>> strategy, and redraw only the necessary regions.
>> Component is the basic unit for interaction. Each component has a flag
>> that indicate if it can receive input focus. The last component with
>> input focus will be the current input, you can use a hotkey like
>> ctrl-tab to switch to other component.
>> Some of the components:
>> label
>> Text label, it consist of text region.
>> image
>> Image, it consist of image region.
> How does an image map to other menu rendering like: text-only, dumb terminal ?
> You can render a menu item that has an image and text in both but
> image would not show without graphics. The style may turn off  the
> text if graphics is available.
> IMHO images need not be available separately. You can put them in the
> background of an element or as an icon to text+icon label element. The
> style then specifies in which direction from icon the text is shown
> (hidden, over the center, above, below, left, right ..).


Actually there is bitmap for text mode as well, it's ascii art. And
the main reason to separate image from others is for update control.
Bitmaps uses blt to update a region, rect uses fill, and text uses
draw_font, each have different update algorithm.

>> frame
>> Window frame. This is normally used by other component to draw the
>> border, it consist of multiple image and/or rect region.
>> panel
>> Layout manager. It can have a scrollbar when the actual content is
>> bigger than the window size. it consist of viewport region.
> How does a frame differ from a panel?

The frame only draws the window border, and panel is layout manger.
It's possible to use panel without frame, for example, listbox.

>> text
>> Multi-line text box. It has a frame and a text box in the center.
> Why another frame ? We have a frame component already.

Frame is only responsible for the border, the actual content is
controlled by another component.

>> edit
>> Single line edit box. It has a frame and an edit box in the center.
>> Has input focus.
> Another frame?
> Is this even needed? The only editable thing in gfxterm is multiline -
> the whole menu entry.

This edit box is mainly for popups, for example, it can be used to
input passwords.

>> menu
>> Menu box. It has a frame, a panel for layout control, and multiple
>> menu items. Has input focus.
> Is this even needed? The menu is always generated by a script so there
> is no problem if multiple elements are used in the default menu and it
> can be customized if it is not a fixed element.

This only control the style and layout of menu component, the actual
menu items is added in menuentry statement.

>> term
>> Terminal emulator. It has a frame and a two dimension edit box in the
>> center. Has input focus.
> Thanks
> Michal
> _______________________________________________
> Grub-devel mailing list
> address@hidden


gitgrub home:
my fork page:

reply via email to

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