Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Sat, Oct 10, 2009 at 12:29 AM, Michal Suchanek <address@hidden> wrote:
> 2009/10/9 Bean <address@hidden>:
>> On Fri, Oct 9, 2009 at 11:57 PM, Michal Suchanek <address@hidden> 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

text2:
aa.text
aa.**.text
text


-- 
Bean

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