The declarative DSL for defining user interfaces reminds of QML and I'm not sure why I would use this over QT really given that Slint seems to have a similarly weird licensing model.
Most of this codebase seems to be Rust. I'm not sure how good the Qt/Rust experience currently is; there might well be room for another player in that space.
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 non-commercial and personal projects, the runtime licenses are free.
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.
Slint author here. Allow me to share a few reasons why we believe choosing Slint over Qt:
- 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.
Thanks for creating slint! Qt still has not delivered on the promise of rapid prototyping with qml, after 14 years. The biggest issue I see is that half of the Qt devs themselves do not like qml. See my rant I wrote a while ago: https://kelteseth.com/post/20-04-2023-current-issues-with-th...
Urgh. Cool demo, but to everyone considering Slint - please don't make general purpose websites using tools like this.
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.
That's awesome. Seems like Slint is growing healthy! I like programming with (Qt) C++ and QML, so I'll stick with that. Although, Qt's bloat is a downer.
What's the current story on how it maps to system accessibility mechanisms? The high-level components for marking objects up with accessibility data look fine.
Depends on the backend.
With our main backend (the winit backend) it uses AccessKit [https://github.com/AccessKit/accesskit]
With our Qt backend (used for the Qt native style on Linux), it uses Qt accessibility infrastructure.
I think Slint is neat, it seems to have learned from both the best desktop toolkits and web development. QML, in contrast, is much heavier, uses a full JS interpreter, but still doesn't reach the same kind of ergonomics as VDOM web frameworks for dynamic state management (though its layout options are better than even modern CSS). Sadly I mostly make web UIs nowadays, so I haven't had much use for it.
I love programming with QML. And it's real fast if you combine C++ and QML the right way. I use `QAbstractListModel` on the C++ side and my views are in QML. It allows me to create an advanced block editor[1] that is much more performant than anything out there (Notion etc, even more than native macOS apps like Bike).
EDIT: Much of QML code from Qt's latest releases is compiled to C++.[2]
As others have pointed out, Slint is inspired from the good parts of QML.
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.
Yes. At least in my opinion. The entire view is reactive via bindings which is pretty incredible alone. Animations are super easy to do. And there are many other benefits. I'm not affiliated with him, but I really like his QML course if you want to check it out: https://www.udemy.com/course/qml-for-beginners. He also has some free Youtube videos on the topic.
I only develop for desktop, so not that interested in animation and prefer to stick with the standard desktop styling. But will make a note for the future. Thanks.
You are basically loosing on ~15 years of evolution in the way GUI are programmed.
The "reactive programming" pattern that QML introduced with its property binding is really powerful and is what every new UI framework do nowadays. QtWidgets library only got the minimum of updates to be still relevant.
Sadly, the story of QML on desktop is not really optimal.
Your example looks indeed very nice! But what I'm doing is entirely different. Each component is formed of the same Block component. They're not separate but rather all part of the same ListView. Each block can be dragged and dropped anywhere. The Kanban tasks support drag and drop. The entire editor support from scratch Undo/Redo, copy/paste, Markdown formatting (upon changing cursor position), multi-block selection and edit (quite a difficult problem, especially with rendered HTML, and Markdown/Plaintext underlying), and much, much more. All of that while loading War and Peace under 0.78 seconds on a 2016 Macbook Air.
I don't know why anyone would name their project "slint" (or its previous name "60fps" which made no sense).
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.
I used Slint recently and don’t think it’s quite ready for me. It doesn’t support recursive types in the DSL, so trees have to be represented as a flat array. It’s also not possible to combine certain AST elements like an `if` and `for` loop.
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!
40 comments
[ 4.8 ms ] story [ 96.0 ms ] threadMore 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.
- https://github.com/slint-ui/slint/blob/master/README.md
Is it not good enough?
Sometimes, it's useful to have a quick and dirty GUI toolkit. I think Slint fills that gap.
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.
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.
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!