Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek <hramrach@centrum.cz>]

2009/10/9 Bean <bean123ch@gmail.com>:
> On Sat, Oct 10, 2009 at 12:29 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> 2009/10/9 Bean <bean123ch@gmail.com>:
>>> On Fri, Oct 9, 2009 at 11:57 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> I am suggesting an interface that allows style commands like
>>>>
>>>> style {
>>>>
>>>> (class==button).(text==OK) { <style> }
>>>>
>>>> (class==dialog).<nothing here>.(class=button) { <style> }
>>>>
>>>> (class==buttonbar) { direction = right_to_left }
>>>>
>>>> (class==button) {
>>>>  border_top = button_top
>>>>  border_left = button_left
>>>>  ...
>>>> }
>>>>
>>>> }
>>>>
>>>> for
>>>>
>>>> panel { class = dialog ; direction = top_to_bottom
>>>>  panel {
>>>>   scroll = auto
>>>>    text { Blah blah blah... }
>>>>  }
>>>>  panel { class = buttonbar ;
>>>>  panel { class = button ; img { check.png } ;text { OK } ; command =
>>>> <something> }
>>>>  panel { class = button ; img { cross.png } ;text { Cancel } ;
>>>> command = <something>}
>>>>  }
>>>> }
>>>>
>>>> The exact syntax and semantic of the selectors it to be defined.
>>>>
>>>> They may be imperative commands that are applied immediately to all
>>>> widgets currently in existence or they may be stored in a style
>>>> database that widgets consult each time they are drawn or some
>>>> combination of the above (for example the style commands affect a
>>>> style database in order of appearance but do not affect widgets
>>>> directly).
>>>>
>>>> I guess the styles that appear in the main config (grub.cfg or loaded
>>>> by loadcfg) should be added together so that scripts that generate
>>>> different parts of the file can add style bits for their widgets.
>>>>
>>>> loadstyle command should reset all widget style properties to default
>>>> (either widget default or the state after loading config) and then
>>>> interpret the content of the file as if it was enclosed in style {}.
>>>>
>>>> When loadstyle is repeated the widgets should be reset again so that
>>>> previous style cannot affect the newly loaded style.
>>>
>>> Hi,
>>>
>>> Perhaps it can be written like this:
>>>
>>> class {
>>
>> perhaps this should be
>>
>> style {
>>
>>>  button.text_OK { <style>}
>>
>> text_OK is quite ugly for a selector that specifies that the property
>> text should be equal OK.
>>
>> What if the text contains a space or underscore or the property
>> contains underscore?
>>
>>>  dialog.*button { <style> }
>>
>> perhaps this should be
>>
>> dialog.*.button
>>
>> meaning there is one element in between or
>>
>> dialog.**.button
>>
>> meaning there can be zero or more elements in between {which is sorely
>> missing from CSS}
>
> Hi,
>
> Do we need to distinguish the situation that exactly one element is in
> between ?
>
>>
>>>  buttonbar { direction = right_to_left }
>>>  button {  border_top = button_top  border_left = button_left }
>>> }
>>>
>>> panel { class = dialog ; direction = top_to_bottom
>>>  panel {
>>>   scroll = auto
>>>    text { Blah blah blah... }
>>>  }
>>>  panel { class = buttonbar ;
>>>  panel { class = button ; img { check.png } ;text { class=text_OK } ;
>>> command =<something> }
>>>  panel { class = button ; img { cross.png } ;text { class=text_Cancel
>>> } ; command = <something>}
>>>  }
>>>  }
>>>
>>
>> This resolves the syntax issue somewhat but there is still problem
>> with the order in which the rules are applied.
>
> We can first try parent*class format, from near to far, then class
> itself. If class is not set, use the widget name, for example, in the
> following config:
>
> panel
> {
>  class = aa
>  panel {
>  class = bb
>  panel {
>    text { class=cc id=text1 }
>  }
>  text { id=text2}
> }
>
> We scan the following section in order:
>
> text1:
> bb.cc
> bb.**.cc:
> aa.*.cc
> aa.**.cc
> cc

I would guess it should be

* /* everything */
text /* = **.text */
cc /* class specified */
aa.**.text
aa.**.cc
bb.**.text /* nearer start*/
bb.**.cc
aa.*.text /* less starry */
aa.*,cc
bb.text
bb.cc
aa.bb..text /* more elements specified in the path */
aa.bb.cc

meaning that a property can be set by any of the above but the later
styles (lower in the list) can override properties set earlier.

This is similar to what X props or CSS would do - the resulting
properties do not depend on the order of styling in text but on how
"specific" the selector is.

This requires a style store separate from the widgets but likely
results in somewhat tidier and better predicatble behaviour than
setting the properties directly on the widgets. The separate style
store also means that you can save the state before loading a style
and reset it later quite easily.

Overriding styles in this system is problematic, that's why the
properties should be reset when a different style is loaded.

The properties set directly on the widgets should be probably
consulted first, before the * style, and it should be possible to
restore them when the style is changed.

Thanks

Michal