[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
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- how menu interface code should be,
Yoshinori K. Okuji <=