Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/1 Bean <address@hidden>:
> On Thu, Oct 1, 2009 at 8:44 PM, Michal Suchanek <address@hidden> wrote:
>> 2009/10/1 Bean <address@hidden>:
>>> On Thu, Oct 1, 2009 at 4:41 PM, Michal Suchanek <address@hidden> wrote:
>>>> Cannot this be inferred automatically?
>>>>
>>>> That is any panel that contains command items is a window.
>>>
>>> Hi,
>>>
>>> Sometimes panel can be used to ground some widgets together, for
>>> example, a dialog may look like this:
>>>
>>> panel
>>> {
>>> ádirection = vertical
>>> áinput = 1
>>>
>>> ápanel
>>> á{
>>> á ádirection = horizontal
>>> á átext { text="username"}
>>> á áedit {}
>>> á}
>>>
>>> ápanel
>>> á{
>>> á ádirection = horizontal
>>> á átext { text="password"}
>>> á áedit {}
>>> á}
>>> }
>>>
>>> In this case, the outer panel should be a single window, and the edits
>>> are items. The inner panel is only used for layout, we don't want them
>>> to receive input focus.
>>
>> Since the panel only contains one active item ( the edit ) this should
>> still work.
>>
>> I recall writing about this here already.
>
> Hi,
>
> It'd be ok if we only have one level input items, but I plans to add
> two two level interaction, first is window, second is item, TAB switch
> different window, while UP/DOWN switch different items. In this setup,
> we need to mark the panel that acted as window.
>

Yes, there's no problem inferring the interaction from the widget tree.

Widgets that don't do anything don't get focus, they are ignored for
purpose of determining focus.

An active item like edit or panel with command is an atomic widget for
focus. A panel that contains exactly one atomic widget is also atomic.

A panel that contains multiple atomic items (or alternatively in which
atomic item is focused) acts on directional keys by switching focus to
next item - this seems what window = 1 does.

A panel that contains multiple panels that can focus but are not
atomic handles (Shift +)TAB by switching to the (previous) next
contained panel. In case the focused panel is its (first) last
focusable item it passes the key to the upper panel.

As an extension the panel direction can be taken into account, and
panels can be seen as atomic in both directions (atomic) atomic in
vertical direction (horizontal panel containing atomic widgets), ...

This can work completely automagically without user setup and thus can
eliminate errors in the setup.

It perhaps might be useful to override the default in some cases but
this should work for any menu I would want to put together.

Thanks

Michal