Re: [GITGRUB] New menu interface (implementation)

[Bean]

On Sat, Oct 10, 2009 at 2:28 AM, address@hidden
<address@hidden> wrote:
> On Fri, Oct 9, 2009 at 12:09 PM, Michal Suchanek <address@hidden> wrote:
>> 2009/10/9 address@hidden <address@hidden>:
>>>> I am suggesting an interface that allows style commands like
>>>>
>>>> style {
>>>>
>>>> (class==button).(text==OK) { <style> }
>>>>
>>>> (class==dialog).<nothing here>.(class=button) { <style> }
>>>>
>>>> (class==buttonbar) { direction = right_to_left }
>>>>
>>>> (class==button) {
>>>>  border_top = button_top
>>>>  border_left = button_left
>>>>  ...
>>>> }
>>>>
>>>> }
>>>
>>> I don't like this.  It's a unit testing nightmare. Matter of fact, so
>>> is auto-layout.  I don't want my bootloader to be a web browser.  I
>>> want it to be reliable and load fast.
>>>
>>> At the very least, please keep the actual boot sequencing (the stuff
>>> equivalent to menu.lst of grub-0.97) separate and let the GUI stuff
>>> incorporate them by reference.  Then provide a hotkey (e.g. hold 'R'
>>> during boot) to skip all GUI (and I mean skip everything configurable,
>>> not just text vs graphics) and provide a simple selection with no
>>> nesting, no icons, no borders, no fonts, no colors, no multiple lists,
>>> just everything in one big scrollable list, with access to the command
>>> line.
>>
>> The thing is that people *demand* that things are configurable, and
>> for grub legacy poorly written (possibly because grub-legacy was hard
>> to extend) patches for that were created which were not incorporated
>> into the mainline grub-legacy.
>>
>> So the choice here is to support configurable menu (and try to strip
>> features as much as possible to keep the complexity reasonable while
>> still maintain reasonable flexibility) or accept that several ad-hoc
>> graphics menu implementations will eventually emerge on the net.
>
> Or you can stop trying to solve all the world's problems (and getting
> an equivalent number of bugs), and design something that lends itself
> to extension.
>
> You've already got modules.  I think that if you provide the following
> few functions, people will make mutually compatible extensions that
> could then be merged into the main tree as desired:
>
> Some data structure for holding the boot sequence commands, like grub
> legacy's menu.lst but without the look-and-feel stuff.
> Enumeration of available boot sequences (and possibly bootable media
> not listed in the user's configuration).
> A function for executing a particular boot sequence by id-string.
>
> A function for printing text in text-mode.
>
> A class for holding a screen-buffer. (readable attributes such as
> width and height)
> A function for presenting the screen-buffer, and returning after a key
> is pressed or timeout (or possibly if bootable media is inserted).
> A function for filling a rectangular subregion with a specific color.
> A function for drawing a box (flags for which sides to draw, color of
> sides, and single-or-double line, and raster-combining op such as XOR
> to help with highlighting selected items).
> A function for drawing a bitmap.
> A function for drawing a string (specify color).
>
> A function for obtaining the user's stored GUI configuration (content
> is specific to the extension).
> And a global setting that specifies which GUI extension is to be loaded.
>
> You can provide a couple prebuilt extensions such as simple scrolling
> text list selectable with arrow keys ala grub-legacy (no GUI
> configuration) and a fancier one more like rEFIt with one horizontal
> list of kernel icons above and a set of tools below (GUI configuration
> is the set of items to place in the toolbar, all others go in the
> kernel list).  These are small enough in scope to get right and cover
> completely with tests.
>
> Yes, fancier menus will emerge out on the net.  Yes, they'll be
> incompatible and have some duplication of effort in terms of
> auto-layout.  But every one of the auto-layout routines will be far
> simpler, because it doesn't have to let the user choose how to divide
> space, etc.  Each only has to accommodate more items in the
> already-defined layout.  Plus, users can always fallback to a good
> version and recovery from a messed-up GUI configuration will be made
> easier.
>
> And, you can work on an extension which is the infinitely-flexible
> pseudo-CSS pseudo-HTML autolayout engine you're already started on.
> But I'm suspicious that it'll never be finished because the scope is
> so large.

Hi,

Actually the menu system is split into different modules, you can use
it to build your own ui:

region:
low level drawing api, use to construct ui that work in both text and
graphic mode

config loader:
loads tree structure config file

widget:
widget infrastructure function

ui component:
widgets

Users can extend ui by writing new widget, some of the complex task
like layout manager is already handled by the widget manager.

-- 
Bean

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