grub-devel
[Top][All Lists]
Advanced

[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: Thu, 22 Oct 2009 09:41:31 +0200

2009/10/22 Bean <address@hidden>:
> On Thu, Oct 22, 2009 at 4:47 AM, Michal Suchanek <address@hidden> wrote:
>> 2009/10/21 Bean <address@hidden>:
>>> On Wed, Oct 21, 2009 at 3:20 AM, Michal Suchanek <address@hidden> wrote:
>>>> 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.
>>>>
>>>
>>> Hi,
>>>
>>> The difference of mapkey and onkey is when they're executed. The order
>>> is as follows:
>>>
>>> mapkey
>>> onkey function of current widget
>>> key binding in onkey section
>>>
>>> For example in the edit widget, you use ctrl-x to finish current edit.
>>> But in EFI, you can't input ctrl-x. The way to solve this is to map
>>> another key as ctrl-x, which use mapkey function. Adding function in
>>> onkey doesn't help, as by the time it reaches there, the edit widget
>>> has finish handling.
>>>
>>> Also, if the key is used by widget, the binding in onkey doesn't help.
>>> This is actually a good thing, for example,  we can add hotkey c to
>>> open a terminal window. This has effect on main menu, but we certainly
>>> don't want it when inside term already. But if we do need to change a
>>> key used by widget, we can map it in mapkey section.
>>
>> Why do you need a separate mapping?
>>
>> The widget either handles the key or not, and it should pass it to its
>> parent if it does not handle it.
>>
>> The function in question is either a widget specific function or not
>> so you know where it should be processed.
>>
>> I am not sure what is the difference in mapkey and "onkey in current widget".
>>
>
> Hi,
>
> Here, function means C function. In config file, all configurable
> command is grub command, no command is specific to certain widget.
> Widget have a onkey callback function which gives it the chance to
> handle the current key press, if it doesn't handle it, it would be
> passed to system.

if it's handled by the widget it must be a function specific to a
widget, otherwise it would not be handled by a widget but do something
global, even in widget's onkey.

>
> So, you can use mapkey to map a key to the one interested by the
> widget. For example, edit control use ctrl-x key to indicate the
> finish of edit. If ctrl-x can't be input, you map F5 to it so that you
> can finish the edit.
>
> This is similar to the vim style of key handling, that's, each key
> defines a specific function. I guess it's possible to use emacs style,
> where each function is named with string. But I think that system is a
> little overkill, you need to bind every function to some key before
> you have a working system, while the current method works out of the
> box, you just change the mapping you need.

I think that naming the function is the first step to writing out the
mapping in a user readable form so that it can be automatically
included in help texts.

Having the functions named does not mean that grub cannot include a
default map. It just means that the functions mapped by default and
not yet mapped are equal, and they can be mapped and remapped in the
configuration the same way.

Binding functions to key names sucks. Not all keyboards have the same
labels and some people might want to use different input, etc.

>
>>>>>
>>>>> 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?
>>>
>>> Popup window. For example, the e hotkey popup a edit box to edit
>>> current command. The top window of popup is placed in screen directly
>>> and not controlled by layout manger.
>>
>> In gfxterm the edit box is fullscreen and some lines still wrap for me
>> so I think it is the right way to handle these edits. They should get
>> as much space as possible, there can be (and typically is) quite a bit
>> of text.
>>
>> You can add the title of the edited item as a label at the top of the
>> edit screen perhaps.
>>
>
> I'm not sure showing a edit with only one or two lines full screen
> have the best look, especially when screen is very large. Although you
> can certainly config it that way. The choice is in the theme writer.

You can't know how much text the editor will have. However, there's no
reason to clutter the screen with other unusable elements. I would
rather include the list of keys that can be used in the editor if you
feel the edit screen is too empty.

Also I would like a way to easily scale the layout so that it is the
same size regardless of screen resolution. That is, if I have a
1600x1200 screen and a layout designed for 640x480 it might be useful
to just scale it to fit the on screen.

>
>>>
>>>>
>>>>> 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.
>>>
>>> You can configure the sub menu to pop up full screen. But I like it
>>> alongside the parent menu. IMO, this is the most common way to display
>>> a submenu.
>>
>> What's the advantage of having submenu alongside the parent menu?
>>
>> The disadvantage is complex, error-prone and inefficient layout
>> algorithm. How do you handle submenus that are larger than the screen
>> and would not fit in any case, for example. Or submenus that would
>> just fit if there wasn't any parent menu alongside the submenu. Or
>> submenus that are as wide/large as the screen but pop up from an item
>> in the middle of the screen.
>>
>> Another disadvantage is cluttered screen. Many distributions present
>> timezone and/or language selection as menus. These are large
>> multilevel selections because putting all the options into one list is
>> quite useless, you could navigate all day just to find your timezone
>> and language. Imagine drawing these with the alongside-menu.
>>
>> I see no advantage. For clarity you can put the name of the parent
>> item as a title of the menu screen so you know exactly where you are,
>> what are your choices, and the screen is not cluttered with other
>> inaccessible distracting rubbish.
>>
>> I know that submenus displayed at some random point near the menu item
>> from which they were activated are often used in GUI toolkits but this
>> does not make the practice good or desirable. There are many corner
>> cases which are likely experienced on small screens (and grub may
>> often use small resolution for compatibility) which are quite
>> confusing. When there are multiple levels of such menus it gets very
>> messy and it is getting hard to find a sensible placing for new
>> submenus. It does not add to readability or anything, you still have
>> to walk the submenus to see which options are available.
>>
>> An advantage of a simple menu it it can be also presented as a list of
>> choices on a dumb terminal (see Debian reportbug as a sample of such
>> interface or the difference between dpkg dialog and readline
>> frontends). No need to write a separate menu for that case, new
>> visualization should suffice.
>
> Actually the handling is very simple, by adding -r or --relative
> option to menu_popup, it moves the widget in relates to parent using
> attach_left/attach_right/attach_top/attach_bottom, instead of the
> default location of top left corner. The problem you describe, sub
> menu grows out of screen, this can happen even when full screen. It's
> the job of scroller, which would scroll the widget into view when
> selected. If you insist, I can just add a option to skip -r.

Yes, a menu can be larger than the screen even when it is displayed fullscreen.

The problem is that displaying a large menu that does not fit next to
its parent menu makes the scrolling confusing. Scrolling is typically
not present on these kinds of menus. The other problem is that the
place covered by the parent is what the menu would require to fit
fully on screen which is ineffective. You cannot use the parent menu
while in the sublemenu but it uses screen space.

Thanks

Michal




reply via email to

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