HikoGUI is now temporarily a header-only library. This is in preparation of
making it a module-only library. This required a lot of work to untangle
the many circular dependencies.
With modules it is now much easier to switch out different implementations
of classes and functions, so I've de-virtualized the GFX and GUI parts of
the library. This means that a win32-window and a X11-window are now both
called hi::gui_window. There are many benefits by fully replacing
implementations and having them have the same name, including allowing
implementation to have very different architectures and having them exposing
implementation specific members.
I've also been working on replacing the global classes with free-functions,
like the: font-book, theme-book, gui-system, audio-system, gfx-system, etc.
Right now some of them are still implemented as a class that is instantiated
as a global variable, but this is an implementation detail.
Another benefit of the header-only work is that the Unicode algorithms and
Unicode database are now constexpr. This includes improvement of the database
that now uses a double associative lookup O(1). The database is now stored
in columns, packed bit-wise, for improved space & cache efficiency.
The main text string type is now a std::basic_stringhi::grapheme
also known as hi::gstring. The hi::grapheme contains one or more
Unicode code-points forming a Grapheme Cluster, a language-tag and a phrasing.
All of this information is needed to display text properly, and for
possible features like spell checking and text-to-speech.
I discovered and fixed a security vulnerability with mapping files and parsing,
in particular with my implementation of true-type files. True-type files are
designed to be loaded in memory and be directly used as a data structure.
HikoGUI uses mmap() to map a true-type file in memory, check if the data
is valid, and then use the data directly. However when you memory map a file the
file can be changed during the execution of the application, bypassing the
validation check that is only done when the file was first mapped. The fix
is to simply validate all data read during the execution of the application.
There is a performance impact, but it is a small price to pay compared to
loading the true-type file in memory, especially on low memory devices.
Of course I also decided to rewrite the true-type font parser and allow it to
render runs of text. A run is a piece of text that is part of a single line, and
uses the same font, style and language. In the future we can use the GPOS
and GSUB tables to properly handle ligatures and cursive fonts. The text-shaper
will need to relegate the responsibilities of rendering text to different
sub-systems.
Added a Vulkan triangle-example, which shows how to use HikoGUI together with
an application that wants to render graphics. Basically the application
can directly render into the swap-chain images through a call-back mechanism.
Then HikoGUI draws the GUI on-top of this drawing using alpha compositing, where
the widget that shows the drawing punches a hole through the GUI so that the
drawing stays visible.