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

[Michal Suchanek]

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

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

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

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

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

>
> term
> Terminal emulator. It has a frame and a two dimension edit box in the
> center. Has input focus.
>

Thanks

Michal