Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/1 Bean <address@hidden>:
> On Thu, Oct 1, 2009 at 10:53 PM, Michal Suchanek <address@hidden> wrote:
>> 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.
>
> Hi,
>
> The window = 1 is used to group some input items together, for example:
>
> screen {
>  panel {   # A
>    window = 1
>    panel { }  #A1
>    panel { }  #A2
>  }
>
>  panel { # B
>    window = 1
>    panel { } #B1
>    panel { } #B2
>  }
> }
>
> This define two menus, each with two items. Each menu remember its
> current selection, for example, if panel A select a language, panel B
> select theme, both can have current selection at the same time. You

Yes, they should both remember their position.

I still don't see any reason why the window = 1 property could not be
set automatically.

> can walk from A to B as they represent two different things.

That's useful, and in case the number of panels is reasonably small so
that you can put them together into a simple layout you could use the
up/down keys to select the item in the panel and left/right to select
the "window" panel.

Thanks

Michal