On 20 May 2010 20:43, Colin Watson <cjwat...@ubuntu.com> wrote: > 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 <cjwat...@ubuntu.com> 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). >
IMHO there should be a possiblility to bind actions (= scripts) with descriptions to keys, and a possibility to print this list of actions somewhere on-screen, automatically. I mean when somebody adds a custom keybinding it would automatically appear in the list of keybindings because it would be automatically generated from the actual grub state, not manually drawn in Gimp. >> > * 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. I guess a scrolling menu is probably easier and can be the same as the kernel menu and just about any other menu the user already knows. Do all the languages available fit on the screen? Is this scalable to all world languages? A scrollable menu with PgUp/PgDn which allows skimming a page of language names at a time seems easier to me, both the implemenataion and the usability. Skimming through a table quickly is not that easy. If the number of languages is really large you could split them by continent similar to what Debian doses with location/timezone in their installer. > >> > * 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. Yes, the implicit termination is a problem. That could be configurable per menu if we had multiple menus I guess. Otherwise I don't see why the menu items for languages cannot be autogenerated by a script. A specialized selection would save some config size, though. > > (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. This is probably the expected way. Ideally it should be customizable as should be all the keybindings so that people with odd input devices can still use grub with proper configuraion. While a specialized radio button would be nice they can be also scripted as generic items so long as the menu is sufficiently configurable from insisde grub I guess. > >> > 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. You can't easily have manu items without menus, especially if you want to split them into multiple separate menus. I would think that a menu should be a list of items ( currently we have an implicit menu which implicitly gets all items defined with menuitem). Also the menus should be included in some layout which specifies the help texts and such, drawing the help texts in Gimp is not quite optimal. It should be possible to switch between multiple layouts because there is no way how you could fit all installer menus in a single layout. I find a stack of layouts quite appealing as when the user enters some submenu (like select language or select extra boot options) and later leaves it the previous menu will get displayed automatically because it was "below" the submenu. > >> 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.) I don't think that something of this complexity can be easily solved with a specialized checkbox widget. You should probably create an item with associated script which takes care of integrating the state of the option into the kernel parameters. The item in question could possibly change appearance on its own and the associated script would just check its state and act accordingly. > 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. Handling translations is somewhat problematic at this point and I have no idea how it would be done except by basically rebuilding the menu each time it is translated. Perhaps as a first iteration you could just define the menus in the different languages and switch to a different menu when the language changes. Also gettext is not really the way to translate things. It is based on taking an arbitrary English string (or a number correstponding to such string) and looking up a corresponding string in a different language. The problem is that while English has singular and plural some languages have more than that. It's similar for English ordianals, there are more than two forms - 1st, 2nd, 3rd, 4th .. And there are other issues of stuff not mapping from English to other languages nicely. It should work for whole menu items and help texts but may not for printf format strings and such. > > (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 ...) Yes, the first character looks familiar. I have not encountered the second one when trying to search for readable translation in Asian programs, it's usually something like 英語 or 英文 but I am not an expert. > >> 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? > Lua is not going to be the official scripting language for Grub due to copyright reasons and proabaly also due to maintainers not really liking the language. I have no idea if or when there would be a replacement. That does not mean you cannot enable it in your packages and use it for the more advanced scripting. It would make things quite a bit easier I imagine as the grub shell scripting is modelled after Bourne shell scripting and comes with all the shortcoming this has for handling data structures more complex than scalars or strings. Thanks Michal _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
