Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

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.


Thanks

Michal