On Tue, Oct 6, 2009 at 11:18 PM, Michal Suchanek <hramr...@centrum.cz> wrote: > 2009/10/6 Bean <bean12...@gmail.com>: >> On Tue, Oct 6, 2009 at 7:46 PM, Michal Suchanek <hramr...@centrum.cz> wrote: > >>> 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: >>> - 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) >>> - 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 = "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 > This is the simplest case which does not require any support media. > This 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 = ",,cyan/blue,#0x250F:,,green/blue,#0x2554" > > - bitmap border, box drawing char border in text > This seems to be the default currently if bitmap is specified > I 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 = "/menu/menu_tl.png,,cyan/blue,#0x250F:/menu/select_tl.png,,green/blue,#0x2554" > > - bitmap border, no border in text > This 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 = "/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. -- Bean gitgrub home: http://github.com/grub/grub/ my fork page: http://github.com/bean123/grub/ _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
