[RFC] New menu design based on MVC

[RFC] New menu design based on MVC

[Bean]

Hi,

The current menu system is a little chaotic, the various components
are mixed together which make it difficult to maintain and extend.
Therefore, I propose a new design which seperates model, view and
controller.

Model. It's the menu items. Currently, menu are added using menuitem
statement, which is unique to sh script engine. I think it'd be
advantageous to have a scipt independent way to define menu. Also,
using configfile to define submenu is not good, as it is
difficult to implement interaction between parent and child menu, for
example, auto expand the child menu when parent is selected, or
implement a hotkey that will jump back to the top menu regardless of
the current menu level. IMO, the menu should be loaded as a whole.

The menu is tree structure, a natural way to represent it is to use
xml, for example, we may write it like this:

<menu>
  <menu title="OS">
    <menu title="Windows 98" class="win98" fallback="Linux">
      root (hd0,1)
      chainloader +1
    </menu>
    <menu title="Linux" class="linux" lock>
      root (hd0,2)
      linux /vmlinuz
      initrd /initrd.img
    </menu>
  </menu>
  <menu title="Tools">
  </menu
</menu>

We can add a command load_menu to load it.

View. It's the menu viewer. Currently, the menu viewer resides in
normal.mod, but it should be placed in a standalone module. Also,
besides the current c version, we could add a new one written in lua.
LUA script is quite flexible, we can extend the function of menu
viewer without recompiling from source code.

Another improvement of menu viewer is to define the layout
dynamically, instead of hardcoding them in the source. And again, we
could utilize the xml to define the layout, perhaps something like
this:

<root>
  <image x="0" y="0" src="background.png" />
  <menu x="100" y="100" width="200" height="200" />
  <progressbar x="0" y="400" style="circular" />
</root>

Controller. Currenlt, the controller is mixed with viewer, the
show_menu function of menu viewer takes over once it's invoked. I
think it's better to move this part out of viewer. In fact, we can
implement this using event model. The controller waits for events,
such as keyboard, timer, etc, and then dispatch them to the viewer.

-- 
Bean

Re: [RFC] New menu design based on MVC

[Robert Millan]

On Thu, Jun 25, 2009 at 12:07:18PM +0800, Bean wrote:
> Hi,
> 
> The current menu system is a little chaotic, the various components
> are mixed together which make it difficult to maintain and extend.
> Therefore, I propose a new design which seperates model, view and
> controller.
> 
> Model. It's the menu items. Currently, menu are added using menuitem
> statement, which is unique to sh script engine. I think it'd be
> advantageous to have a scipt independent way to define menu. Also,
> using configfile to define submenu is not good, as it is
> difficult to implement interaction between parent and child menu, for
> example, auto expand the child menu when parent is selected, or
> implement a hotkey that will jump back to the top menu regardless of
> the current menu level. IMO, the menu should be loaded as a whole.
> 
> The menu is tree structure, a natural way to represent it is to use
> xml, for example, we may write it like this:
> 
> <menu>
>   <menu title="OS">
>     <menu title="Windows 98" class="win98" fallback="Linux">
>       root (hd0,1)
>       chainloader +1
>     </menu>
>     <menu title="Linux" class="linux" lock>
>       root (hd0,2)
>       linux /vmlinuz
>       initrd /initrd.img
>     </menu>
>   </menu>
>   <menu title="Tools">
>   </menu
> </menu>

Isn't Colin already working on a redesign of the menu?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [RFC] New menu design based on MVC

[Colin D Bennett]

Robert Millan wrote on Thursday 25 June 2009:
> On Thu, Jun 25, 2009 at 12:07:18PM +0800, Bean wrote:
> > Hi,
> >
> > The current menu system is a little chaotic, the various components
> > are mixed together which make it difficult to maintain and extend.
> > Therefore, I propose a new design which seperates model, view and
> > controller.

I would definitely like to get my graphical menu stuff committed before you 
make such changes... :-)

> 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 
except to add the concept of a "menu viewer" so that the text menu and 
graphical menu viewers can be treated uniformly at a higher level.

In fact, I am nearly ready to commit my graphical menu changes.  I was hoping 
to track down an apparent memory leak that shows up when switching themes many 
times in a row, but I don't have to let that prevent me from committing the 
current state of things.  I know Vladimir (phcoder) has done some work to get 
an SDL video driver working for grub-emu; I am hoping that I can somehow use 
memory debugging tools to track down my memory leak.

Does anyone have an idea if a tool like Valgrind would work with grub-emu to 
find the source of memory leaks?  I guess it should if grub-emu is using 
libc's malloc() and free() functions, right?

Regards,
Colin

Re: [RFC] New menu design based on MVC

[Bean]

On Thu, Jun 25, 2009 at 9:50 PM, Colin D Bennett<colin@gibibit.com> wrote:
> Robert Millan wrote on Thursday 25 June 2009:
>> On Thu, Jun 25, 2009 at 12:07:18PM +0800, Bean wrote:
>> > Hi,
>> >
>> > The current menu system is a little chaotic, the various components
>> > are mixed together which make it difficult to maintain and extend.
>> > Therefore, I propose a new design which seperates model, view and
>> > controller.
>
> I would definitely like to get my graphical menu stuff committed before you
> make such changes... :-)

Hi,

Oh, glad to know that, please commit your patches soon.

>
>> 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
> except to add the concept of a "menu viewer" so that the text menu and
> graphical menu viewers can be treated uniformly at a higher level.
>
> In fact, I am nearly ready to commit my graphical menu changes.  I was hoping
> to track down an apparent memory leak that shows up when switching themes many
> times in a row, but I don't have to let that prevent me from committing the
> current state of things.  I know Vladimir (phcoder) has done some work to get
> an SDL video driver working for grub-emu; I am hoping that I can somehow use
> memory debugging tools to track down my memory leak.
>
> Does anyone have an idea if a tool like Valgrind would work with grub-emu to
> find the source of memory leaks?  I guess it should if grub-emu is using
> libc's malloc() and free() functions, right?
>
> Regards,
> Colin
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Bean

Re: [RFC] New menu design based on MVC

[Robert Millan]

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.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [RFC] New menu design based on MVC

[Bean]

On Thu, Jun 25, 2009 at 10:25 PM, Robert Millan<rmh@aybabtu.com> 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>

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.

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.

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.

-- 
Bean

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<rmh@aybabtu.com> 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

Re: [RFC] New menu design based on MVC

[Isaac Dupree]

Bean wrote:
> 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.

and (out of order,)

> 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>

XML is a bit complicated to parse, unfortunately, compared to the ideal 
hierarchical data format.(of-course we might choose it despite that)

If graphical menu is going to rely on Lua, why not write the data in Lua 
too?  It's designed for this sort of usage IIRC (use its table 
syntaxes), though I don't recall it well enough to give a good example

-Isaac

Re: [RFC] New menu design based on MVC

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]

On Thu, Jun 25, 2009 at 3:50 PM, Colin D Bennett <colin@gibibit.com> wrote:

> Robert Millan wrote on Thursday 25 June 2009:
> > On Thu, Jun 25, 2009 at 12:07:18PM +0800, Bean wrote:
> > > Hi,
> > >
> > > The current menu system is a little chaotic, the various components
> > > are mixed together which make it difficult to maintain and extend.
> > > Therefore, I propose a new design which seperates model, view and
> > > controller.
>
> I would definitely like to get my graphical menu stuff committed before you
> make such changes... :-)
>
> > 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
> except to add the concept of a "menu viewer" so that the text menu and
> graphical menu viewers can be treated uniformly at a higher level.
>
> In fact, I am nearly ready to commit my graphical menu changes.  I was
> hoping
> to track down an apparent memory leak that shows up when switching themes
> many
> times in a row, but I don't have to let that prevent me from committing the
> current state of things.  I know Vladimir (phcoder) has done some work to
> get
> an SDL video driver working for grub-emu; I am hoping that I can somehow
> use
> memory debugging tools to track down my memory leak.
>
> Does anyone have an idea if a tool like Valgrind would work with grub-emu
> to
> find the source of memory leaks?  I guess it should if grub-emu is using
> libc's malloc() and free() functions, right?
>
Right. It works well. In the mail in which I sent you a WIP patch  I also
gave you a command to debug memory leaks:
valgrind --log-file=log --leak-check=full --leak-resolution=high ./grub-emu
-r hd0
For the moment I have to do some things not related to grub. When I have
time again I'll improve the patch (current version together with your patch
is available at
http://repo.or.cz/w/grub2/phcoder.git?a=shortlog;h=refs/heads/collin%2Bnewconf%2Bsdl)

>
> Regards,
> Colin
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

[-- Attachment #2: Type: text/html, Size: 3260 bytes --]

Re: [RFC] New menu design based on MVC

[Pavel Roskin]

On Thu, 2009-06-25 at 23:54 +0800, Bean wrote:

> 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.

I tend to agree with Robert here.  It's more important to make a stable
release.  As for the themes, we should make it clear that there will be
incompatible changes in the menu and the graphics subsystem, so that
theme authors are prepared to deal with it.

We should not be constrained by the expectations that we explicitly
disclaim.

-- 
Regards,
Pavel Roskin

Re: [RFC] New menu design based on MVC

[Robert Millan]

Btw, what is MVC anyway? :-)

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [RFC] New menu design based on MVC

[Pavel Roskin]

On Fri, 2009-06-26 at 16:31 +0200, Robert Millan wrote:
> Btw, what is MVC anyway? :-)

http://en.wikipedia.org/wiki/Model-view-controller

It's a popular design pattern in designing business applications, which
discourages hardcoding the rules (business logic) into the data
structures and the user interface.

I'm not sure if we have anything corresponding to the business logic in
GRUB (perhaps password checking could fit there).  The view (i.e. the
menu) is already separate from the data (if that means the OSes to be
loaded).

-- 
Regards,
Pavel Roskin

Re: [RFC] New menu design based on MVC

[Marco Gerards]

Hi,

Bean <bean123ch@gmail.com> writes:

> The current menu system is a little chaotic, the various components
> are mixed together which make it difficult to maintain and extend.
> Therefore, I propose a new design which seperates model, view and
> controller.
>
> Model. It's the menu items. Currently, menu are added using menuitem
> statement, which is unique to sh script engine. I think it'd be
> advantageous to have a scipt independent way to define menu. Also,
> using configfile to define submenu is not good, as it is
> difficult to implement interaction between parent and child menu, for
> example, auto expand the child menu when parent is selected, or
> implement a hotkey that will jump back to the top menu regardless of
> the current menu level. IMO, the menu should be loaded as a whole.
>
> The menu is tree structure, a natural way to represent it is to use
> xml, for example, we may write it like this:
>
> <menu>
>   <menu title="OS">
>     <menu title="Windows 98" class="win98" fallback="Linux">
>       root (hd0,1)
>       chainloader +1
>     </menu>
>     <menu title="Linux" class="linux" lock>
>       root (hd0,2)
>       linux /vmlinuz
>       initrd /initrd.img
>     </menu>
>   </menu>
>   <menu title="Tools">
>   </menu
> </menu>

Personally, I do not like XML.  So I have a *very* strong opinion
against using this.  The current syntax is closer to most programming
languages.  Shouldn't we focus on getting that into shape?

Perhaps I should actually make that my first priority when I get some
time again to work on GRUB (fixing scripting support, etc).

--
Marco