Re: [GITGRUB] New menu interface (implementation)

[Bean]

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 {}
}

-- 
Bean

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