2009/10/9 Bean <bean12...@gmail.com>:
> On Sat, Oct 10, 2009 at 1:27 AM, Michal Suchanek <hramr...@centrum.cz> wrote:
>> 2009/10/9 Bean <bean12...@gmail.com>:
>>> On Sat, Oct 10, 2009 at 12:29 AM, Michal Suchanek <hramr...@centrum.cz>
>>> wrote:
>>>> 2009/10/9 Bean <bean12...@gmail.com>:
>>>>> On Fri, Oct 9, 2009 at 11:57 PM, Michal Suchanek <hramr...@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.
>
> Hi,
>
> Currently, the menu system don't store class property in widget, this
> make it easier to change theme, we just reload the class tree and
> reinit the screen. It checks local properties first, if not found,
> check the class tree for default value, so the scan order should be
> reversed, it quits as soon as one match is found.
>
> For starters, we can just implement two level pattern parent*class, as
> each property would need to scan the tree for matches, deep level
> would mean a lot of iteration and could have a impact on performance.
I don't think this is too much of a problem. How deep a typical layout
will be? Ten levels? Do ten pointer dereferences slow down grub? There
are components in the current system that are much slower (ie fonts
and drawing) so we should not really care.
Even if this becomes problem in the future given a reasonable
interface to the style resolver the matching can be optimized later.
It seems that the paths are in fact very simple:
- there is a list of zero or more classes. A class may be either one
that is explicitly specified on a panel or "" (anonymous panel)
- at the end there is an element type (panel, edit, text, image, ...)
and an optional class
So the interface to the style resolver should accept this list of
classes in some form and information on the final element and the
resolver should return back the properties it knows about for this
path (return a structure holding these or set them directly on the
final element if passed to it or something).
Thanks
Michal
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
