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

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.

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

    [profile.release]
    opt-level = "z"
    lto = true
    overflow-checks = false
    codegen-units = 1
    debug = false

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 {}
        }
    }

You can also experiment with the inlining threshold:

    export RUSTFLAGS+=-C inline-threshold=0

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.

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.

- 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)

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.

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.

So like a web app.

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

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

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

Why do you suppose this in particular?

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

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.

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

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?

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.

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

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

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.

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.

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 )

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.

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.

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

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

* multi-line text

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

* RTL and maybe vertical layout

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

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.

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

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

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

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

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.

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

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 :)

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.

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.

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?

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

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.

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.

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.

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

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.

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.

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.

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!

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.

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.

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'm pretty fed up with Qt and I'm getting kind of excited to start experimenting with this.

> 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?)

> 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.

Curious also if there are plans for Python API's

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.

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 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.

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.

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?

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...

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.

> Free for non-commercial use.

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

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

Fits easily in 128kb boards

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

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

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.

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

Are you planing a C interface?

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.

Mmmm no thanks, I'll pass.

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

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?"

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.

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

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