While I welcome new cross-platform GUI Frameworks, I wonder why not use a declarative UI similar to QML? Even Slint[1] (which is built in Rust) uses such syntax for its UI.
I've only dabbled a bit in 3D graphics (OpenGL, THREE.js, swift SceneKit). When these 2D GUIs say "GPU-accelerated", does that mean they are doing the same thing you would do for 3D - build triangular meshes, materials, etc - and then just essentially point an orthographic camera at this "scene"? Or what kind of low-level GPU APIs (eg WebGPU) are used?
I think it just means the texture image for the widgets are loaded into gpu memory space instead of a traditional framebuffer that gets copied to the gpu.
I dabbled in 3D for a while too and was astonished how much 2D stuff there is for it.
How well integrated with the underlying platform is it? For example, on Windows do you take advantage of accessibility APIs for things like screen readers?
I don't think open source GUI toolkit developers should be expected to handle accessibility until OS vendors spend some of their billions of dollars to develop a reasonable cross-platform API.
If you are creating tooling for people to create GUIs, it should always be possible to make those GUIs accessible. I’m not saying this one doesn’t—I don’t know if it does—but in the general case it absolutely should. Not everyone is going to bother, but not even giving people the ability would be deeply irresponsible.
Why should OS vendors spend money devaluing their product? It's up to the cross platform software developers to make abstractions that work across platforms, not on platform developers to make things that work on other platforms.
All those naked 'new's in the example make me nervous. I see that the library uses exceptions, if one of the widget constructor throws while composing the overall widget hierarchy, it would leak memory.
You should be able to make it work with a value-based interface and allocating behind the scenes (this would also enable a few optimization opportunities).
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/
I spent a very long time giving SolveSpace a native Haiku UI. I'm going to keep doing this kind of thing because there's nothing I personally dislike more than apps that don't use the platform's native UI.
I don't care that my approach is harder for the developer, because the thing I care about is consistency and convenience for the user.
I know the thing you built is neat (I've spent quite a few years working on almost the same thing), but I guess this is why I gave up on pushing my own solution
” nothing I personally dislike more than apps that don't use the platform's native UI”
I’m not sure if this is universally applicable dogma. Games generally apply their own UI regardless of platform.
Web apps generally do as well.
I do realize there is space for apps with least surprise per platform, but it’s not obvious to me if an app benefits from platform standard UI any quantifiable way.
App usability and performance typically benefit greatly from using the native platform they’re running on. Plus all the egress savings of not shipping chromium with every download
This looks really good. It's nice to see some options like this (and slint) appearing for cross-platform desktop GUI. I'm pretty skeptical of "modern" c++ but this looks like a good example of using it where it makes sense.
The data binding looks particularly clever. That's usually the Achilles heel of GUI toolkits (for me at least) and that looks like a clever and novel solution if it works.
How many people really want to spend time programming their UIs?
I use Qt myself and one of the best things about the framework and toolkit is the UI tooling that allows me to drag and drop and visually create my UIs in the UI Designer app.
I find that for any non-trivial application this type of boilerplate is best done with good tooling that just works and lets the UI to be knocked up fast and efficiently.
I also wrote an UI system for my game engine but it's completely drag & drop in the editor. Styling (skinning) is also via UI builder.
Question, how do you handle arbitrary clipping masks ? In my solution clipping masks require evaluating all the widget parent's clipping rects and writing them to stencil buffer before rendering the current widget. This is unfortunately quite slow...
> I use Qt myself and one of the best things about the framework and toolkit is the UI tooling that allows me to drag and drop and visually create my UIs in the UI Designer app.
But then it's not trivial to write responsive/adaptive applications. In contrast, QML makes it extremely easy to build such apps.
I used to build UIs in the designer as well[1] but after studying QML there's no going back. Here's a new project I program solely in QML (and C++ for the logic)[2].
Nice to see someone taking a swing at a C++ GUI framework. Implementing a real on is not for the weak. If it's really works, it'll be expensive to license.
As someone who lives and breathes QT at the moment - what would you says the main differences are? What does Brisk offer that QT doesn't and vice-versa?
Though unfortunately since it's not lGPL or MIT, it doesn't look like I could use it anyways.
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.
I don't want to be a party pooper here, but, I am so that's how it comes out.
In code declaration of user interfaces was old hat in Qt, and wxWidgets
Why no interpreter? Recompiling to fritz with UI is just a bore.
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.
I see that WebGPU is used so it is a good candidate for being tried in https://exaequos.com, the OS I am creating and that fully runs in the web browser
While I welcome new cross-platform GUI Frameworks, I wonder why not use a declarative UI similar to QML? Even Slint[1] (which is built in Rust) uses such syntax for its UI.
[1] https://slint.dev
I've only dabbled a bit in 3D graphics (OpenGL, THREE.js, swift SceneKit). When these 2D GUIs say "GPU-accelerated", does that mean they are doing the same thing you would do for 3D - build triangular meshes, materials, etc - and then just essentially point an orthographic camera at this "scene"? Or what kind of low-level GPU APIs (eg WebGPU) are used?
I think it just means the texture image for the widgets are loaded into gpu memory space instead of a traditional framebuffer that gets copied to the gpu.
I dabbled in 3D for a while too and was astonished how much 2D stuff there is for it.
How well integrated with the underlying platform is it? For example, on Windows do you take advantage of accessibility APIs for things like screen readers?
I don't think open source GUI toolkit developers should be expected to handle accessibility until OS vendors spend some of their billions of dollars to develop a reasonable cross-platform API.
If you are creating tooling for people to create GUIs, it should always be possible to make those GUIs accessible. I’m not saying this one doesn’t—I don’t know if it does—but in the general case it absolutely should. Not everyone is going to bother, but not even giving people the ability would be deeply irresponsible.
Why should OS vendors spend money devaluing their product? It's up to the cross platform software developers to make abstractions that work across platforms, not on platform developers to make things that work on other platforms.
Just seems absurd.
Nice project! Do you think you'd ever support a "live preview" or "hot reloading" of the UI or is that beyond the scope of the project?
All those naked 'new's in the example make me nervous. I see that the library uses exceptions, if one of the widget constructor throws while composing the overall widget hierarchy, it would leak memory.
You should be able to make it work with a value-based interface and allocating behind the scenes (this would also enable a few optimization opportunities).
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?
Since it's cited as cross-platform, including non-Windows screenshots would be helpful https://github.com/brisklib/brisk#screenshots
Also, I wasn't able to readily find any information about keybindings for the widgets, e.g. the way some frameworks use "&Monday" to make alt-m act on that checkbox https://github.com/brisklib/brisk/blob/v0.9.3/examples/showc...
I did see your "unhandled" event handler doing its own keybinding dispatch <https://github.com/brisklib/brisk/blob/v0.9.3/examples/calc/...> but I hope that's not the normal way to do keybinding
I spent a very long time giving SolveSpace a native Haiku UI. I'm going to keep doing this kind of thing because there's nothing I personally dislike more than apps that don't use the platform's native UI.
I don't care that my approach is harder for the developer, because the thing I care about is consistency and convenience for the user.
I know the thing you built is neat (I've spent quite a few years working on almost the same thing), but I guess this is why I gave up on pushing my own solution
” nothing I personally dislike more than apps that don't use the platform's native UI”
I’m not sure if this is universally applicable dogma. Games generally apply their own UI regardless of platform.
Web apps generally do as well.
I do realize there is space for apps with least surprise per platform, but it’s not obvious to me if an app benefits from platform standard UI any quantifiable way.
They said “apps,” not games nor websites
App usability and performance typically benefit greatly from using the native platform they’re running on. Plus all the egress savings of not shipping chromium with every download
This looks really good. It's nice to see some options like this (and slint) appearing for cross-platform desktop GUI. I'm pretty skeptical of "modern" c++ but this looks like a good example of using it where it makes sense.
The data binding looks particularly clever. That's usually the Achilles heel of GUI toolkits (for me at least) and that looks like a clever and novel solution if it works.
The one thing I have to wonder is:
I use Qt myself and one of the best things about the framework and toolkit is the UI tooling that allows me to drag and drop and visually create my UIs in the UI Designer app.I find that for any non-trivial application this type of boilerplate is best done with good tooling that just works and lets the UI to be knocked up fast and efficiently.
I also wrote an UI system for my game engine but it's completely drag & drop in the editor. Styling (skinning) is also via UI builder.
Source:
https://github.com/ensisoft/detonator/tree/master/uikit
Live demo:
https://ensisoft.com/demos/ui/game.html
Question, how do you handle arbitrary clipping masks ? In my solution clipping masks require evaluating all the widget parent's clipping rects and writing them to stencil buffer before rendering the current widget. This is unfortunately quite slow...
> I use Qt myself and one of the best things about the framework and toolkit is the UI tooling that allows me to drag and drop and visually create my UIs in the UI Designer app.
But then it's not trivial to write responsive/adaptive applications. In contrast, QML makes it extremely easy to build such apps.
I used to build UIs in the designer as well[1] but after studying QML there's no going back. Here's a new project I program solely in QML (and C++ for the logic)[2].
[1] https://github.com/nuttyartist/notes
[2] https://www.get-vox.com/
Nice to see someone taking a swing at a C++ GUI framework. Implementing a real on is not for the weak. If it's really works, it'll be expensive to license.
As someone who lives and breathes QT at the moment - what would you says the main differences are? What does Brisk offer that QT doesn't and vice-versa?
Though unfortunately since it's not lGPL or MIT, it doesn't look like I could use it anyways.
> Though unfortunately since it's not lGPL or MIT, it doesn't look like I could use it anyways.
Why not. They also intend to have a commercial license. Don't event want to consider paying?
"However, for those who wish to use Brisk in proprietary or closed-source applications, a commercial license is also available."
Unfortunately there is no public information on the pricing.
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.
I don't want to be a party pooper here, but, I am so that's how it comes out. In code declaration of user interfaces was old hat in Qt, and wxWidgets Why no interpreter? Recompiling to fritz with UI is just a bore.
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.
Great job, looks like a huge amount of work.
To make it really declarative and exception safe, you need to wrap widget creation in function and return smart pointer.
I see that WebGPU is used so it is a good candidate for being tried in https://exaequos.com, the OS I am creating and that fully runs in the web browser
Incredible to see people working on this so kudos
Why would someone use C++ and not Rust in 2024? Familiarity and experience?