Slint GUI Toolkit
github.com
github.com
EDIT: Much of QML code from Qt's latest releases is compiled to C++.[2]
[1] https://imgur.com/a/CAJhg69
[2] https://www.qt.io/blog/the-new-qtquick-compiler-technology
The Equivalent to QAbstractItemModel is the slint::Model class[1]. That API is actually easier to use as it simple indices instead of the concept of QModelIndex/QPersistentModelIndex and 4D tables of tree of table. And it has sensible default implementation that works consistently. Since it is a template class, all the types are checked at compile time instead of wrap all data into a QVariant and hope the view will interpret it correctly. Slint is also compiling everything to C++ (or whatever language you use Slint with), and it doesn't have the legacy of having to support JavaScript with dynamic typing and garbage collector.
[1] https://slint.dev/releases/1.4.1/docs/cpp/api/classslint_1_1...
How is the text manipulation support in Slint? Does it support Rich Text content?
BTW, the ListView linked from the article you mentioned leads to this page: https://slint.dev/releases/1.4.1/docs/slint/src/builtins/wid...
Thanks for reporting the broken link. Fixed in https://github.com/slint-ui/slint/commit/9200480b532f49007d2...
*And there's much more not in the video
I made a video to showcase it a little bit better: https://www.loom.com/share/79bbfce7feb44631a3ddfb1f229bf141
Still, Slint looks very promising! I might even convert to it in the future when it matures.
The LSP extension for VSCode seemed to have some stability issues as well.
I ended up rewriting the project using egui and found it pretty pleasant. With this said I hope slint succeeds!
More generally, I get the impression that the current state of the art in cross-platform desktop-first UI development leaves a lot to be desired, so, tentatively, I applaud any and all efforts in this space, especially the ones that attempt to implement something from the ground up, rather than introducing unnecessary layers of leaky abstraction.
Slint is under multiple licenses. The GPLv3 and also the Slint Royalty-free license.
For desktop applications, The Royalty free license is actually less restrictive than the LGPL since you can do static linking and don't need to share the modifications.
For embedded products, the LGPLv3 can often not be an option anyway, and we hope that users can find our pricing model better the one of Qt.
For commercial projects, the online form https://slint.dev/get-price (from https://slint.dev/pricing page) automatically sends an email with pricing info (no marketing person is involved :) ). Note: you need to enter your business email in the form.
- Qt is a C++ framework for C++ developers, its language bindings for other languages, are second-class citizens and not truly idiomatic (I know, I've made bindings for Rust before). C++ may not always be the optimal language for writing GUI application logic. Slint is designed with a smaller API surface and improved bindings for multiple programming languages. (eg, we don't duplicate half of the C++ stdlib) With our JavaScript binding, we are a good lightweight alternative to Electron.
- The Slint language is using static typing, and each file is self-contained, simplifying tooling. We already offer IDE support with the language server protocol, featuring a Live Preview. We're also developing a WYSIWYG editor. Catching errors at compile time is better than at runtime.
- Slint is optimized to work on less powerful hardware devices, even supporting micro controllers with less than 300K of RAM, while Qt require 100 or 1000 times that amount)
- As a young and small company, every customer is invaluable to us. We are offering personalized support and implementing features to allow for the product of our customers. Even small customer receive the attention they deserve.
- In general, Slint is what we think QML could be without its legacy, by starting afresh. We acknowledge that this is an ambitious project that will take time to mature, but we encourage you to give it a try.
Slint's web target does completely custom rendering of its UI components to an HTML canvas element. This will never look or feel like a real website - where the browser can use native controls and native keyboard shortcuts. This also makes the browser's dev tools totally useless, and obfuscates how websites work. And this page is completely invisible to screen readers.
If I'm on a mac, I expect that in a text box, all my mac specific keyboard shortcuts should work (cmd+arrow keys, cmd+A, copy/paste, etc). This page doesn't support any of those shortcuts. If I'm on mobile, I expect text input controls to use my configured keyboard and autocomplete. I haven't tried, but I suspect none of that works either.
This is fine for embedded devices. And maybe desktop apps, where you at least know the OS and you can set up keyboard shortcuts to match. But in a web app, its truly awful. Its like all of electron's jank backported into the browser. Don't do it.
> Web: In Progress. Slint apps can be compiled to WebAssembly and can run in a web browser. As there are many other web frameworks, the web platform is not one of our primary target platforms. The web support is currently limited to demo purposes.
Is it not good enough?
Sometimes, it's useful to have a quick and dirty GUI toolkit. I think Slint fills that gap.
I also don't know why anyone would want a bulky DSL to declare a GUI. Declaring a GUI is the easy part. It's attributes and data that mostly don't need to be changed by the user. Just call C++ functions to get the data into the library.
When DSLs start to come in to play you have an entire secondary language to worry about. Everything from parsing to type conversions to character sets to byte codes is suddenly a potential problem and it doesn't need to be because it doesn't solve anything difficult in the first place.