Re: [GITGRUB] New menu interface (implementation)

[address@hidden]

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.