I did a test - what id we would have a declaraive API? (not a reactive one, meaning - data would not modify the UI). I started experimenting.

.

I was impressed - this UI looked cooler and easier to read. On the minimap of my IDE - I could actually see the the UI tree. The chaining API got a new life here, being the center of the stage. Everything is chainable.

See how easy is to define a menu/toolbar and center of window (here the root widget is constructed elsewhere in the code):

window->set_root(
    ui::vbox()
        .margins(ui::no_margins())
        .spacing(ui::no_spacing)
        .add(ui::menubar()
                    .add_menu(
                        ui::menu("&File")
                            .action(new_cmd)
                            .action(open_cmd)
                            .action(save_cmd)
                            .action(export_cmd)
                            .separator()
                            .submenu(
                                "Recent &Files",
                                ui::menu()
                                    .action("&File1.txt", [] { spdlog::info("Opening File1"); })
                                    .action("&File2.txt", [] { spdlog::info("Opening File2"); }))
                            .separator()
                            .action(exit_cmd))
                    .add_menu(ui::menu("&Edit")
                                .action(undo_cmd)
                                .action(redo_cmd)
                                .separator()
                                .action("Cut", [] { spdlog::info("Menu: Cut"); })
                                .action("Copy", [] { spdlog::info("Menu: Copy"); })
                                .action("Paste", [] { spdlog::info("Menu: Paste"); }))
                    .add_menu(ui::menu("&Help")
                                .action("About",
                                        [&window] {
                                            toolkit::MessageBox(window)
                                                .title("About SVision3")
                                                .markdown()
                                                .message("## SVision3\n\n"
                                                        "Declarative API demo application.\n\n"
                                                        "Demo of a C++ **cross-platform** UI "
                                                        "toolkit.")
                                                .show();
                                        })))
        .add(ui::toolbar()
                    .command("OK", [] { spdlog::info("Toolbar: OK"); })
                    .command(exit_cmd)
                    .separator()
                    .command("Disabled", "This command is disabled")
                    .disable()
                    .command("Increase count", "Increase the counter", {}, repeat_action)
                    .add(ui::spacer(), ui::expand)
                    .add(toolbar_theme_toggle)
                    .add(toolbar_theme_combo))
        .add(rootWidget, ui::expand)

Then I ported the main demo app into the new declarative API, and the same UI was written in 200 lines less! Binary size was the same (as this is just syntactic sugar on top of the imperative API).

Not unlike Android's Compose API.

However - you will get a non native solution, or a limited GUI, or a very large installer. In some cases, things like utilities to modify a small hardware you provide (the Logiteck mouse utilities, Rapoo has a similar utility or maybe a program to flush the firmware of your new USB adget) - using available solutions just do not scale, or are non optimal.

Other solutions are great (specially Qt, DearImgui and Slint, which are my recommendations). But I think SVision3 can provide a valid alternative to existing toolkit libraries,in a very small codebase withtout compromising on features. This list does not aim to "trash" competitions - but to praise them. They all have a their place.

Electron with JavaScript/Typescript.​

Electron based application seem to be the prefered method in the industry. This is what VSCode, Slack and lots of other use.

You get the very large ecosystem of nodejs - and an easy way to target the major platforms. Another huge benefit - is that you can share code with your web site, and provide a very similar experience.

The problem this solution cannot solve - is that you are still writing a portable website into a window. Integration with the user's desktop/platform is not ideal. You are locked in JavaScript (wasting d-ccache, and fearing the underterministic heap cleanup) and any interaction with the OS needs to be marshalled.

Tauri - Rust+JavaScript/TypeScript​

Use Tauri with JavaScript/Typescript for front end, and backend (?) in Rust. This is becoming an alternative to Electron using the system webview. But again, you are in Javascript land - not running directly on the OS. This is another abstraction.

Dear Imgui​

You can use Dear Imgui for immediate C++ GUI. This is a very simple UI to integrate into an existing system. It is native, and very performant - but the toolkit is limited, and making a proper desktop app is not trivial (BUT! There are some very impressive applications written in it!).

The toolkit provided is very limited, and does not look native. Doing layouts or using docks is not standard (the docks branch is stable, but not the default).

Localization, and internazionalisation is not trivial.

Complex text layout? Screen readers? Input methods? This is not something this library can fix at this moment.

Use Qt with Widgets or QML.​

If you want "the best" C++ toolkit available - that would be Qt. Period. It is everything you need and can be used in other languages as well (lots of Python code uses Qt). The disadvantage is a very large distribution binary. It is difficult to properly deploy in an installer (I know, I have experience with it).

Another problem with Qt - is that the "widgets" part is considered "done". No real development is going there. The vast majority of the development effort is on the QML site. Also, as a very "experienced" library, it started when STL was not a thing and it contains another container library.

This is one of my personal peeves with it: it tries to do everything for its own. You want an INI file loader? we got an implementation. Painters? Cool, we got our own. QRichTextWidget for exmaple uses its own rendering engine for its minimal HTML (and you have WebView as well).

I also found myself writing very basic widgets, which I assume they should provide in 2026. And I am still have bugs related to DPI, and look inside GNome or Windows11 is not ideal.

SlintUI​

A new alternative I see - is slint. It seems to be Qt, without QWidget, purely QML. A good rust support, and C++ native. UI code is written in a DSL, not in C++.

I am not a fan of another language for the UI. Also, this still uses JavaScript which is another huge dependency. Might be OK for you - but not what I consider native.

SVision 3​

This new toolkit is trying to think: "what if QtWidgets was done from scratch using modern C++". We could re-use a lot of 3rd parties instead of re-writing all from scratch (see https://en.wikipedia.org/wiki/Not_invented_here).

Some of the ideas that are in the design of SVision3:

• Do not abuse inheritance. Qt has QWidget -> QPushButton -> QCheckbox/QButton. In SVision3 snstead, functionality needed by several classes is moved to a new class (see ButtonState). This re-uses behaviour in several widgets. See also https://en.wikipedia.org/wiki/Composition_over_inheritance .
• We have a large ecosystem of 3rd parties. We can use toml++ for parsing INI/Toml files, or use litehtml and md4c to display markdown in a widget. For logging we can use spdlog which gives us for free also fmt.
• Unlike Qt, which uses its painter, SVision3 abstract the platfomr's native painter (GDI+, Cocoa or Cairo) in a very thin way, so in generated code actually uses the platform's drawing routines.
• We can use catch2 as internal unit test framework.

All these ideas free the toolkit's developers from doing anything not related to the toolkit itself (no unit test framwork, build system).

Some other things that make this toolkit better:

• We use UTF-8 everywhere. We have an iterator for reading it, as just iteragin over the char vectos will fail.
• We have themes that emulate the look and feel of the host platform. Ideally - a user of this library, will not know how its built - it will look "in home".
• CSD as first class citizen. Window decorations are normal widgets and layouts you can just hook into them - and inject a normal widget.
• We do use the platform's image loaders. On Windows and macOS - the platform provide very good APIs. No need to re-bundle libpng or libjpeg.
• We do learn from Qt experience - and subsystems are abstracted. Platform windowing is chosen on runtime (Windows and macOS have a single one, but Linux has X11 and Wayland) each providing its own painter, and rasterizer. (not unlike fltk).
• We also let developers choose the painter, or rasterizer at compile time - so you can provide your own backend for creating windows, painting or load images.
• We have i18n. The difference from Qt/GTK is that our translation system creates classes containing the translation, which are compiled into the binary itseld, instead of data parsed at runtime (but still - PO reading at runtime is supported).
• The MVC system Qt uses was the inspiration for the system used in SVision3.
• 0FPS. Unlike toolkits like slint which has a moto of "we can draw 60 frames per second" - we aim at the exact oposite. We don't draw if possible. In static UIs (lets be honest, applications sit idle in ideal mode). No drawing is done at all. Same for Dear Imgui - which redraws constantly.
• We use conan for distributing the library.
• We also provide a demo git repo, which you can clone and continue working on your own repo. This already contians github/gitlab actions to build your application - reducing fraction, so you can focus on develping software, not on packaging for 3-4 platforms.

So yes. Another toolkit. I think I can do better, with less code and smaller footprint.

This is the 3rd iteration. It is much more mature try to build a production ready cross platform GUI in pure C++.

This is a very exciting time to be writing C++ code, with C++26 comming to life and bringing exciting featuress like compile time reflection. We have the best tools for helping develop (thinkgs like clang-format or clang-tidy). Sites like https://github.com or https:://gitlab.com that help spread code. New build sysetems like vcpkg or connan.

What's here today​

• Tutorial — build the toolkit and get a window with a label and a button on screen.
• Demos — demos of the available code.
• Declarative API — the ui:: fluent wrapper used throughout demo_declarative.cpp.
• Widgets & Modules — every widget class, grouped by category, each with its constructor, API table, callbacks, and a themed screenshot gallery.

This blog will track notable changes to the toolkit and to the docs themselves as both evolve.