[Top][All Lists]

[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 

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.


reply via email to

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