Live data from Hacker News

Show HN: Slint – A declarative UI toolkit for embedded and desktop

slint.dev

111–120 of 152 posts

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#111
post #64

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 u…

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

Some popular embedded display controllers have commands to draw primitives.

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#112
post #104

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.

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

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

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#114

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 dow…

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

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#115

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?

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#116
post #8

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.

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#117

Earlier quoted context omitted.

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.

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#120

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/

Post reply on HN