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

[Heinrich Schuchardt]

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.

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

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

** How do we want to structure our GUI **

- Good practice is to clearly separate model, view, and controller.

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

Best regards

Heinrich