• FancyMenu

• "Fancy Menu" for GRUB2

This page is here to put together all of the ideas on the menu so far, please add yours here.

As a starting point there has already been discussion on this in the development list, here are a couple of the messages from Yoshinori K. Okuji about this:

how menu interface code should be

Here is my idea about how the menu code should be rewritten.
We are planning to have at least two different menu interfaces: one is based
on text, and the other is based on graphics. They will have to be a bit
separate, because the logic of the view is not the same. It might be possible
to use the same code with a kind of style/theme, but I'm not sure if it is
feasible.
Anyway, we need to define what part can be shared and what not. In this
context, the good model would be the so-called MVC (Model-View-Controller),
which has been used in the area of GUI for long, and also for web
applications these days. For those who are not familiar with this concept, I
describe how I interpret it in the context of GRUB:
Model -- the data structure of the menu interface, and the manipulation of the
data. For example, how to get a next entry and how to boot current entry
would be good examples.
View -- the rendering or view of the menu data. This should be trivial.
Controller -- the user actions on the menu interface. For example, inputting a
key and moving a mouse cursor would be good examples.
What's bad with the current code is that we do not distinguish Model from
View. So if one wants to implement a new appearance of the menu, nearly
everything must rewritten or duplicated.
I believe that the following would be the best:
- Define data structures. The current design may be reusable.
- Write data access/manipulation code as a Model. Define the API precisely.
- Write the rendering code as a view. Define the API precisely to get feedback
from other components. This code must not access the data directly, but use
the API of the Model.
- Write the Controller. This should be trivial once the Model is defined well.
The distinction between View and Controller might not be very important for
us, but I think it would be nice to keep this in mind.
The advantage with this approach is the modularity. For example, if you want
to implement a very different graphics interface, you would only have to
implement the View part. If you want to add support for a touch panel, you
would only have to implement the Controller part. In other words, the menu
would be pluggable.
Okuji

what must be possible with the future fancy interface

I give a simple example of a possible menu interface here. This example is
extremely simple among my ideas, but still requires a lot of new features (so
the code as well). I name it "twm-like", because this resembles the twm
window manager in good old days.
Although this looks complicated, the required features are not that many.
- GRUB needs to put a background image.
- GRUB needs to put text at arbitrary points.
- GRUB needs to manipulate image data (in order to draw a scroll bar and a
timeout bar).
- GRUB needs to have timer events (in order to animate some pictures and text)
Note that the important thing here is that they must be entirely customizable.
As drawing this kind of picture takes a lot of time, I hesitate to make more
pictures. But I have much more complicated examples in mind; but what's
necessary is mostly some manipulation features of image data.
Okuji

twm-like.png

CategoryDeveloper