Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/9 Bean <address@hidden>:
> On Fri, Oct 9, 2009 at 10:20 PM, Michal Suchanek <address@hidden> wrote:
>> 2009/10/9 Bean <address@hidden>:
>>> On Fri, Oct 9, 2009 at 7:52 PM, Michal Suchanek <address@hidden> wrote:
>>>> Yes, that's nice to name the dialog so that it can be styled more easily.
>>>>
>>>> However, the text has no style assigned. Still the user should be able
>>>> to do something like
>>>>
>>>> popup text { font-face: sans }
>>>>
>>>> or
>>>>
>>>>  .dialog.mesasge text { font-face: sans }
>>>>
>>>> to override the font used in the dialog although the text element is
>>>> not explicitly linked to any style.
>>>
>>> Hi,
>>>
>>> Oh, perhaps the name style is not very appropriate here, class may be
>>> a better one. As for the sub element, it can be handle it like this:
>>>
>>> panel { class=dialog.message text { text="Hello" }}
>>>
>>> class
>>> {
>>>  dialog.message
>>>  {
>>>    background = "/back.png"
>>>    color="blue"
>>>  }
>>> }
>>>
>>> All widgets under the panel would looks in the dialog.message section
>>> for default property, this is similar to Xterm*color in Xresource.
>>> This method also make it easier to define a menu item:
>>>
>>> panel { class=menu.debian image {} text {}}
>>>
>>> class
>>> {
>>>  menu.debian
>>>  {
>>>    image = "/debian.png"
>>>    text = "Boot debian"
>>>  }
>>> }
>>>
>>
>> I don't understand what is what in this example. Which part is the style 
>> here?
>>
>> In my mind there are two separate parts of the menu.
>>
>> 1) the content - text and icons separated into logical groups
>>
>> 2) style which specifies how these logical groups are rendered
>>
>> By now we have enough styling properties that adding a style to bare
>> widget tree should not require meaningless elements. The unit of user
>> visible focus focus is a panel and the unit of content is an edit,
>> text or bitmap.
>>
>> It is natural then that a panel is used to group several content
>> elements (text and edit or bitmap) that represent aspects of a single
>> action into a single panel and group related panels (such as the boot
>> menu items in current gfxterm) into a larger panel.
>>
>>
>> The widget properties that relate to content (text, the image for
>> bitmap element, command/action, key shortcut) should not be affected
>> by style. Even if it is possible right now we should forbid it for
>> consistency and security reasons. Localization should be applied while
>> generating the layout, possibly by generating the layout in multiple
>> languages and allowing to switch between languages.
>>
>> A style should be generally applicable to any layout (mostly) without
>> any help from the layout author. You can add user styles to your
>> browser to fix style problems on existing sites, for example. I think
>> in grub we do not need this level of control, it's fine if loading a
>> new style completely replaces (rather than amends) the previous style.
>>
>> Still applying a style should not rely on every element having a class
>> wherever the style is to change.
>>
>> For example, it is not possible to identify a toplevel panel of a
>> dialog without setting a class on it. On the other hand, setting a
>> class on the toplevel window should suffice for styling each and every
>> element of the dialog separately without any further support from the
>> dialog author. Sure, marking some elements with the intended use (ie
>> marking all buttons in the default layouts with the same class) would
>> make the styling easier but it should not be a requirement.
>> Inheritance (= cascading) might be a nice thing but it is not required
>> when you can selectively apply style to anonymous elements.
>>
>> Powerful selectors make it possible to amend omissions in the layout
>> you style so that you can download a style, apply it, and it just
>> works on the default layout in your distribution even if it styles the
>> layout differently than originally intended.  Relying on support in
>> the layout is error prone and limits style flexibility.
>
> Hi,
>
> I'm not sure what interface you're suggesting. Currently, class
> property is optional, if it's not set, it would use the class name to
> scan for default property, like:
>
> panel {}
> panel { class=menu }
>
> class
> {
>  panel {}
>  menu {}
> }
>

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.

Thanks

Michal