grub-devel
[Top][All Lists]
Advanced

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

how menu interface code should be


From: Yoshinori K. Okuji
Subject: how menu interface code should be
Date: Wed, 19 Apr 2006 12:18:51 +0200
User-agent: KMail/1.8.2

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




reply via email to

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