From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with archive (Exim 4.43)
	id 1MwIeI-00084s-5D
	for mharc-grub-devel@gnu.org; Fri, 09 Oct 2009 12:48:58 -0400
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MwIeG-00083K-CM
	for grub-devel@gnu.org; Fri, 09 Oct 2009 12:48:56 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MwIeB-0007xq-E2
	for grub-devel@gnu.org; Fri, 09 Oct 2009 12:48:55 -0400
Received: from [199.232.76.173] (port=56611 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MwIeB-0007xT-6z
	for grub-devel@gnu.org; Fri, 09 Oct 2009 12:48:51 -0400
Received: from mail-pz0-f181.google.com ([209.85.222.181]:44683)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <bean123ch@gmail.com>) id 1MwIeA-00080W-Mg
	for grub-devel@gnu.org; Fri, 09 Oct 2009 12:48:50 -0400
Received: by pzk11 with SMTP id 11so5269938pzk.14
	for <grub-devel@gnu.org>; Fri, 09 Oct 2009 09:48:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:mime-version:received:in-reply-to:references
	:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=sdzjjBU1nImDJK8winbPtC0FKVBu9WsNkFgp07jfz6o=;
	b=eQ4EjbTPkxBfC4i8XtG5xXThAj1GNhCpZBeSap6A4244tUhe4u6TyKo3V/EksWDGOm
	dyr8iWJAG8Zw+nsXlwUAhKoRvwhWtADTgHd5tCMmt+YsSUJqm8zroxBR/5DsRWy1GoB+
	6XY/Omj35MDEIWP9GSjuBP0EQFpRxn+lZyv3s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	b=Nw4hDZUmVttKdMqBnc3nl3pyJee0Lwqt3uZ07SthSPQ8YCMyRb+tgydI6oZhPhm0+s
	J9oFkTYa2LM65rBuF6W2FmJYsvW4qMcnMUvP0YhJLTE+2tOjMoNZDDzYkiwqyJc1KoKE
	ESO/wfPOGNtUzD2hiLlAl3WXLwWZSLiEp4V0Y=
MIME-Version: 1.0
Received: by 10.140.169.19 with SMTP id r19mr268103rve.235.1255106929887; Fri, 
	09 Oct 2009 09:48:49 -0700 (PDT)
In-Reply-To: <a5d587fb0910090929h31e816fj35766f5b1917b5c6@mail.gmail.com>
References: <ca0f59980909161355h35df69a8ra32ccc3b4b06a41f@mail.gmail.com>
	<a5d587fb0910081434s17144c62p258e1aa5cb1b06ee@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>
Date: Sat, 10 Oct 2009 00:48:49 +0800
Message-ID: <ca0f59980910090948y7a3a179cjfc165ec49d19b767@mail.gmail.com>
From: Bean <bean123ch@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Content-Type: text/plain; charset=ISO-8859-1
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 16:48:56 -0000

On Sat, Oct 10, 2009 at 12:29 AM, Michal Suchanek <hramrach@centrum.cz> wro=
te:
> 2009/10/9 Bean <bean123ch@gmail.com>:
>> On Fri, Oct 9, 2009 at 11:57 PM, Michal Suchanek <hramrach@centrum.cz> w=
rote:
>>> 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) {
>>> =A0border_top =3D button_top
>>> =A0border_left =3D button_left
>>> =A0...
>>> }
>>>
>>> }
>>>
>>> for
>>>
>>> panel { class =3D dialog ; direction =3D top_to_bottom
>>> =A0panel {
>>> =A0 scroll =3D auto
>>> =A0 =A0text { Blah blah blah... }
>>> =A0}
>>> =A0panel { class =3D buttonbar ;
>>> =A0panel { class =3D button ; img { check.png } ;text { OK } ; command =
=3D
>>> <something> }
>>> =A0panel { class =3D button ; img { cross.png } ;text { Cancel } ;
>>> command =3D <something>}
>>> =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 {
>
>> =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?
>
>> =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 ?

>
>> =A0buttonbar { direction =3D right_to_left }
>> =A0button { =A0border_top =3D button_top =A0border_left =3D button_left =
}
>> }
>>
>> panel { class =3D dialog ; direction =3D top_to_bottom
>> =A0panel {
>> =A0 scroll =3D auto
>> =A0 =A0text { Blah blah blah... }
>> =A0}
>> =A0panel { class =3D buttonbar ;
>> =A0panel { class =3D button ; img { check.png } ;text { class=3Dtext_OK =
} ;
>> command =3D<something> }
>> =A0panel { class =3D button ; img { cross.png } ;text { class=3Dtext_Can=
cel
>> } ; command =3D <something>}
>> =A0}
>> =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
{
  class =3D aa
  panel {
  class =3D bb
  panel {
    text { class=3Dcc id=3Dtext1 }
  }
  text { id=3Dtext2}
}

We scan the following section in order:

text1:
bb.cc
bb.**.cc:
aa.*.cc
aa.**.cc
cc

text2:
aa.text
aa.**.text
text


--=20
Bean

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