Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Thu, Oct 22, 2009 at 3:41 PM, Michal Suchanek <address@hidden> wrote:
>> 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.
>

Hi,

Yep, this is how it's handled now, if the widget doesn't interested in
the key, it return a value of SKIP and the global key mapping is
checked.

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

I understand that named method is better than using keys directly. But
the current method works and it's simpler to implement. There are
other area that needs more attention at the moment, so it's not a
priority to change it now.

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

You can't scale fonts, for other element, you just use the percentage
notion and it will scale according to the screen size.

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

The point of displaying the parent menu is to provide navigation clues
to the current location. If the tree level is deep, users can get lost
pretty quickly if all menu looks the same. By displaying the parent
menus, users can go from A to B much easier. And whether to use full
screen or not is the choice of user, we shouldn't enforce one scheme
or another in code.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/