Re: [GITGRUB] New menu interface (implementation)

[Michal Suchanek]

2009/10/9 address@hidden <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.

What do you mean by:

- boot seqence

- bootable media

- structure for holding boot sequence commands

I suspect you can think of the new (and old) menu configuration as a
structure to hold boot sequence commands if by boot sequence you mean
something like:
  linux /boot/vmlinuz root=/dev/sda1 ro
  initrd /boot/initrd.gz

In the new menu configuration the style which specifies how this is
drawn can be separate form the menu configuration.

>
> 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).

We already have these functions in video subsystem.

Just having them does not make a nice menu magically appear on your
screen. That's what the new menu system is about.

>
> 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.

We need a gui extension that actually works, even if it is the old
console menu or gfxterm. They still do have configuration and layout
that have to work reasonably for them to be usable but they are not
customizable at all. This causes problems. For example the key
bindings that include the Ctrl modifier do not work on Apple EFI and
grub itself has to be patched to change these, they cannot be set in a
configuration file.

>
> 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.

Why should we bother?

gfxterm is there but people complain it's too limited and even the
rEFIt author acknowledges the UI is too limited and inflexible so we
need something more general than that.

>
> 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

There is no need for numerous extensions if the menu system in grub
can do what most people want.

> 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

Why so?

You either manage screen space or your menu overflows on one edge when
you have too many (or too long) items.

> already-defined layout.  Plus, users can always fallback to a good
> version and recovery from a messed-up GUI configuration will be made
> easier.

Why should fallback in a more general system be difficult? You still
have the command line and you can store and use multiple
configurations, that's not going to change.

>
> 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.

There are numerous toolkits far more complex than this, and they are
finished and working.

I am also actively trying to keep this one as simple as possible.

Thanks

Michal