Dialog API for simple genode-native GUI applications

[nfeske]

The menu-view dialog-rendering component is used by a number of simple interactive Genode applications, the most prominent being the Sculpt manager. Other examples are the touch keyboard, file vault, text area, and @alex-ab's power tools. The menu-view approach is useful in situations where the complexity of commodity GUI tool kits like Qt is unwanted. Menu-view-based applications merely consume hover reports and produce dialog descriptions in XML. In contrast to GUI toolkit libraries, the widget rendering happens outside the address space of the application.

The XML processing is usually done via a rather ad-hoc-designed set of utilities. These utilities and patterns start to stand in the way when applications become more complex, e.g., as experienced with the phone manager as employed by mobile variant of Sculpt OS. The new dialog API aims at simplifying the creation of menu-view-based applications. The key ideas are:

• The management of menu-view components (generating sandbox configurations, implementing the ROM service to supply dialog descriptions, and implementing the report service to obtain hover reports) should better be moved to a re-usable library, relieving applications from such technicalities.
• Large parts of application code is currently needed to apply hover information to the application's local dialog model. This code is not intuitive and is prone to become brittle when making structural changes in the dialogs. Hover handling should better not be the responsibility of the application.
• Right now, menu-view based applications tend to not work with touch input unless special care has been taken. The application should better not need to distinguish pointer-based from touch-based input.
• Input used to be handled in two steps: First, hover information is applied to an internal data model. Second, once a click occurs, the currently known hover information is evaluated to respond to the click. This two-stage approach is too complicated. From an application point of view, a click should come with all information needed to handle it without relying on any cached (hover) state.
• The evaluation of hover reports must always be consistent with the dialog structure. But the manual parsing and generation of XML does not reinforce this consistency. By encoding dialog structure in C++ types that are used by both the dialog generation (view) and event handlers (control), the consistently can be enforced by the compiler, avoiding many manual compile-test cycles.

Note that the dialog API is specifically designed for the needs of Sculpt's UI and similar bare-bones utilities. It is not intended to become a desktop-grade general-purpose widget set. E.g., complex topics like multi-language support are out of scope.

At the current stage, the API should be regarded as being in an evaluation stage. I'm currently in the process of confronting it with all use cases found in Sculpt's UI, and gradually refining it. Once Sculpt's UI is completely converted, it will be fair to assume its fitness for other purposes and document it properly.