[PATCH 00/24] bootstd: Add a boot menu

[Simon Glass]

Hi Heinrich,

On Mon, 17 Oct 2022 at 15:11, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 10/17/22 22:29, Simon Glass wrote:
> > So far standard boot lacks a boot menu, although it is possible to create
> > a rudimentary one using the existing 'bootmenu' command.
> >
> > Even then, this text-based menu offer only basic functionality and does
> > not take full advantage of the displays which are common on many devices.
> >
> > This series provides a 'bootflow menu' command which allows the user to
> > select from the available bootflows. An attempt is made to show the name
> > of the available operating systems, by reading more information into the
> > bootflow. A logo can be read also, where supported, so that this can be
> > presented to the user when an option is highlighted.
> >
> > Full use is made of TrueType fonts, if enabled. For cases where only a
> > serial console is available, it falls back to a simple text-based menu.
> >
> > All of this is implementing using a new 'expo' construct, a collection of
> > scenes (like menu screens) which can be navigated by the user to view
> > information and select option. This is fairly general and should be able
> > to cope with a wider array of use cases, with less hacking of the menu
> > code, such as is currently needed for CMD_BOOTEFI_BOOTMGR.
> >
> > Of course it would be possible to enhance the existing menu rather than
> > creating a new setup. Instead it seems better to make the existing menu
> > use expo, if code space permits. It avoids the event-loop problem and
> > should be more extensible, given its loosely coupled components and use of
> > IDs instead of pointers. Further motivation is provided in the
> > documentation.
> >
> > For now the CLI keypress-decoding code is split out to be used by the new
> > menu. The key codes defined by menu.h are reused also.
> >
> > This is of course just a starting point. Some ideas for future work are
> > included in the documentation.
>
> Hello Simon,
>
> Linaro's implementation of a boot menu for UEFI booting showed that the
> current basis of bootmenu is inadequate for properly designing a GUI
> like user interface.
>
> With your patch set you try to overcome this. Your design document in
> patch 24 identifies a hierarchy of objects expo - scene - design element
> but otherwise remains rather sketchy to me.

For now the doc is here:

https://docs.google.com/document/d/1VQeApnLlH6xKm_OI36AhWkJLUEd9OXEvIJXB8aM2de8/edit?usp=sharing&resourcekey=0-DwgHpR2S8vJEJzvvwPb-AQ

>
> Before investing into code we should a more holistic design perspective.
>
> First thing we need to define is our requirements, e.g.
>
> ** Which input devices do we want to support in future **
>
> - keyboard
> - mouse

I have patches for mouse, actually.

>
> ** What type of GUI do we want to support **
>
> - text terminal
> - graphical output
>
> ** Which design elements do we need **
>
> - lists
> - trees
> - grids
> - menus
> - labels
> - buttons
> - drop down lists
> - combo boxes
> - bitmaps
> - screens (you call them scene)
> - transactions (you call them expo)

(this series has rudimentary menus, labels and bitmaps, but does not
support the others)

>
> ** How do we want to structure our GUI **
>
> - Good practice is to clearly separate model, view, and controller.

Expo is the view. Controller is the client code. Model is currently
the expo, updated by the controller. That part of it needs though if
we are to expand the capabilities of this effort.

>
> ** Which constraints do we have to observe? **
>
> - How much is the code base allowed to grow?
> - Who will be the long term sponsor and maintainer?
>
> After having this rough cut overview we may start with a draft
> implementation and detail our design document.
>
> How do you plan to organize the design work?

See also the bottom of the docs for some future work, also whether we
should consider using a GUI library like Nuklear in the future:

https://patchwork.ozlabs.org/project/uboot/patch/20221017203000.2207887-25-sjg@chromium.org/

It has evolved since that doc. The doc needs to evolve further.
Perhaps we can start by agreeing the requirements.

Regards,
Simon