From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MvD0O-0000Q0-7k for mharc-grub-devel@gnu.org; Tue, 06 Oct 2009 12:35:16 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MvD0N-0000PY-DZ for grub-devel@gnu.org; Tue, 06 Oct 2009 12:35:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvD0I-0000NH-N3 for grub-devel@gnu.org; Tue, 06 Oct 2009 12:35:15 -0400 Received: from [199.232.76.173] (port=42026 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvD0I-0000NB-EL for grub-devel@gnu.org; Tue, 06 Oct 2009 12:35:10 -0400 Received: from mail-pz0-f181.google.com ([209.85.222.181]:52561) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MvD0H-0007eZ-PJ for grub-devel@gnu.org; Tue, 06 Oct 2009 12:35:10 -0400 Received: by pzk11 with SMTP id 11so2547555pzk.14 for ; Tue, 06 Oct 2009 09:35:08 -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=cHHzOlCXtsqNRUG3YCWFD9ZX4kir9LeZIZjlPDJFVfg=; b=az3lDOWf0+38wx03w+v1K9KuuOEwkh57sz6AsxNZeu0Wn2sy8JXdMaBw4eNai1yPic +h7rYBv4uIL7lw5aGHvmSOHyoVFDgwzduVbP3lmRTLcoG1jbLlqoMn2ri0g1t4acDxF6 B/f8s8Hmv+K0/JcaBt5NW6CiqZn9gm6Gc/0oA= 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=oZg7eKWK878Cz8xe8l+nRTJIWioef7xE7XOwyBVMESR1mmAQuMf2yWZIkUVd6u70Hp DNRafbN4N7rHQ5TMrrqEHxChn1Q6guFueD2vFmi/bpyvsnmabhmJfMVT0Xyqu2uXmQl3 5w1M4G4KiKK0w2a4Rw3OZzehHbTkNbV3n2pAo= MIME-Version: 1.0 Received: by 10.141.21.12 with SMTP id y12mr259306rvi.248.1254846908528; Tue, 06 Oct 2009 09:35:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Oct 2009 00:35:08 +0800 Message-ID: From: Bean To: The development of GRUB 2 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 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 16:35:15 -0000 On Tue, Oct 6, 2009 at 11:18 PM, Michal Suchanek wrot= e: > 2009/10/6 Bean : >> On Tue, Oct 6, 2009 at 7:46 PM, Michal Suchanek wr= ote: > >>> This is an interesting feature but I was more interested in >>> controlling the border in text mode independently of graphics mode. >>> >>> For example, I would want something like: >>> =A0- graphics: 3px outer space, 2px border, 16px inner space >>> (unfortunately there is no character unit usable because the character >>> size is different when measured horizontally and vertically) >>> =A0- text: single border using the box drawing characters, inner space >>> vertical 1character >>> >>> AFAIK this is not possible. >> >> Hi, >> >> Well, to achieve that, we need some special syntax to allow users to >> skip the border bitmaps optionally in graphic mode, perhaps something >> like this: >> >> top_left =3D "null,,cyan/blue,#0x250F:,,green/blue,#0x2554" > > Is the hex number the number of the box drawing character? > > I would prefer if the border was easier to construct in text mode > without looking up which character goes where. Hi, Perhaps I can add some alias. > > I think there are these common uses for borders: > > - line border in graphics, box drawing char border in text > =A0This is the simplest case which does not require any support media. > =A0This should be well supported so that creating layout that just > works is easy (think fixing grub configuration, posting on pastebin, > etc) Yes, you can archive it with this: top_left =3D ",,cyan/blue,#0x250F:,,green/blue,#0x2554" > > - bitmap border, box drawing char border in text > =A0This seems to be the default currently if bitmap is specified > =A0I wonder what the semantics would be if I had bitmap only for some > borders (ie left, right) Very similar to above, just add the bitmap path as first parameter top_left =3D "/menu/menu_tl.png,,cyan/blue,#0x250F:/menu/select_tl.png,,gre= en/blue,#0x2554" > > - bitmap border, no border in text > =A0This is probably also common use - the bitmap only serves to add > rounded corners or something like that. No need to replicate in text > although some special characters might fit in some cases. If the fill character is not set, it won't displayed in text mode: top_left =3D "/menu/menu_tl.png:/menu/select_tl.png" > > Adding a flat border can be done with an additional panel if desired > and is probably not common, no need for special support. > >> >>>> valign, halign: >>>> Now align property control the position of current widget, instead of >>>> its children, each have four values: >>>> left/top >>>> center >>>> right/bottom >>>> extend - Extend the widget to the full width/height of parent. >>>> >>>> margin_left, margin_right, margin_top, margin_bottom >>>> This properties set the inner space reserved by the panel >>>> >>>> padding_left, padding_right, padding_top, padding_bottom >>>> This set the outbound box of the panel >>>> >>>> attach_left, attach_right, attach_top, attach_bottom >>>> Stick the widget to one of the border of parent, once this is set, the >>>> widget is no longed controlled by the layout manager and therefore can >>>> overlap with other widget. >>>> >>> >>> This sucks. Since overlap is not properly handled it should not happen. >>> >>> I am not sure what is the use of this property anyway. >> >> This can be used to implement the auto hide toolbar. We can use a >> hotkey to show/hide the bar. In this case, we definitely don't want to >> add the widget to the layout manger otherwise all widgets on screen >> would need to be resized after the show/hide operation. >> > > It could be used like that if we had the ability to show/hide > individual widgets. > > I know concealable toolbars are cool but do we really need them for grub? > > They are cheap in a desktop environment where the windowing system is > already present and you just write an application that hides/resizes > its window. > > In grub we would have to add and maintain/support features just to > support a concealable toolbar. > > And what would be the use? > > grub is not a windowing environment in which you stay for a prolonged > period of time. You just boot your system and are done with it. > > Admittedly, concealable toolbars are somewhat useful to hold tools > which you need occasionally but which would occupy precious screen > space while you are working on something else. This is not the case in > grub, though. > > All tools that are at your disposal should be clearly visible and you > don't really need to put the effort into hiding them because it should > take about the same effort to boot your system and exit grub > completely, including its toolbars. It can also be used to placed small widgets, like a digital clock at the upper left corner, I guess it won't look pretty if all window have to align leftward and downward to show it (and a lot of extra panels). Anyway, it's not much code for the attach_* properties, I guess it doesn't hurt to leave it there in case we find new use for them in the future. --=20 Bean gitgrub home: http://github.com/grub/grub/ my fork page: http://github.com/bean123/grub/