GRUB menu proof of concept demo - very rough draft as implemented in Java applet demo
This project will add an attractive GUI menu system to GRUB 2. It will be customizable and will include support for animation and other graphical effects.
By adding an attractive graphical interface with eye-candy, many users (especially casual users) will be attracted to GRUB 2, which will help to enhance the superiority of GRUB among bootloaders and also will drive users of GRUB legacy (0.9x) to upgrade to GRUB 2.
Implementing a true graphical menu for GRUB will also open the door to mouse support, which I would like to work on after this Summer of Code graphical menu is completed.
A graphical menu allowing users to select the operating system to boot. The graphical interface must feel highly responsive and not be sluggish to react to keyboard events. The graphical menu will use the same menu item data and other configuration data that the text mode menu uses; it will simply be presented in a different user interface.
The appearance of the menu would be customizable through some "CSS-like" style sheet that defines the colors, fonts, sizes, and what effects should be used. Possible effects could include transitions such as the GRUB screen fading in when it starts and fading out when an operating system is booted, among other transition effects. A graphical progress bar will be included displaying the timeout remaining until the default choice is selected.
The graphical menu implementation will build on the existing GRUB Video API. The menu will use Unicode to support international characters. If it makes sense, the GRUB Video API may be extended or modified during the course of this project.
Code will be compatible with the GPLv3 license, and copyright of the produced code will be assigned to the FSF. Code will adhere to the GNU coding standards and will be adequately commented and written to be as self-documenting as possible.
I'll use the Bazaar version control system for my work and so I can share my development branch either publicly (most likely) or at least with my mentor, and publish weekly tarballs. Bazaar supports foreign CVS repositories, so I can pull updates downstream from GRUB 2 CVS into my Bazaar branch over the course of the GSOC to keep up to date with GRUB CVS development; but compared to CVS, Bazaar makes branching and merging very pleasant, so I can separate logical units of work, keep stable and unstable branches, etc.
First, a basic graphical menu should be implemented. This will include support for highlighting options with the arrow keys and selecting an option. For the best appearance and usability, multiple font sizes must be supported, especially on larger screens (1920x1200, etc.), where an 8x8 pixel font will be far too small to be usable.
The current GRUB font code supports up to 16x16 pixel fonts (32 byte glyph bitmap), but I would extend the font loader to allocate glyph bitmap data dynamically to avoid this limit and support larger bitmap fonts. Concurrent use of multiple fonts will be supported. Proportional-width fonts will be supported.
If time permits, and if it seems useful, I may implement a utility to convert bitmap fonts from standard bitmap font formats into the GRUB format. In this way, the many free bitmap fonts available can be put to use in GRUB with minimal work required beyond the utility's implementation. We can then batch-convert fonts for use in GRUB, and can easily supply many different sizes of fonts for use in the GRUB menu.
Outline (vector) font support will not be implemented during the GSoC, unless time permits. Though use of outline fonts is probably too complex as far as rendering is concerned, but it may be worth considering a future outline font module option. This would make rendering large text much more practical, since a 96-point bitmap Unicode font would take up a very large amount of storage space (disk and memory).
The menu should be properly rendered no matter what video mode dimensions are in use. Specification of the UI layout should not be done in absolute pixel positioning, except when laying out static images of a fixed size, or for some other exceptional reason. The menu itself, and possibly the size of fonts used for rendering, could be dynamically selected based on the selected screen pixel dimensions.
The design of the GUI code will probably generally follow the design in ( http://grub.enbug.org/Subprojects/GraphicalMenu ). I will strive to support producing a display along the lines of ( http://grub.enbug.org/FancyMenu ) and ( http://nokkau.net/~chaac/files/grub2/grub2.html ), among other possible presentation styles.
After a basic graphical menu with item selection and good text support, animation support should be added. An animated timeout progress bar might be a good place to start; this will require timed event infrastructure that will be key to all animation support. Once a basic graphical menu and a basic animation are working, then adding support for customization via a theme or style sheet file will be added. New graphical menu options such as colors, UI layout style, and font size, as well as other graphical effects will be added to the graphical menu engine as well as to the theme file format.
By the mid-term evaluation, a graphical menu should be implemented, including the ability to display text in various fonts and sizes, select menu items, boot operating systems, and at least some basic style customization such as font size and color. Documentation would have been produced, probably primarily in the form of wiki pages on the GRUB wiki. It will include documentation on both the inner workings of the GUI menu system and also user-oriented documentation on how to configure the GUI and styles, etc.
During the remainder of the term, animation support would be implemented, including a progress bar and a fade in/fade out effect. We will concentrate on direct color video modes, and leave indexed color mode conversion to the video driver, since it is unlikely that GRUB 2 will be run on any video hardware that only supports indexed color modes (and text mode will be used on any non-graphical hardware, anyway).
I can use any IM network that my mentor prefers, I can use email, and I can have telephone or VOIP conversations. I could produce an online progress log of my work on the project, make my development branch accessible, post weekly tarballs, and produce documentation on the GRUB wiki as development progresses.
I have been using and hacking GNU/Linux and x86 PCs since I was 13. I am now a junior in Computer Science at Eastern Washington University. I have done a decent amount of x86 assembly language programming and low level C programming in DOS and Linux, as well as a lot of Java, C++, Perl, and other languages. I use GRUB on all my machines and I would love to help improve it. I have done graphics programming including assembly language 256 color VGA demos, image processing, GUI development in GTK+ (a little bit) and Java/Swing (extensive experience). I have contributed some small bits of code here and there to the Gentoo project, XMMS, and PyDDR (a Python Dance Dance Revolution clone). I have experience with internationalization and localization in software. I feel that my experience and skill set would make me an ideal candidate for this project. I am excited to get to work on this task!
These are features I am interested in adding, but which will have to wait until after the GSoC.