Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Slint – A declarative UI toolkit for embedded and desktop (slint.dev)
291 points by ogoffart on June 19, 2023 | hide | past | favorite | 148 comments
Slint is a declarative GUI toolkit written primarily in Rust, with API support for multiple programming languages such as C++ and JavaScript. It is designed for desktop and embedded usage.

The Slint website has just been redesigned. And we added a new Royalty-Free License option besides GPL and commercial




I just spent the last two weeks choosing an embedded ui framework and then building out a little demo to test out its capabilities. I settled on Slint and have been very impressed with the design of the domain specific language they came up with. It’s small, simple, powerful and easy to learn IMO. The vs code extension for real time gui feedback is amazing. I’ve used swift ui before and Slint is as much of a joy to use. This is a breath of fresh air compared to Microsoft’s Windows Presentation Foundation that took me years to master.

My only concern is optimising for binary size. My little microcontroller only has a measly 1MB of flash storage and I’m already at 900kb on a 15 screen app with no icons or images. It would be nice to know what actually uses up all that space (as little as it is). Perhaps I need to use ui element virtualisation or something.

Edit: 1kb of flash -> 1MB of flash


Thank you for your comment and feedback! I'm glad to hear that you have chosen Slint for your embedded UI framework and have been impressed with its design and ease of use. Feel free to post on Github for issues or discussions.

I assume you meant 1Mb of flash and not 1kb of total flash :-) We might find some way to optimize the generated code to reduce the binary size further.


Yes, I meant 1MB, typo! Thanks I’ll engage on GitHub. :)


Out of curiosity, 1kb of flash storage sounds quite tiny for a chip which is expected to provide GUI capabilities. Can you provide more information about the context?


Typo, I meant 1MB. The actual specs are 1MB flash, 564KB sram and around 500Mhz mcu speed. I’m using the STM32H735G-DK development board which comes with a few bits extra to drive a 4.2” lcd screen directly. There are already demos for it in the Slint repo which is why I chose that hardware in particular.


I assume you're already doing this since you're on a microcontroller, but have you set

  [profile.release]
  codegen-units = 1
  lto = true


This is what I found to reduce code size the most for the 8bit AVR MCU:

    [profile.release]
    opt-level = "z"
    lto = true
    overflow-checks = false
    codegen-units = 1
    debug = false
Also invoking cargo with: cargo build --release -Z build-std=core -Z build-std-features=panic_immediate_abort

You must then implement panic handling yourself:

    pub mod std {
        #[lang = "eh_personality"]
        #[no_mangle]
        pub unsafe extern "C" fn rust_eh_personality() -> () {}

        // panic can be replaced by abort with the panic_immediate_abort feature.
        // -Z build-std-features=panic_immediate_abort
        // This saves space by getting rid of the unwinding.
        #[panic_handler]
        pub unsafe fn panic_impl(_info: &::core::panic::PanicInfo) -> ! {
            loop {}
        }

        #[no_mangle]
        pub unsafe extern "C" fn abort() {
            // blink led
            loop {}
        }
    }
If I still have some room in the flash, I will make some led blink with a noticable pattern on abort.

You can also experiment with the inlining threshold:

    export RUSTFLAGS+=-C inline-threshold=0


Yes I’ve tried these things and more (like setting the opt-level to “z”). I don’t think that this is a show stopper, probably just a recent regression that will be fixed easily since this is all open source and the GitHub issue tracking is very active I see. If I were to hazard a guess it’s probably some small code gen change that results in mostly duplicated code for some ui primitive. But, it could also be me doing something stupid ;)


ELI5 what this does?


The lto setting controls the -C lto flag which controls LLVM’s link time optimizations. LTO can produce better optimized code, using whole-program analysis, at the cost of longer linking time.

The valid options are:

    false: Performs “thin local LTO” which performs “thin” LTO on the local crate only across its codegen units. No LTO is performed if codegen units is 1 or opt-level is 0.
    true or "fat": Performs “fat” LTO which attempts to perform optimizations across all crates within the dependency graph.
    "thin": Performs “thin” LTO. This is similar to “fat”, but takes substantially less time to run while still achieving performance gains similar to “fat”.
    "off": Disables LTO.
Basically, increases performance at cost of compile time. Great for release builds, not so much for debug builds (because most of the time that rustc spends is on linking anyways.)


Also, codegen-units = 1 disables some compiler parallelization which means it can find more optimizations, including for size: https://nnethercote.github.io/perf-book/build-configuration....


I wish that there was some GUI lib dedicated to small embedded systems, I just want to draw some buttons and sliders without eating hundreds of flash/ram...


This was our aim with Slint


Have you looked into fltk-rs?


looking at required dependencies it couldn't even run on the microcontroller


Some popular embedded display controllers have commands to draw primitives.


I'm essentially looking for something like imgui but with ability to draw directly to framebuffer. I looked at egui but that has same issue.


Imgui doesn’t write to a framebuffer, it records GPU commands. Really embedded MCUs don’t have space for a framebuffer either, a technique used is filling a line buffer on a timer interrupt and driving the lcd off that. The gui has to be written quite differently.


Beefier display modules will have a framebuffer inside so you don’t have to mind the timing, even if you still have to transfer the image line by line because a full screen buffer (at the full colour depth) may not fit into the microcontroller’s own RAM. It would actually be interesting to do some sort of IMGUI for this kind of environment, that would perhaps rerun the display function multiple times per screen update, once for each line where a widget’s bounding box starts or ends.


The comparison sections are very confusing. It says you will compare your UI toolkit with, for example, Flutter and then there is no comparison there at all. I thought the site is broken on mobile, I tried different browsers, etc, because the comparison was just not there.

If you don't have any real content there because you don't want to start a flame war, you could try something like what the Flutter team did, they have an "onboarding guide" for XYZ developers that builds upon things you already learned in other frameworks and explains the key differences without coming off as hostile towards the other frameworks.

https://docs.flutter.dev/get-started/flutter-for/react-nativ...

I'm a Flutter developer by day and Rust enthusiast by night, and I'm looking for a "good enough" Flutter alternative that uses Rust.


This is what I do:

- Write the backend in Rust

- Write the UI in Flutter

- Tie them together using gRPC. You get an API and ability to run client and server on different machines as well

I looked at the flutter to rust bridge and started to play with it, but assuming your UI can withstand the slight overhead of gRPC I found it a simpler way to proceed (although I'm not that far in yet)


I have the same but I wouldn't recommend gRPC. It adds a ton of overhead and complexity that you don't want. Plus you have to deal with all the complexity of Protobuf and the fact that everything becomes `Option<>`.

Instead I wrote my own RPC system using Serde and Bincode. Communication is over stdio, that way you can support SSH access extremely easily (like VSCode remote).

Unfortunately it was for a company so the code isn't public, but there really wasn't much code to the RPC system at all since you don't need to worry about versioning, authentication, transport, etc. I write a very simple schema language, used Nom to parse it and generate Rust, Typescript and Dart code. The Rust code generation is trivial since you can just `#[derive(Serialize...]`. Typescript / Dart was a bit more complicated (you have to implement Bincode) but it's not very difficult really.

By far the most complex thing is trying to integrate with SSH. If you call `ssh` directly then you end up having to parse non-machine-readable prompts and errors and so on. But if you use a proper SSH library then you end up having to implement ssh-agent, read `~/.ssh/config` etc. yourself which isn't fun either.


This is interesting enough I want to look into it if nothing else than for the geek/cool factor, but the thing I like about gRPC is it gives me layer I can let my client consume as an API (although REST is likely sufficient for this). I actually have an internal API and then two little shim/wrapper layers over the top: one for gRPC and one for REST. My UI consumes the gRPC API. I also want my Rust server to have an independent lifetime from the UI so it can do work in the background. I suspect my use case is just a little different.

NOTE: I found this crate that would likely help with Dart codegen of message types: https://crates.io/crates/serde-generate. While stdin/out wouldn't likely work for me, I could use a TCP socket bound to localhost or named pipe as alternative for the transport piece.


I'm looking at something similar with Go as the backend. Why gRPC instead of a pipe? I started with that as well since it was really easy to set up but that comes with the caveat of requiring network permissions even though it's local to local communication.


Pros and cons: with a pipe it will be up to you to create your own message delimiters and protocol, so a pipe is somewhat lower level. You also limit comm. to just that machine, but that may be a pro if that is what you are looking for (omits need for things like username/password or locking to 'localhost'). Lastly, you do not gain an API for your users to consume (if that makes sense for your app - it doesn't always).


Protoc actually generates "writeDelimitedMessage" and "readDelimitedMessage" functions for each type. The only thing I needed to add was some buffering on the Dart side to ensure the full message was available. The Go side was able to read the stream and block until input became available


Interesting - so you are using protobuffer encoding over a named pipe?


Yes but just over stdin/stdout since I'm creating the backend as a subprocess. Not sure if it makes more sense to have the backend be the parent and the flutter app be the subprocess but this is working so far.


> You get an API and ability to run client and server on different machines as well

So like a web app.


Yes, nothing to stop you from substituting Flutter for your frontend of choice including a web-based SPA, but then you would need the gRPC-web extension to call gRPC from a browser. The Rust Tonic crate has this available for the server side.


Have you seen flutter_rust_bridge? I use that to write business logic in Rust, if I need to use Rust crates. I did that recently for a CRDT library called Automerge.


Not a Flutter Dev, but have you tried 'flutter_rust_bridge' [0]. Seems provide some interop between flutter and rust and looks like a popular and active project. I'm native mobile dev and just curious about this kind of interop myself. If it's seamless then looks like good balance to do mobile front-end in flutter and mobile backend in rust.

[0] https://github.com/fzyzcjy/flutter_rust_bridge


Cool... was just thinking one could use flutter's web target with tauri's interop and host model.


Thanks.. This is a nice reference for an onboarding guide.. We could add a similar section to our documentation page https://slint.dev/docs


Made a similar comment about the comparison pages, which is a simple and factual statement yet was downvoted immediately by (pressumably) people with a stake in the project. Does not reflect well...

Detailed and unbiased comparisons are extremely useful but also are hard (and costly) to do. Don't promise them if you can't deliver.


Not sure why or who downvoted.

We will add more detailed comparison in our documentation. Thanks.


> (pressumably)

Why do you suppose this in particular?


my lack of imagination as to what might be otherwise motivating HN members to "engage" in this way :-)

I mean I can't imagine anybody having an independent interest in the project (like I do) and actually thinking that the comparison provided was adequate.

As said in my original comment, this is an area where a sense of sub-optimal status quo is palpable and people search for some sort of rationalization of the various nascent possibilities and options. Just a few days ago somebody was talking "parallel futures" (in mobile context) [1]

[1] https://news.ycombinator.com/item?id=36340925


People downvote perfectly reasonable questions or comments here plenty often. And even more pile on if you dare to call this infantile behavior out.


Wow, that Flutter Doc page is beautiful... and seems fairly comprehensive, kudos to them.


Looks really nice!

I used to work in the Medical Device, Bio Tech & consumer device space (~10 years ago), good toolkits for building embedded interactive UIs were few and far between. The idea of having one codebase for both an embedded UI on a low spec device and for a mobile app is really compelling.

I could see a dev kit, based on an existing dev-board and screen, running JS with bindings to this, as a great way to do rapid prototyping and development. Then being able to take that and optimise down to lower cost production hardware.

As with all these toolkits, when it comes to the web and doing rendering via a HTML Canvas you end up with accessibility problems. Not though a fault of not considering it, but its not something you have to consider for an embedded device at all (or you do but it's built from scratch for that specific device). Unfortunately the APIs are just not there yet on the web platform to open up accessibly of these sort of UIs.

I suspect the key selling point of the web version is building demos and simulators for design validation. It makes it super easy to distribute to projects stakeholders and focus groups. We did something in that area for an early version of the UI for the first version of the Bosch Robot Lawnmower, we had demo hardware on the mower, and a UI simulator written in JS. Both used the same custom built UI specification system, so we could iterate the design and demo it via the web, then built it into the embedded software for the hardware prototypes.


Thank you for your feedback! We are aware of the issue regarding accessibility when rendering via HTML Canvas on the web platform. Our web version of Slint is mainly, as you guessed, designed for demo purposes. While it would be possible to write a backend that uses the DOM, we haven't done it yet because our focus is currently on embedded and desktop.


At some point I'm planning to work on a web backend for AccessKit. I know that creating a parallel DOM for canvas-based web applications doesn't solve all accessibility problems, but it'll at least be better than nothing.


Looks nice, but actually the per/appliance pricing could be a bit clearer, I hate the Call Us type pricing pages, that is usually where I rather look for the competition...

(Just had some hardship with finally getting an atrociously expensive quote after spending workdays of providing the needed inputs to a HW vendor)


Disclaimer: I work for Slint

I suppose you are referring to the "Embedded Add-on per application" pricing? At least the non-commercial use is hopefully clear :)

Yes, we need find a better way to show the pricing there since it's dependent on 2 variables - volume and type of embedded system. Maybe some sort of a online calculator?


What exactly is a 'user'? Literally one device running the application? In that case the pricing does seem a bit steep in a small business context.


A user is a person (eg. a developer or a designer etc.) using Slint to build the GUI.


Ahh, it makes this much more reasonable.

The enterprise pricing made me thought at first that the cost is per application user. (Making enterprise lisence more appealing) … of course per end-user pricing would be way too expensive.


We changed the term from "User" to "Seat" and added an entry in the FAQ section to avoid confusion.


I always assumed "call us" pricing was to give a salesperson the opportunity to negotiate the best deal for the seller.


I always read "call us" as "tell us how thick your wallet is".


For early stage products, it's often more like "we have no idea how to price this and we don't want to publish it yet".

You can basically come into those calls and name your price or walk away.


I would think they want to hear what your device sells for. If you're going to charge me $1 per unit on something that costs only three figures, I'm telling you to take a hike.

Qt hasn't quite learned this. Their embedded pricing is absurd.


Yes, I was thinking of that part, as this kind of stack would make a lot of sense for commercial application.

Just made an appliance using a Web technology for the frontend, as the licensing situation was a nobrainer, and we could focus on delivering value instantly, using proven technology, instead of wasting time on negotiating on terms for something this basic element of the project. I mean if I need an LCD screen or a CPU, I don't negotiate, just go to a retailer, and check their prices and availability, and order&pay. No multiple round interactive sales process needed for something that is just a stock item, no customization needed, etc. Also the per-customer pricing seems potentially a bit discriminatory to me.

So an online calculator would be great, it would instantly let me know if your product suits outr business.

For example with the relatively low volume electric part I have mentioned above I had to make several hoops, provide lot of redundant paperwork, and nag the salespeople for weeks to provide me at least a quote the vendor could have already put on their site, as their competitors do. (This vendor has some niche differentiator aspects which made us focus on them first, not on larger volume ones). They wasted a lot of our time and our project was stalled until we got responses from them, and the prices seemed irrationally high, feeling almost as if they didn't want to sell that piece to us from the start. This is what I feel whenever I see Call Us for a quote, as this was not a unique occasion.


The widgets examples do not look good, unfortunately.

Let me elaborate: they seem aliased (everything looks like sampled with nearest neighbor), spacing is non-uniform and overall the style chosen looks somewhat outdated.


Just to clarify: are you talking about the image next to Desktop in https://slint.dev/use-cases#desktop-applications ? Indeed, we'll improve on that. Thanks for your feedback!

For the story, we initially had screenshot of an actual commercial desktop app, but we were asked to remove it by the author until the app is actually released. So we went with that set of of widget instead, which is a prototype of the Cosmic style for Pop!OS)

Edit: We changed the image. (for reference, the previous image was https://slint.dev/assets/img/cosmic_de_popos_light.png )


I am not a designer (not for 20 years now) but that desktop image (rotating gif of different styles) is not a good advert. There are many, many layout issues with those that I would really spend time to try and make "default" look right out of the box (and in line with platform HID guidelines). I am a Rust developer, and I think Slint could be amazing, but those things will put off people who are driven by design quality.


Thanks for the feedback. We will try to get some designers to improve the widget gallery examples.


I'm always happy when a new GUI toolkit comes out and Slint looks really well done, especially if you like QML. I could imagine using it if I do another embedded or kiosk application.

However, I find the modern flavor of "declarative" is not really for me. QML, Slint, and to some degree XAML and SwiftUI are all like this. They mix widgets with layout elements and presentational elements (like rectangles). There is no separation of content and style. Another smaller problem is that the initial layout is done in the markup language, but any runtime additions have to be done in another language (if at all possible).

In my ideal GUI, you could say in code "give me a detail-item view" or "this pane shows the detail of the selected item from this pane", and then have it layed out according to platform standards, possibly completely different on iOS or on Windows. But then you could go in and customize the placement and look&feel of every element with CSS if needed. Either applying platform styles ("default inset border") or completely custom styles.


Separating content and style does not really have a purpose in GUIs. A lot of people who come from HTML assume it does because HTML does it, but HTML does it because it's for documents, where it does have a purpose. It's got nothing to do with declarativeness; everyone does the same thing because it works and the other way doesn't solve problems.

The only non-DOM-based library I know of to use separate stylesheets is JavaFX and it's one of the biggest reasons people hate it.


This looks really neat, I played with it a bit and the DSL is well thought out.

One thing I can't figure though: how do we set default values for internal Struct?

Said default values are mentionned in the documentation (here: <https://slint.dev/releases/1.0.2/docs/slint/src/reference/ty...>).

  // ok even if a is missing, it will just have the default value


Currently the default is just whatever empty value for that type (so 0 or "")

But since this is something that was asked before, I created an issue: https://github.com/slint-ui/slint/issues/2936


Neat!


Correct and complete text handling is hard. Does Slint handle (did a cursory search in the docs but couldn't find anything that hints at an answer):

* multi-line text

* languages that use non-Latin characters, as well as mixing them in the same control

* RTL and maybe vertical layout


Correct text handling is indeed a challenging task, especially to get all keyboard shortcut to edit and input methods. While we strive to improve our text handling capabilities, we are not perfect yet.

Slint does handle multi-line text and languages that use non-Latin characters. However, we currently do not support vertical layouts.


How’s accessibility? Does Slint play well with things like screen readers?


We do have initial support for screen readers. That’s using accesskit, or Qt when using the Qt backend.

It’s still basic, some controls like text input need work, or customizing the focus chain.

Building blocks are there and will need further polish.


The examples start up promisingly fast. Faster than Uno, IMHO, and waaay faster than Qt (on WebAssembly I mean).

Great to see competition in this space; I'm sure they'll all benefit in the long run.


"Achieve low footprint and minimal resource consumption. The Slint runtime fits in less than 300KiB RAM..."

Well done! This is exactly what we should be better at, ship less bloat and set a higher standard.


The band is not that bad as well https://en.m.wikipedia.org/wiki/Slint


Nice to see that Qt finally gets some competition! The pricing alone is a no-brainer. Now the only thing I'm missing from the demos is smooth scrolling :)


If you target desktop only probably Qt license (LGPL 3.0) is easy to use even in commercial projects. The problems comes if you want to target embedded, mobile platforms especially iOS or require some of their GPL modules (e.g. Charts, Data Visualization)

Otherwise Qt is probsbly much more mature project and already has unofficial rust bindings


The current main problem is that Qt often releases new modules under GPL and commercial only licenses. For example, the new Qt GRPC implementation and then it is all or nothing. Qt commercial would force us to essentially buy two licenses because we have a second app that acts as a third party dll loading app. These dlls often crash and thus we moved them into a dedicated app we could simply restart, but Qt license would force you two buy two licenses only because they talk to each other. So, no thank you Qt we will stick with LGPL for now, and move to something else in the future. See my blog post "Current Issues With The Qt Project - From The Outside Looking In" [1].

[1] https://kelteseth.com/post/20-04-2023-current-issues-with-th...


I think you have misunderstood the Qt licensing model when you say that you need two Qt licenses if you are building two separate applications?

The commercial licenses are a) per developer and b) per distributed device (if you distribute your software as part of a device), there is no per application licensing requirement.


> An application using Qt Commercial must not communicate with any another application using Qt LGPL-3.0 or Qt GPL, if both applications run on the same device. This is more restrictive than GPL.

https://embeddeduse.com/2023/01/06/using-qt-5-15-and-qt-6-un...


The context there is "combining commercial and free open-source Qt licenses"; if you are using either commercial or open source licenses exclusively, there are no such restrictions.


Not to diminish Slint authors work, but it is still far from being Qt competition, given the current state of accessibility, IDE integration, or graphical tooling for UI/UX designers.


Disclaimer: I work for Slint

Indeed we are actively working on all of those topics:

Accessibility support in Slint is improving. We just merged the initial AccessKit integration into our winit backend -- https://github.com/slint-ui/slint/pull/2865

IDE integration - our VSCode extension is pretty stable these days (https://slint.dev/get-started#vscode) and we also support integrating into other IDEs via LSP (https://slint.dev/get-started#other-ide)

Graphical tooling for UI/UX designers - our current prototype https://slintpad.com needs more work to become an easy Drag n'Drop editor for UI/UX designers -- but we are on the right path to achieve that :)


Slint is already a viable alternative to Qt, as evidenced by users actively choosing us over Qt. While Qt is more mature in many areas with its two decades of development and large team, Slint is already good enough for some use cases. And as a young framework, we naturally strive to improve.

By the way, when it comes to IDE integration, our VSCode extension and LSP server, which includes live preview, put us on par with Qt's.


Sorry but that isn't the same thing, you're even reckon that is only some use cases, not all of them.

Using VSCode is hardly comparable to QtEditor alongside Qt Design Studio.

So yeah it might be a viable alternative to those that aren't even aware of what a full installation of Qt brings in the box.

While I don't doubt Slint will eventually reach that level, we are comparing 1.0 release with 6.5 and related tooling.

By the way, madnirua's answer was more in line with the reality and it was appreciated.


Disclaimer: I work for Slint

Thanks. We have a lot of users who are migrating from Qt/QML to Slint.

The smooth scrolling part -- is that for the wasm binary or for a native application?


Wasm in Firefox.


I can't find it now, but I remember looking at slint a few months back and finding out that native widget support on the desktop required QT. Is this not true?


Qt is only needed if you want native looking widgets. Otherwise, another style will be used for widget, which does not look native. In the future, we plan to have native backend using the native API, which will allow native widgets without using Qt.

Reference: https://github.com/slint-ui/slint/blob/master/docs/install_q...


There is often a criticism of Javascript, that new frameworks seem to appear every week. But it honestly feels like every week on HN there is a new Rust UI project showing up. Whether it is some new HTML/web thing, a native app thing, a TUI thing, etc.

Don't get me wrong, I think that is the sign of a very healthy ecosystem. I am just curious how the Rust evangelists will spin this. Somehow this constant churn on the Javascript side is worthy of snide, satire and ridicule.

IMO, UI development is deceptively hard. Rendering scalable graphics efficiently is hard enough. Creating a good layout engine and a set of reliable basic controls is even more difficult. But managing interfaces seems to scale quadratically with the number of controls, views, states, etc. I see programmers, over and over, underestimate how difficult of a task managing that complexity can be. This complexity leads to difficult to use libraries/framework/platforms. It also leads naive and ambitious developers to believe they can do better. This leads to more and more new libraries/frameworks/platforms.


It's a somewhat hot area of development and there isn't a clear winner yet, so of course there are new projects all the time.


Slint has been around for quite a while now. A few years ago it was called SixtyFPS.

I used it for a cross compiled Windows app (did 99% of the development on macOS) and it was quite nice. It was a little limited as far as widget customization went (without getting down and writing your own widgets from scratch) but app ended up looking nice and behaving decently. It also lacked a few features I'd say were essential for any non-small desktop app (multiple top level windows weren't a thing a year ago, not sure if they've been added yet).

I quite liked their DSL for the UI scripting. It was even typechecked a bit and interfaced with Rust in a fairly clean way. It's one of the nicer UI libraries I've used in a while.


All of these rust libraries and frameworks are in their infancy and there are no clear winners yet. Its probably less of a sign of a healthy ecosystem, and more of a sign of an immature ecosystem. There are a few projects that seem promising, but all of that could be invalidated by next week.

Meanwhile in the js ecosystem things are both incredibly stable and also in flux. All of the usual suspects are still around, but competing in ways intergrate both server and client rendering as seamlessly as possible. There is also some movement around introducing optimising compilers - see solid and svelte.

But its probably safe to say, ignoring the tooling churn going on with Rust, Go, and Zig seemingly systematically replacing all js tooling like for like, things are pretty stable when it comes to js ui libraries.


While there are a lot of Rust UI frameworks, none of them are really recommended for production use yet. I suspect a few of the will die off and work will coalesce a few once things mature a bit.

Another nice feature of the Rust UI ecosystem is that lots of it is being built in a modular way. For example I maintain a layout engine [0] library which just does layout and can be easily integrated by anybody creating a UI library. And there a bunch of similar composable libraries covering rendering, text layout, accessibility, window creation, clipboard access, etc.

[0]: https://github.com/DioxusLabs/taffy


> Somehow this constant churn on the Javascript side is worthy of snide, satire and ridicule.

In my experience it is frontend devs, not backend devs, who are most harsh on Javascript's procession of UI frameworks. Rust users are more than happy to take inspiration from Javascript UI frameworks, if for no other reason than the reactive/declarative approach is a better fit for Rust than the prevailing inheritance-heavy/object-oriented approach of Qt and GTK.


>>" Rendering scalable graphics efficiently is hard enough"

As a not-UI dev guy, what will be awesome is when a stack solves the scaling/swiping.

Imagine being able to swipe a UI from one UX to another UX -

I See my blood pressure on my E-watch... I swipe right to throw that details onto my laptop... ... I swipe up to throw that shit on the EMR at the doctors office...

Or I have a vitals monitor on my watch and when the ambulance picks me up they can just slurp my historics via my watch and an AI starts doing prognoses asap.

Those who do this, win all the money. (not to mention the threat this is to HOSPITAL CODES or INSURANCE PAYMENT CODES) -- Yeah those bitches will be upset when this happens.


Nobody expects you to go and learn this week's Rust UI project, or to abandon last week's one.

If go looking for a job, you will discover the people working with Rust UI hire Rust developers, not Tokyo (yeah, that one was many weeks ago) ones or whatever else. Those developers are expected to be able to learn and adapt to whatever framework the place uses.

All of that is completely opposite to how things happen with Javascript.


it’s a different situation though: very few people have shipped guis in Rust, so the Rust projects are largely greenfield, while a lot of JavaScript front ends are legacy apps.


I'm a total laymen on the embedded side, and as such I think this looks great and the GPL and permissive licensing options are a very welcome and (IMO) fair way to engage and empower the community.


Nice!

I have been using libQt since the last millennium for different projects, this looks more like how I use it as I never really liked QML.

But the comparison page vs qt is a bit thin, what do I gain here and how do the features compare?

It works be nice if the page was more fleshed out in that respect.

It's so refreshing when new stuff comes out for native and not just web web web!


Thanks :)

Since Qt is a much broader toolkit, we are considering of writing dedicated blogs to do an objective comparison between the two toolkits on the GUI part only.


Please do!

And, speaking as a Qt programmer, address the biggest pain points that Qt user have.

Number one: get a virtual keyboard that supports the biggest world languages without a commercial license. That would make me an instant convert.


Thanks :)

For the short term, we have an example that some of our community users and commercial customers a using to build their custom virtual keyboard

https://github.com/slint-ui/slint/blob/master/examples/virtu...


I'll try it out, thanks.

I'm pretty fed up with Qt and I'm getting kind of excited to start experimenting with this.


> Create your application under MIT, BSD, Apache 2.0 or any of the other GPLv3 compatible licenses, provided that the complete work is made available under the GPLv3.

> Create your application under a license of your choice, open-source or proprietary, provided that the application includes proper attribution to Slint and retains copyright notices. I've listened to at least one (or two?) podcasts on slint, and I'm still not sure that I understand the license options, which makes me hesitate to invest time to learn.

I usually use the MIT license. Is the first license above compatible with MIT, without requiring forks (of my project) to GPL3 their code?

Does the latter license mean I can closed-source and commercialize my app and just include a shout-out to Slint and I'm good? (EDIT: if so, why would anyone choose the potentially expensive commercial option?)


Forks of your project do not require open-sourcing their code if they adhere to the terms of the royalty-free license, which include attributions and excluding usage on embedded devices. (Alternatively, they can get a paid license)

> why would anyone choose the potentially expensive commercial option

The paid option is for those using Slint in embedded devices (which is not permitted by the royalty-free license) or for those who prefer not to include attribution to Slint in their program.


The GUI space is crying out for more workable approaches so fresh takes are more than welcome. But going through the website the comparison with other existing options (Qt, Electron etc) is mainly schematic one-liners, good for marketing but not particularly informative.

Curious also if there are plans for Python API's


Thank you for your comment!

I acknowledge that the comparisons on our webpage footer is primarily for marketing and SEO purposes. This is inspired by the equivalent content on websites like figma.com. The intention is to highlight Slint's unique selling points without delving into extensive discussions about other frameworks.

And yes, we do have plans for Python, that would actually be the next language we want to make bindings for.


The in-browser demos (using WebAssembly) are surprisingly fast and responsive (very different from the Flutter demos that I remember). Very cool!

Also, I just realized I had checked out this project before when it was still called SixtyFPS, https://slint.dev/blog/sixtyfps-becomes-slint . Maybe it would make sense to mention the name change in your post.


It has been over a year since we renamed the project. We previously had a note on every page with the former name. But the new website design no longer includes this note.


I understand too little about GUI Toolkits to have a strong opinion on the technical merits, but as a music fan, I appreciate the name.


Thanks.. Probably we should name our major releases after some of the band's titles :)


Ignoring for a second that "Slint" is only slightly better than "60fps" as a name for a GUI library, I think using a custom domain specific language for configuration is a giant mistake.

It really is not difficult to just call functions to set values. Laying out GUI components is also rarely what takes time when doing GUI programming.

A brand new custom domain specific language has almost no benefits but has huge downsides like having to learn brand new syntax, complete with error messages and debugging. Then you probably have to change GUI values dynamically anyway inside your program. All of this is on top of the added bloat, which itself is strange for a 'embedded usage'.

I think a lot of newer GUI libraries would be better off porting FLTK to work on their platform, it is very simple and easy to understand underneath.


DSLs are not inherently more difficult to learn than API and conventions of a complex GUI library. DSL offer benefits in terms of expressiveness and conciseness. The focus in UI programming is on rapid iteration and immediate results, which can be facilitated by a live preview in the IDE made possible by a declarative DSL


DSLs are not inherently more difficult to learn than API and conventions of a complex GUI library

In theory maybe, in practice the indirection and extra layer of syntax, error handling, documentation and edge cases mean this is not true. Also this is an assertion without any evidence.

DSL offer benefits in terms of expressiveness and conciseness.

Prove it.

The focus in UI programming is on rapid iteration and immediate results

I have never thought that setting up values through functions was not rapid. It has never been a bottleneck or time sink when making a GUI. Unfortunately, using custom markup languages that don't work like they say they should has been a time sink.

which can be facilitated by a live preview in the IDE made possible by a declarative DSL

My experience is that this is very minor in terms of overall utility and doesn't actually require a custom markup language.


An UI framework in 2023 needs two things: one line animations and a gorgeous starter template.

The inconvenient truth is that there are way more good coders than there are good designers so coders need all the help they can get to sell their product and make good ux choices.

Any comments on how it compares on those fronts?


We do have one line animations [1], we do have starter templates[2]. But not sure what you call "gorgeous".

I 100% agree with the need of good designers.

[1] https://slint.dev/docs/slint/src/reference/animations [2] https://github.com/slint-ui/?q=template&type=all&language=&s...


Wether it's fair or not.. I generally compare any given UI framework/toolkit to mui.com (Material-UI) component library. They've solved a lot of the issues I've had, nice to work with and in general really well-rounded components. Would love to see an equivalent with Yew or similar, maybe integrated like Tauri.

In the end, I think that accessibility is a really hard thing to get right. As are the base components that are generally needed for applications. This is a nice start, and for lighter/embedded it could be nice. I'm not sure that I'd reach for this ahead of Flutter, React(-Native) or alternatives that are more polished for general use though.


What's the catch? There's always a catch, like "turns out it's just WebView" or "turns out only the android and Linux CDE implementations actually exists" or "call us for pricing"


Looks like "Call us for pricing":

> Free for non-commercial use.

> For commercial use, the runtime fee is based on volume and type of embedded system.


We plan to add a pricing calculator later, replacing “Call us for pricing “


The link to Javascript at the bottom of this page is broken: https://slint.dev/releases/1.0.2/docs/slint/. It goes to https://slint.dev/releases/1.0.2/docs/nodejs/ which gives a 404.


Here is the correct link

https://slint.dev/releases/1.0.2/docs/node/


Thanks for reporting. Will fix that.


If you need something written in C and very tiny, I recommend LVGL https://lvgl.io/

Fits easily in 128kb boards


The toolkit still seems quite incomplete for desktop use (as opposed to embedded/appliance UIs), as it doesn't support menu bars in an issue open since 2020: https://github.com/slint-ui/slint/issues/38


A comprehensive toolkit like Slint is an enormous and ambitious task. We prioritize feature implementation based on user demand and needs. As of now, we haven't received any specific requests from users for the menu bar feature, but we know it is important (we filled the issue ourselves)


What is a "menu bar?" Something other than a regular application menu?


The toolkit doesn't support regular application menus or right-click menus.


That's a pretty big problem.


You should give us educators a free license :) I'd use this in my classes if I could.

I'm keen to use it with c++ and rust


It looks like you can use the GPLv3 license for this use case.


Unrelated, but a song by the band was in the 'BlackBerry' movie.

https://www.youtube.com/watch?v=CuqEpjcBfaU


Is it named after the band?


Just a nice co-incidence :)

The toolkit was initially named SixtyFPS and was renamed to Slint last year --https://slint.dev/blog/sixtyfps-becomes-slint

The name comes from our design goals - Straightforward, Lightweight, Intuitive, Native Toolkit.


Well, I'm still gonna listen to Spiderland because you reminded me, so thanks for everything.


Tweez is my favorite album of theirs, though Spiderland is excellent.


Scorching take. Tweez is nowhere close to spiderland. Now hurry up and get me some new headphones Steve, they're fucked.


If youre reading this, go listen to spiderland by slint. Awesome and super unique album


I’ve always hoped that HN was a place that appreciated music like Slint, now I have my answer.


Do you support any kind of integration with Vxworks 7 on some platform ?

Vxworks has some Rust support so I wonder if you already had some integration with vxworks drivers


We investigated integration VxWorks as part of a customer request and we concluded that all the required hooks exist to support Slint.


Thanks for the answer !


Do I need to use rust or cpp? Can I work in js only? I like the slint layout files and the viewer.

Are you planing a C interface?


You don't need c++ or rust if you want to work with JS. (although right now you will need a rust compiler to compile the binary, but we want to ship binaries in the future)

We are considering a C interface, but given we already have a C++ interface, we don't see much gain in having a C interface compared to the effort to maintain it.


>Attribution to Slint

Mmmm no thanks, I'll pass.

While I'm looking for a Flutter alternative, this seems like a trap.


We are not a charity and aim to operate on a sustainable development model. While we offer paid and GPL licensing options, we also provide a free-of-charge license that only requires attribution. If you are unwilling to provide even attribution, then Slint may not be the right choice for you.


Oh it's certainly not for me, no question about it.

Yet, it's curious that you compare Slint to LVGL/Flutter/Electron (I don't know about Qt) when none of them have this intrusive requirement.

--- >What's intrusive about it?

(a) Display the AboutSlint widget in an "About" screen or dialog that is accessible from the top level menu of the Application.

(b) Display the Slint attribution badge on a public webpage, where the binaries of your Application can be downloaded from, in such a way that it can be easily found by any visitor to that page.

(c) You may not remove or alter any license notices (including copyright notices, disclaimers of warranty, or limitations of liability) contained within the source code form of the Software.

(d) You allow SixtyFPS to use your Application on the website and in advertising materials of SixtyFPS as a reference and to display your logo and trademark for this purpose.

---

Please don't pretend like a/b/d aren't big asks by saying "you wont even provide attribution?"


Not a dev, but I've often seen software that acknowledge their dependencies in About sections and on their websites. Is that particularly intrusive? Especially given that you could always use the GPL too if you want.


This goes beyond that. I didn't see that list of requirements; some places only say "attribution."

I would have no problem listing a library in the About dialog, but dictating the use of special icons and then all of those other requirements goes further than I've seen in any similar product.


Funny how they claim the toolkit is responsive, but then their website isn't.

The "Used by" section overflows and basically breaks the whole website.


Probably because we are using HTML and CSS instead of Slint :)

Jokes aside .. which browser and device combo are you using.. We can adjust the css accordingly. Thanks.


Pixel 7, Chromium.

I think the issue is with one of the logos at the bottom




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: