Re: [RFC] New menu design based on MVC

[Colin D Bennett]

Bean wrote on Thursday 25 June 2009:
> On Thu, Jun 25, 2009 at 10:25 PM, Robert Millan<address@hidden> wrote:
> > On Thu, Jun 25, 2009 at 06:50:55AM -0700, Colin D Bennett wrote:
> >> > Isn't Colin already working on a redesign of the menu?
> >>
> >> Yes, but I haven't drastically changed the design of the core menu
> >> system
> >
> > In general, I'm not happy with this kind of drastical changes specially
> > at this time.  We're supposed to be replacing GRUB Legacy with GRUB 2,
> > *that* is the reason we rewrote GRUB almost from scratch.
> >
> > This gives us plenty of room for newer/fancier stuff.  For example GRUB 2
> > is portable, and it's being ported to a number of platforms.  But we
> > haven't even finished exploiting the current design and we're already
> > discussing major changes to the GRUB core.  Isn't this something for GRUB
> > 3 ?
> >
> > Distributors want something which does the job and is first and foremost
> > stable and robust.
>
> Hi,
>
> Actually, the changes are not so dramatic, my main points are:
>
> Use xml to store data. With Colin's graphic menu path, we are already
> introducing a new file format - the theme file. But the current
> representation is a little awkward, for example, to write a label, it
> uses:
>
> +vbox{ +label{ text="Hello" } +label{ text="World" } }
>
> I think it would be more natural to write it like this:
>
> <vbox>
>   <label text="Hello" />
>   <label text="World" />
> </vox>

I think XML could be a viable format.  Personally, I think there are both 
positives and negatives to XML, but it is nice to have a standard which would 
make it much easier to create theme authoring tools--we could use standard XML 
libraries to implement tools to read/write theme files.  I'd like to convert 
some of my example theme files to a hypothetical XML format just to see if it 
looks like a good solution.

> Once the official version is out, people could start creating theme
> files, which make it more difficult to change the format. I think it'd
> be better if we can make it right the first time.

True, we should make sure we are happy with the theme format ASAP.

> Implement the menu viewer in lua. Colin's patch already make extensive
> use of lua, so perhaps we can just standardize the interface a little
> bit, and make it easier to write components using either c or lua.

My current patch does not use Lua at all.  I did make an *experimental* 
version of my patch that added Lua support along with letting themes include 
Lua scripts--my demo did an animated background all with Lua code calling GRUB 
video API functions.

During the GSoC'08, I was told that I couldn't depend on Lua for my project, 
so I figured maybe we'd revisit it down the road.

> Event model. This reduce code duplication among viewers. For example,
> instead of polling the keyboards, it just need to write a keyboard
> handler that get called when the a key is pressed. This model also
> make it easier to add new input device, such as mouse.

Will mouse support make sense for non-graphical menu viewers?

Regards,
Colin