This is definitely a great feature for future versions and is already in our backlog, though it will require significant effort to implement. Thank you.

Unfortunately, I didn't come across your library when checking for name collisions. You're right, this is purely a coincidence.

Modern 3D rendering APIs (like Metal, D3D12 and Vulkan and D3D11 to some extent) offer far more flexibility than the traditional triangles-and-materials approach. Rendering in Brisk leverages complex shaders that directly process drawing commands on GPU, avoiding the intermediate step of converting them into a list of triangles.

For text rendering, Brisk uses FreeType to render glyphs on the CPU and caches these glyphs in a GPU-accessible texture, which is reused for improved performance. This approach is common among GUI toolkits for handling graphics and fonts.

In addition to this, Brisk employs SDF (signed distance field) graphics wherever possible, which are entirely computed in shaders.

There are many professional applications (not games) that use custom-drawn UIs. Examples include video editing software, 3D modeling tools, and professional audio plug-ins. These applications may rely on a significant amount of platform-specific APIs for better OS integration, yet they maintain a consistent appearance across all supported platforms.

Accessibility features are planned and will be included in one of the upcoming major releases.

Thank you for the feedback. C++ isn't a language that makes data binding implementation easy, but C++20 introduces some useful features that could be leveraged for this purpose.

Good point about the non-Windows screenshots, but the Brisk library apps look exactly the same (except for window decorations and DPI scaling) on any supported OS due to its custom pixel-perfect graphics engine and its own font engine (based on FreeType and HarfBuzz, of course). Key bindings are not supported at the moment. The calc example shows a possible workaround for this.

Oh, wowzers, then you should really _for sure_ put macOS and Linux screenshots to warn off people who don't want <canvas> driven UIs on those platforms. I now better understand why you have listed WebGPU as a requirement

Specifying things declaratively within the language itself goes far beyond simply constructing widgets by calling library functions.

This technique is utilized in modern frameworks like Jetpack Compose, Flutter and SwiftUI and unlocks several powerful features, such as flexible data binding and the ability to rebuild the widget tree on demand, features that would be quite difficult to implement in other libraries.

Wouldn’t pure data based definition scheme enable all of the above in any case?

If the underlying model is tree, then any graph based configuration data could be used to build it.

I mean underneath it could be implemented using the api as is, but as a C++ dev I don’t see any compelling reason to be interested in this.

You can do the most astounding things nowadays in 100fps. I’m not sure if manually handcrafting object initialization trees to a ui framework is something I want to do as a developer in 2024.

This is not intended as a put-down! This must have been enormous amount of work.

I would love to hear the rationale for why exposing the user API as a class structure like this - I’m sure there are good reasons and would love to hear them.

Thank you for the feedback. The framework was originally built with exceptions always disabled, and it is currently being reworked to support both modes: exceptions enabled and disabled. Some approaches definitely need to be reconsidered.

An alternative approach is to use the rcnew macro, which wraps a pointer in a shared_ptr under the hood. Details on the implementation of rcnew can be found at: https://www.kfr.dev/blog/three-cpp-tricks/

Why not std::make_shared, given that you require C++20 anyway?

Just a quick note that the basic form of std::make_shared (which is the one that is relevant here) has been in the language since C++11.

Why is heap allocation and shared_ptr required? Can't you have the user store the widgets in whatever manner they want, as values?

You absolutely can. Heap allocation for every component is already unneccesary, but loose pointers on top of that is a huge red flag.

This seems like someone who isn't up to date with the most elegant and fastest ways to write C++. Charging money on top of that is egregious, not to mention that there are lots of great GUI libraries already. FLTK, Juce, Qt to name a few.

Heap allocation is necessary in real-world scenarios because it allows a tree of potentially derived widget types to be manipulated easily. This is precisely how any robust GUI library is implemented.

The pricing information will be made public at the time of the next Beta release. Currently, the framework is refining Linux support, with plans to include mobile platforms as well.