From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with archive (Exim 4.43)
	id 1MwJG4-0000v3-OE
	for mharc-grub-devel@gnu.org; Fri, 09 Oct 2009 13:28:00 -0400
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MwJG2-0000tW-OZ
	for grub-devel@gnu.org; Fri, 09 Oct 2009 13:27:58 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MwJFx-0000ox-55
	for grub-devel@gnu.org; Fri, 09 Oct 2009 13:27:57 -0400
Received: from [199.232.76.173] (port=51035 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MwJFx-0000ou-1S
	for grub-devel@gnu.org; Fri, 09 Oct 2009 13:27:53 -0400
Received: from mail-fx0-f205.google.com ([209.85.220.205]:38471)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <hramrach@gmail.com>) id 1MwJFw-0005RW-HT
	for grub-devel@gnu.org; Fri, 09 Oct 2009 13:27:52 -0400
Received: by fxm1 with SMTP id 1so6099186fxm.31
	for <grub-devel@gnu.org>; Fri, 09 Oct 2009 10:27:51 -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=PvGfJ8Y2Bzr07KYlhcs4lBHH6KfNi3Y/XKfkyoZl3uc=;
	b=HVXaVTpDBkKsqCLxCuQTLs4ziJcbmLsKBAb1BDHuojBu7VaZqUWBFKZ1pIAp31/Spr
	x0DyuLAMPLznohg7HP2I/5pPJ+XVRaRjD8E6snb+5G5wFAjDlAJbT/9earRhtFuFDmtg
	3UjJ8XkPW2AdwbT6rFbx4c5PDrla27RUIE7a8=
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=OyPByzbi7lndww4fqzCK3BVg1O7oZUA1PgLkmOCCeNVeXDhtO+PGAZcFK++rlmBZ8u
	x8AApqBtOErG5jS+swcY1WrjfPIU7W4HtaQGxehijVTuICGc0V2CFrS+dX5F7URza9Z8
	5iH45tgAFUdvTGnirtAjjhq9u8hfm4wl+2PM8=
MIME-Version: 1.0
Sender: hramrach@gmail.com
Received: by 10.86.240.9 with SMTP id n9mr2649637fgh.70.1255109271490; Fri, 09 
	Oct 2009 10:27:51 -0700 (PDT)
In-Reply-To: <ca0f59980910090948y7a3a179cjfc165ec49d19b767@mail.gmail.com>
References: <ca0f59980909161355h35df69a8ra32ccc3b4b06a41f@mail.gmail.com>
	<ca0f59980910082045y5d955d28j7b0088bc23b119a1@mail.gmail.com>
	<a5d587fb0910090452s436070bamae9da3f8afdbcf3b@mail.gmail.com>
	<ca0f59980910090548o16dd337cjf6b50212fa1e36e@mail.gmail.com>
	<a5d587fb0910090720p51839490j69145593a02e55d2@mail.gmail.com>
	<ca0f59980910090754n5dee715cxc6fa90c483ce49bb@mail.gmail.com>
	<a5d587fb0910090857n3c3fe936jb83d2b4549896c3b@mail.gmail.com>
	<ca0f59980910090917l5ad9ddeey23184d4f1f2ecb12@mail.gmail.com>
	<a5d587fb0910090929h31e816fj35766f5b1917b5c6@mail.gmail.com>
	<ca0f59980910090948y7a3a179cjfc165ec49d19b767@mail.gmail.com>
Date: Fri, 9 Oct 2009 19:27:51 +0200
X-Google-Sender-Auth: aa3ec51d2d5b9f8a
Message-ID: <a5d587fb0910091027k3744e2e7wd6944b9c10197614@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: Fri, 09 Oct 2009 17:27:59 -0000

2009/10/9 Bean <bean123ch@gmail.com>:
> On Sat, Oct 10, 2009 at 12:29 AM, Michal Suchanek <hramrach@centrum.cz> w=
rote:
>> 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) {
>>>> =C2=A0border_top =3D button_top
>>>> =C2=A0border_left =3D button_left
>>>> =C2=A0...
>>>> }
>>>>
>>>> }
>>>>
>>>> for
>>>>
>>>> panel { class =3D dialog ; direction =3D top_to_bottom
>>>> =C2=A0panel {
>>>> =C2=A0 scroll =3D auto
>>>> =C2=A0 =C2=A0text { Blah blah blah... }
>>>> =C2=A0}
>>>> =C2=A0panel { class =3D buttonbar ;
>>>> =C2=A0panel { class =3D button ; img { check.png } ;text { OK } ; comm=
and =3D
>>>> <something> }
>>>> =C2=A0panel { class =3D button ; img { cross.png } ;text { Cancel } ;
>>>> command =3D <something>}
>>>> =C2=A0}
>>>> }
>>>>
>>>> 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 {
>>
>>> =C2=A0button.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?
>>
>>> =C2=A0dialog.*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 ?
>
>>
>>> =C2=A0buttonbar { direction =3D right_to_left }
>>> =C2=A0button { =C2=A0border_top =3D button_top =C2=A0border_left =3D bu=
tton_left }
>>> }
>>>
>>> panel { class =3D dialog ; direction =3D top_to_bottom
>>> =C2=A0panel {
>>> =C2=A0 scroll =3D auto
>>> =C2=A0 =C2=A0text { Blah blah blah... }
>>> =C2=A0}
>>> =C2=A0panel { class =3D buttonbar ;
>>> =C2=A0panel { class =3D button ; img { check.png } ;text { class=3Dtext=
_OK } ;
>>> command =3D<something> }
>>> =C2=A0panel { class =3D button ; img { cross.png } ;text { class=3Dtext=
_Cancel
>>> } ; command =3D <something>}
>>> =C2=A0}
>>> =C2=A0}
>>>
>>
>> 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
> {
> =C2=A0class =3D aa
> =C2=A0panel {
> =C2=A0class =3D bb
> =C2=A0panel {
> =C2=A0 =C2=A0text { class=3Dcc id=3Dtext1 }
> =C2=A0}
> =C2=A0text { 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.

Thanks

Michal