On Sat, Oct 10, 2009 at 4:41 AM, Michal Suchanek <hramr...@centrum.cz> wrote:
> 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).
Hi,
To support full path, except the last element, each element can appear
or not independent of others, for N level, this is 2^(N-1), for
example, four class aa, bb, cc, dd, we need to scan:
aa.bb.cc.dd
aa.bb.dd
aa.cc.dd
aa.dd
bb.cc.dd
bb.dd
cc.dd
dd
This is for every property. For every widget, the layout manger would
read at least margin_*, padding_*, attach_*, width, height, that's 16
property, widget like panel would need to read border_*, left/top/.. ,
an extra of 15 property, the number can go out of control rapidly.
Anyway, how often do we need patterns like aa.bb.cc.dd ?
--
Bean
gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
