From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MvEyE-0005Oc-M8 for mharc-grub-devel@gnu.org; Tue, 06 Oct 2009 14:41:10 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MvEyD-0005Mq-Gq for grub-devel@gnu.org; Tue, 06 Oct 2009 14:41:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvEyC-0005Ly-LE for grub-devel@gnu.org; Tue, 06 Oct 2009 14:41:09 -0400 Received: from [199.232.76.173] (port=53556 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvEyC-0005Lj-FM for grub-devel@gnu.org; Tue, 06 Oct 2009 14:41:08 -0400 Received: from fg-out-1718.google.com ([72.14.220.153]:38119) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MvEyB-0008NL-Jj for grub-devel@gnu.org; Tue, 06 Oct 2009 14:41:08 -0400 Received: by fg-out-1718.google.com with SMTP id e21so895757fga.12 for ; Tue, 06 Oct 2009 11:41:06 -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=IcUljh6GiJNMp4smjXnR63+tJ2W0N995lWwdtwBfWzo=; b=wV2kgSteNlmYFeHkWHwN0xB6lKichtiCwbCv4NiBqFCqSUDlPK1SiwG5fW2jImXRMB BYe+wuviO8A+j3pIjj0LMldGRLeJW+lo3U3LGYAsFBxUahoKf99AljVS2W17gxwznDLM n5b62cGrIY8qUw+E56EeV5O6XwpBYK1w6eIkc= 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=XMwR/NRIQmsMSmp875fSN//mxSU2d6LeoLTCWft/uRW6r9TFXtMaIFwTCHuEtlXrSI sl4fzy4nwZDxusz0dvJ8pst1dJxu0+ZvJbMEpo2jrngT1c9TA+2oAaWXFKpk2Xnunh8Z 6eMwMC75QyGF/YNXqzxpWI87QKSLQdYOFAFtE= MIME-Version: 1.0 Sender: hramrach@gmail.com Received: by 10.86.181.6 with SMTP id d6mr852984fgf.29.1254854466697; Tue, 06 Oct 2009 11:41:06 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Oct 2009 20:41:06 +0200 X-Google-Sender-Auth: 79d3dda17296f133 Message-ID: From: Michal Suchanek To: The development of GRUB 2 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 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 18:41:09 -0000 2009/10/6 Bean : > On Tue, Oct 6, 2009 at 11:18 PM, Michal Suchanek wr= ote: >> 2009/10/6 Bean : >>> On Tue, Oct 6, 2009 at 7:46 PM, Michal Suchanek w= rote: >> >>>> 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: >>>> =C2=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) >>>> =C2=A0- text: single border using the box drawing characters, inner sp= ace >>>> 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 >> =C2=A0This is the simplest case which does not require any support media= . >> =C2=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 >> =C2=A0This seems to be the default currently if bitmap is specified >> =C2=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,,g= reen/blue,#0x2554" > >> >> - bitmap border, no border in text >> =C2=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, th= e >>>>> widget is no longed controlled by the layout manager and therefore ca= n >>>>> 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). They have to be aligned leftwards or downwards, not both. It also won't look pretty if the clock gets sometimes obscured by other pan= els. However, the screen is not a panel so it might not force any particular layout and placing a clock like that might be viable. Still you have to take care not to overlap it with other panels and leave space for it so I see little use for such placement, you can as well put the clock in a ltr or ttb layout which automatically reserves space for it. Note also that the clock will likely be in UTC unless you replicate system TZ data and settings in grub. > 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. It's additional code that might have bugs, the more if it is seldom used. And it can cause bugs by its sole existence because then users of the code can cause panels to overlap and complain that stuff broke. Thanks Michal