[0.7.0] Strange Squirrel

[takev]

HikoGUI is a fast and efficient desktop application library written in C++20.

It has been quite a few months since I released the last version, this version 0.7.0 therefor has a lot of changes, I will highlight a few in this post.

observer:
I changed how observer<> works, this is basically a template-class which observes a value and then calls a registered callback on modification. It can now create a sub-observer<> from a member variable of the value it observers. This makes it possible for widgets to be composable. This is based loosely on lager's lenses and cursors.

Here is a good example on line 15, 17 of label_widget.cpp; label is a observer<label> which has two member variables icon and text, which is passed to it's two children.

label_widget::label_widget(gui_window &window, widget *parent, observable<label> label) {
    _icon_widget = std::make_unique<icon_widget>(window, this, label.get<"icon">());
    _text_widget = std::make_unique<text_widget>(window, this, label.get<"text">());
}

The observer<> is able to do this using the selector<> type-trait to select a member variable based on a fixed-string tag. You can see the specialisation for selector<label> at line 181-197 of label.hpp. Using fixed strings as tags in C++20 is really nice and use it in quite a few places in HikoGUI.

Unicode:
I changed the Unicode character database to de-duplicate information in groups of 32 code-points. This allows selecting entries from the database using a quick two step associative lookup. You can see this on line 14-22 of unicode_description.cpp

I also changed the grapheme character type so that it can be used with std::basic_string<grapheme> or gstring for short. The grapheme type is only 21 bits. A single code-point is encoded as-is, while the values 0x11'0000 to 0x1f'ffff are used to index into an add-only table of multi-code-point graphemes. Only using 21 bits allows for a future character type atributted_grapheme which includes a text-style, phrasing and language tag.

A new char_converter<tag,tag> template has been added which converts between two char_map<tag>s. A char_map<tag> may be specialized by a user to add more character encodings. The tags here are again fixed-strings.

File handling:
Most of the file handling API of HikoGUI now take a std::filesystem::path, when I started with HikoGUI std::filesystem::path was still experimental so I created URL this was one of the first types I wrote and although it is hardly used directly anymore by the API has been given an overhaul as well. At the same time I reworked the file and file_view (memory mapped IO) as a pimpl, so that file and file_view can now be treated as value-types.

Widgets:
There is now a single handle_event() member function for a widget that you can override in custom widgets, this will handle keyboard, mouse, and commands (keyboard and mouse bindings may be translated into commands). This greatly simplifies the previous system with multiple member functions handling different kind of events, each with a different way of forwarding events to base-classes and to parent widgets.

I also put back in a text-baseline system for widgets. When widgets are located on the same row, they will try to share a text-baseline among them using a priority system, this makes the text between widgets align properly even if the widgets are of different types and styles.

Talking about styles; the color type now can both encode an RGBA (half float) value or a semantic color. A semantic color is a color that is used in a specific context and is specified in a theme. Just before rendering the semantic colors will be resolved to an RGBA value. This makes working with colors easier because there is only one type to worry about. I will be using the same technique for encoding semantic-text-style in a text-style in the future.

HikoGUI does not accept Windows 10 HDR capability as "uniform". On Windows 10 when an application requests a HDR capable window, it will switch the complete desktop from SDR to HDR, this switching will cause the whole desktop to visually look different. This is not a problem on other operating systems like MacOS where the desktop is always HDR. If a HikoGUI application must present HDR content, then it can explicitly opt-in on non-"uniform" systems.

A new shader has been added to reset the alpha channel of a region. This will punch a hole in the GUI, so that image previously rendered in the swapchain-image becomes visible. This can be used by an application to let another graphics engine draw into the swap-chain before HikoGUI, which is displayed as-if it is a widget.

This new "alpha channel" shader in the future will also be used to mark a region as "image content" to be tone-mapped from SDR -> HDR or HDR -> SDR (using the invalid alpha values). Other regions are normal GUI elements which may contain HDR and high-gamut colors, but the mapping to SDR will be different.

Documentation:
There is now documentation for building split into IDEs and package managers, the first two are

• Build with Visual Studio
• Build with Visual Studio and vcpkg

I am looking forward to receiving documentation for building with other IDEs.

I have also started to use the "group" documentation of Doxygen. This uses the @ingroup Doxygen command, which will create the documentation in the Modules tab. I really like how this works as you can make nested groups, and each page contains a piece of text explaining the module and a list of types and function that belong to that module.
I will be migrating most of the old documentation from the "Related Pages" to these "Modules".