Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

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.

Note also that on non-i386 platforms there is often no VGA text
console so graphics is the only way to display any menu at all, and
you have to deal with fonts and colors then.

For now you can choose to load the old gfxterm (and it is the only
working graphics option now) but I expect that when the new menu
system is considered stable gfxterm will be deprecated.

Thanks

Michal