grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Converting Ubuntu CDs to GRUB


From: Colin Watson
Subject: Re: Converting Ubuntu CDs to GRUB
Date: Thu, 20 May 2010 19:43:36 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Thu, May 20, 2010 at 11:13:02AM -0700, Colin D Bennett wrote:
> On Thu, 20 May 2010 18:35:54 +0100
> Colin Watson <address@hidden> wrote:
> > I've written up a brief description of our needs here:
> > 
> >   https://wiki.ubuntu.com/FoundationsTeam/Specs/MaverickCDBoot
> > 
> > I think that the extensions we'd need in gfxmenu amount to:
> > 
> >   * Supplementary menu support, with menus bound to keys
> 
> How do you envision these supplementary menus?  Are they pop-up menus
> spatially separate from the main boot menu?

Yes - e.g. the function-key menus across the bottom in your
http://grub.gibibit.com/Theme_ubuntu1_menu.jpg (which I notice are just
stubs in the theme right now).

> >    * Either scrolling menus or grid menus, preferably grid
> 
> Would this grid be a grid of boot menu entries, like the rEFIt screen
> shot I linked to above?

No, I'm thinking of a menu offering the ability to select the user's
language.  The list of languages will be too long to fit vertically on
the screen; in gfxboot, rendering that list as a pop-up grid menu has
worked well for us.

> >   * The ability to bind functions to menus to process selections
> 
> Currently menu items each run the code defined by the GRUB 'menuitem'
> command.  Would you want something different to happen that can't be
> implemented this way?

That's for main boot menu items.  I wouldn't expect this would be right
for secondary pop-up menus.  For something like language selection, I
don't think you'd want to write a menuentry stanza for each one;
instead, you'd want a single function that's called with the menu
selection as an argument, and it wouldn't implicitly terminate by
booting a kernel.

(I get the sense I may have skipped a few steps in my explanation of
what I'm trying to achieve.  Let me know if you want me to back up.)

> >   * Checkbox widgets
> 
> Should checkbox widgets be able to be part of a menu?  How should
> checkboxes by selected/deselected?  By navigating to them and pressing
> Enter, or via a dedicated hotkey?

I'm thinking of something like:

 /-----------------\
 | [x] Expert mode |
 | [ ] acpi=off    |
 | [x] noapic      |
 \-----------------/
  F6 Other Options

In gfxboot, I used Space or Enter to toggle a checkbox and Escape to
dismiss the menu.  I'm not sure this is ideal.

> > Needless to say I'm willing to take on the bulk of the work here, but
> > I'm very new to gfxmenu and I would greatly appreciate review from
> > those who've spent more time thinking about it and hacking on it.  In
> > particular, I'd appreciate thoughts on how this kind of thing might
> > best be represented in extensions to the theme format.
> 
> There are different possible approaches to setting up special menus.
> One possibility is to create the various menus/menu items in grub.cfg
> and then simply have the theme set up the menu widget which will then
> use the menu data defined in grub.cfg to create/navigate the menu tree.

I was thinking that grub.cfg should define the actions bound to menu
items, but that the theme should declare the menus themselves.

> Another possibility is to explicitly instantiate widgets in the theme
> for specific purposes.  For instance, you could create checkbox widgets
> and somehow associate each one with a GRUB environment variable name,
> which would be set according to the checkbox state.

In the case I have in mind, I'd want to be able to aggregate the whole
lot into a single variable because the end goal is to substitute them
into the kernel command line.  That was one reason I was thinking of a
function: it could be given the list of internal values corresponding to
checked boxes, and concatenate them into a single variable.  (Or
something similar with a single environment variable hook for all the
checkboxes in a menu at once would work too.)

> The language chooser could be implemented as a special widget, or
> perhaps a better option would be to create a generic "choice" widget
> which gets its list of possible choices from a file included by
> grub.cfg and sets a GRUB environment variable when the selected value
> is changed.  (Note that environment variables can then have a "hook"
> defined to take some action when the value is changed.)

I'd forgotten about environment variable hooks.  That does seem like a
nice way to do things, yes - it would save having to have a new binding
mechanism.

> How could GRUB script code define option names/values for a choice
> box?  The issue is that you normally want some internal value for
> each choice and a label to display to the user for the choice.  It
> seems kind of a kludge but if you had a choice box given the name
> "language" then it might get its possible choices from an environment
> variable called "language_options", defined in grub.cfg (or more likely
> in a file included in grub.cfg) something like
> 
> set language_options="en English
> de Deutsch 
> fr Francais"
> 
> and so on.  It would be nice if we could avoid using magic text
> characters like space and newline but since GRUB script doesn't have
> good data structures, it's simplest to use plain text, unless I'm
> missing something.  (Lua makes defining and using such data structures
> fantastically easy...)

Choices often need to be translated, and in this context we'll need to
be able to change the language at run-time: so the easy way to handle
internal vs. human-readable choices (which I agree we need) is to regard
English as just another translation, and then handle the whole thing via
gettext.  Then language_options or whatever can just be space-separated.

(Although the language_options choices always need to be displayed in
the language corresponding to each choice, of course, so I suppose there
would only be one "translation" there.  You have this right above, but
the way I sometimes explain this to Anglophones who haven't thought
about the problem is to ask them whether they'd recognise "英语" if they
saw it in a menu ...)

> Another thought:  I think it would be really fantastic to do some of the
> more complex widget work in Lua.  I have created some test widgets that
> are written 100% in Lua and do animation, etc.  It makes it much easier
> to do things like manipulating lists, and creating widgets with
> customized behavior.

I'm not opposed to Lua, but have no experience with it in GRUB, and I'm
conscious that it's not enabled in the Debian package right now and so
I'd sort of be reversing a decision made by Robert and Felix in their
absence, which niggles at me.  If it really makes things very much
easier, I wouldn't mind using it for this; if possible I would prefer
not to design in a way that actually requires it, though?

Thanks,

-- 
Colin Watson                                       address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]