[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: Tue, 20 Oct 2009 21:20:39 +0200

2009/10/18 Bean <address@hidden>:
> Hi,
> Update:
> Add mapkey section. For example:
> mapkey {
>  f5 = ctrl-x
> }

Does this also generate a mapkey text which you can dump into a text
box so that people know what is mapped to what (and the same for the
default bindings and grub version/last git commit)?

Wouldn't it be more practical and transparent to just make the
mappings configurable?

That is write the current mappings as key->function assignments and
then allow change mappings / add new mappings.

> maps f5 key to ctrl-x, this is important for platforms like EFI as
> ctrl-x can't be input.
> key name should be lowercase, it can be single character, f1 to f10,
> ctrl-a to ctrl-z, left, right, up, down, home, end, delete, page_up,
> page_down, esc, tab, backspace and space.
> Add onkey section, which allow you to assign a function when a key is
> pressed. For example ,this is the onkey section for the demo:
> onkey {
>  c = "menu_popup term_window"
>  e = "menu_popup edit_window edit.text=command"
>  f7 = "menu_popup layout_test"
>  f8 = menu_toggle_mode
>  f9 = halt
>  f10 = reboot
> }

This should be merged with the mapkey into a single key mapping function.

> c open a terminal window, e open a edit box to edit the current
> command, use ctrl-x to save it. f7 runs the layout demo test, f8
> toggle between text and graphic mode, f9 shutdown, f10 reboot.
> Data binding for popup windows, for example, in the above example,
> menu_popup edit_window edit.text=command
> property text in the edit widget in the popup dialog binds to the
> command property of current node, this is used to implement the edit
> function.
> Add two property attach_hcenter and attach_vcenter for layout manager.

What is the actual use case for windows which are not managed in the
layout and thus potentially overlap other windows in a system where
window overlapping is not handled?

> The top widget of popup window must use absolute position, as widget
> are already placed in screen and can't be moved without refresh. But
> it's not easy to put the widget in the middle of screen using
> attach_left/right/top/bottom, the new property attach_hcenter and
> attach_vcenter defines the offset from the center of screen.

Can't you just make the popup fullscreen?

IMHO it rids us of quite a few things  that allow people to shoot
themselves in the foot and require documentation and maintenance while
not removing anything particularly useful.

> Support TAB completion for term widget.

That's very nice.



reply via email to

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