From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with archive (Exim 4.43)
	id 1Mwa25-0000jb-6K
	for mharc-grub-devel@gnu.org; Sat, 10 Oct 2009 07:22:41 -0400
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Mwa23-0000iz-Qg
	for grub-devel@gnu.org; Sat, 10 Oct 2009 07:22:39 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Mwa23-0000iY-4X
	for grub-devel@gnu.org; Sat, 10 Oct 2009 07:22:39 -0400
Received: from [199.232.76.173] (port=50015 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Mwa22-0000iV-QK
	for grub-devel@gnu.org; Sat, 10 Oct 2009 07:22:39 -0400
Received: from fg-out-1718.google.com ([72.14.220.157]:31891)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <hramrach@gmail.com>) id 1Mwa21-0004dU-H9
	for grub-devel@gnu.org; Sat, 10 Oct 2009 07:22:37 -0400
Received: by fg-out-1718.google.com with SMTP id e21so522730fga.12
	for <grub-devel@gnu.org>; Sat, 10 Oct 2009 04:22:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:mime-version:sender:received:in-reply-to
	:references:date:x-google-sender-auth:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=OqsFRXIOyKMtrzwWq/Ywjd/P6b+boIYTr/LVXfB4MuE=;
	b=ajeMhsmjRrlVkIZcuts4IymzFbtuFtrs1liGLHpEOZPdbS3fuVACpblRZmudCE1ZgN
	cg7ngwe3kZUzbImDQLpQxyk5Dk9SzKMqSZjiU3IxN5uUEFXthBtZrYiG5UUbyB2x6rbR
	jzDtw4J4uYsW2C1n/ALik3KNX+N5f6l3Qa2BI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	b=i7VTkAKk1r79R2cXpVt9rl3BFxcNf3d4BpacvHtMzoIiyQgFYz17Jj3TAuE9CqSn4F
	BlsWstRGWn1wTQEci1fyakAorqyzFtPzvzczBXhRybwEurYeIRXcXqBBXc2OaaisX9Jv
	852XgeBmEb6440nA/OUTDZ6g+a7ZnREFRHkBM=
MIME-Version: 1.0
Sender: hramrach@gmail.com
Received: by 10.86.154.32 with SMTP id b32mr3401137fge.10.1255173755946; Sat, 
	10 Oct 2009 04:22:35 -0700 (PDT)
In-Reply-To: <ca0f59980910092043u6cf7568dl37129a7bd58b0c33@mail.gmail.com>
References: <ca0f59980909161355h35df69a8ra32ccc3b4b06a41f@mail.gmail.com>
	<ca0f59980910090754n5dee715cxc6fa90c483ce49bb@mail.gmail.com>
	<a5d587fb0910090857n3c3fe936jb83d2b4549896c3b@mail.gmail.com>
	<ca0f59980910090917l5ad9ddeey23184d4f1f2ecb12@mail.gmail.com>
	<a5d587fb0910090929h31e816fj35766f5b1917b5c6@mail.gmail.com>
	<ca0f59980910090948y7a3a179cjfc165ec49d19b767@mail.gmail.com>
	<a5d587fb0910091027k3744e2e7wd6944b9c10197614@mail.gmail.com>
	<ca0f59980910091132q5df64f9clcbd3f8aa3d709d34@mail.gmail.com>
	<a5d587fb0910091341v1b1f96ddwa4b6262972a16e8e@mail.gmail.com>
	<ca0f59980910092043u6cf7568dl37129a7bd58b0c33@mail.gmail.com>
Date: Sat, 10 Oct 2009 13:22:35 +0200
X-Google-Sender-Auth: 3f28ced5273cfb81
Message-ID: <a5d587fb0910100422p1b6e9d4bh7a8f2de181726b32@mail.gmail.com>
From: Michal Suchanek <hramrach@centrum.cz>
To: The development of GRUB 2 <grub-devel@gnu.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2)
Subject: Re: [GITGRUB] New menu interface (implementation)
X-BeenThere: grub-devel@gnu.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: The development of GRUB 2 <grub-devel@gnu.org>
List-Id: The development of GRUB 2 <grub-devel.gnu.org>
List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/grub-devel>,
	<mailto:grub-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/grub-devel>
List-Post: <mailto:grub-devel@gnu.org>
List-Help: <mailto:grub-devel-request@gnu.org?subject=help>
List-Subscribe: <http://lists.gnu.org/mailman/listinfo/grub-devel>,
	<mailto:grub-devel-request@gnu.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Oct 2009 11:22:40 -0000

2009/10/10 Bean <bean123ch@gmail.com>:
> On Sat, Oct 10, 2009 at 4:41 AM, Michal Suchanek <hramrach@centrum.cz> wr=
ote:
>> 2009/10/9 Bean <bean123ch@gmail.com>:
>>> On Sat, Oct 10, 2009 at 1:27 AM, Michal Suchanek <hramrach@centrum.cz> =
wrote:
>>>> 2009/10/9 Bean <bean123ch@gmail.com>:
>>>>> On Sat, Oct 10, 2009 at 12:29 AM, Michal Suchanek <hramrach@centrum.c=
z> wrote:
>>>>>> 2009/10/9 Bean <bean123ch@gmail.com>:
>>>>>>> On Fri, Oct 9, 2009 at 11:57 PM, Michal Suchanek <hramrach@centrum.=
cz> wrote:
>>>>>>>> I am suggesting an interface that allows style commands like
>>>>>>>>
>>>>>>>> style {
>>>>>>>>
>>>>>>>> (class=3D=3Dbutton).(text=3D=3DOK) { <style> }
>>>>>>>>
>>>>>>>> (class=3D=3Ddialog).<nothing here>.(class=3Dbutton) { <style> }
>>>>>>>>
>>>>>>>> (class=3D=3Dbuttonbar) { direction =3D right_to_left }
>>>>>>>>
>>>>>>>> (class=3D=3Dbutton) {
>>>>>>>> =C3=A1border_top =3D button_top
>>>>>>>> =C3=A1border_left =3D button_left
>>>>>>>> =C3=A1...
>>>>>>>> }
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> for
>>>>>>>>
>>>>>>>> panel { class =3D dialog ; direction =3D top_to_bottom
>>>>>>>> =C3=A1panel {
>>>>>>>> =C3=A1 scroll =3D auto
>>>>>>>> =C3=A1 =C3=A1text { Blah blah blah... }
>>>>>>>> =C3=A1}
>>>>>>>> =C3=A1panel { class =3D buttonbar ;
>>>>>>>> =C3=A1panel { class =3D button ; img { check.png } ;text { OK } ; =
command =3D
>>>>>>>> <something> }
>>>>>>>> =C3=A1panel { class =3D button ; img { cross.png } ;text { Cancel =
} ;
>>>>>>>> command =3D <something>}
>>>>>>>> =C3=A1}
>>>>>>>> }
>>>>>>>>
>>>>>>>> The exact syntax and semantic of the selectors it to be defined.
>>>>>>>>
>>>>>>>> They may be imperative commands that are applied immediately to al=
l
>>>>>>>> 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 loa=
ded
>>>>>>>> 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 defa=
ult
>>>>>>>> (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 th=
at
>>>>>>>> previous style cannot affect the newly loaded style.
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Perhaps it can be written like this:
>>>>>>>
>>>>>>> class {
>>>>>>
>>>>>> perhaps this should be
>>>>>>
>>>>>> style {
>>>>>>
>>>>>>> =C3=A1button.text_OK { <style>}
>>>>>>
>>>>>> text_OK is quite ugly for a selector that specifies that the propert=
y
>>>>>> text should be equal OK.
>>>>>>
>>>>>> What if the text contains a space or underscore or the property
>>>>>> contains underscore?
>>>>>>
>>>>>>> =C3=A1dialog.*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 sore=
ly
>>>>>> missing from CSS}
>>>>>
>>>>> Hi,
>>>>>
>>>>> Do we need to distinguish the situation that exactly one element is i=
n
>>>>> between ?
>>>>>
>>>>>>
>>>>>>> =C3=A1buttonbar { direction =3D right_to_left }
>>>>>>> =C3=A1button { =C3=A1border_top =3D button_top =C3=A1border_left =
=3D button_left }
>>>>>>> }
>>>>>>>
>>>>>>> panel { class =3D dialog ; direction =3D top_to_bottom
>>>>>>> =C3=A1panel {
>>>>>>> =C3=A1 scroll =3D auto
>>>>>>> =C3=A1 =C3=A1text { Blah blah blah... }
>>>>>>> =C3=A1}
>>>>>>> =C3=A1panel { class =3D buttonbar ;
>>>>>>> =C3=A1panel { class =3D button ; img { check.png } ;text { class=3D=
text_OK } ;
>>>>>>> command =3D<something> }
>>>>>>> =C3=A1panel { class =3D button ; img { cross.png } ;text { class=3D=
text_Cancel
>>>>>>> } ; command =3D <something>}
>>>>>>> =C3=A1}
>>>>>>> =C3=A1}
>>>>>>>
>>>>>>
>>>>>> 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
>>>>> {
>>>>> =C3=A1class =3D aa
>>>>> =C3=A1panel {
>>>>> =C3=A1class =3D bb
>>>>> =C3=A1panel {
>>>>> =C3=A1 =C3=A1text { class=3Dcc id=3Dtext1 }
>>>>> =C3=A1}
>>>>> =C3=A1text { id=3Dtext2}
>>>>> }
>>>>>
>>>>> 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 /* =3D **.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:
>>
>> =C2=A0- there is a list of zero or more classes. A class may be either o=
ne
>> that is explicitly specified on a panel or "" (anonymous panel)
>> =C2=A0- 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 ?

I would put it differently: is single level selector enough? Are you
sure you will never want to select an element on which somebody forgot
to put a class?

For me the answer is no. So I am not sure how many levels I need. I am
sure one is insufficient and I doubt a fixed number like two levels
would do.

Note however that you need not check combinations that do not exist in
the style.

The "specificity" rule gives ordering independent of the actual
element matched against the style (with the exception of a.**.b which
may designate a shorter or longer path depending on the actual
element).

Let's ignore the ** issue for now and sort the list of style rules by
specificity.

Let's assume that the style resolver gets a pointer to the element
matched and this element contains the class name, element type, and
parent pointer in its common data.

As a first step you can count the number of parent elements and skip
any style rules that specify too many elements.

Now you create a zeroed structure that contains *all* style properties
that an element can have, and a bitmap which says which are set.

You walk the list of rules (which can have similar structures
attached) and add the properties from the rules. When the structure is
full or there are no more rules you are done.

You can save this structure in the element until style changes.

It would be nice to have this structure extensible but since there are
no bindings for a scripting language there is no point. Any extension
requires recompiling grub anyway. The structure should perhaps include
version (or size or something) if multiple modules use it so that a
module that expects more fields does not write outside of the
structure.

When there are bindings to a scripting language this structure should
be replaced by a hash implemented in the runtime of that language (any
structure of key-value pairs where values are easily retrieved by key
and it is also easily determined if a value for a particular key
exists).

The ** issue can be ignored (=3D the behavior is undefined in that case)
or a special check can be included for this case.

Thanks

Michal