tronical

…which appears to wrap the png crate. (Good, so not a rewrite)

On macOS and Windows, the menubar is native. On Windows, context menus are, too. On macOS it‘s a small patch away, we just haven‘t gotten around. (https://github.com/slint-ui/slint/blob/7bb333c77dd477f8625c8... )

Shout out to the muda folks here and big thanks to npwoods :)

What’s the difference between having your data in an AWS data center versus having it in Hetzner’s data center from the point of view of “private data in cloud”?

(Good move IMO nevertheless)

If you scroll all the way down, you can see at least a similar look of “the band” :)

The closest I can think of is for you to insert one or multiple soft-hyphens.

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.

We're working on interop, so that when you select Slint's Skia renderer on top of Vulkan or Metal, you can import a wgpu texture if wgpu's Metal or Vulkan adapter was chosen.

What kind of feature set do you need?

A typed and tooled (lsp, live-preview, etc) DSL for the UI and Rust/C++20 APIs, compared to C APIs.

You might find this article helpful from my colleague Tobias: https://slint-ui.com/blog/rust-and-cpp.html

We're not trying to be clever, TBH. There are many excellent alternatives out there in the Rust world. Our choice of Rust is primarily a technical choice, and later we found out that it's also a fantastic community to be part of.

Most of us have our roots in the open source world, many (most?) of us learned coding because we were able to look at open source code, make changes to it, recompile and play with it.

We're trying to give back to the open source community and at the same time earn a living by asking the people who use Slint for proprietary apps (i.e. not giving back) to support us by purchasing a license.

I think the distinction that you may be missing is between software generally licensed under the Apache license and software that is part of the Apache project and governed by the Apache Software Foundation. The latter may choose not to include GPLv3 software in their project, but software outside of the ASF umbrella that's licensed under the Apache license can be combined with GPLv3 software.

SixtyFPS GmbH | https://slint-ui.com/careers.html | Berlin/Germany | Embedded Software Development (Rust and C++) | Remote(EU) | Fulltime | 40k-70k€

Slint is a toolkit to efficiently develop fluid graphical user interfaces for any display: embedded devices and desktop applications. Slint supports multiple programming languages, such as Rust, C++, and JavaScript.

SixtyFPS GmbH is the company behind Slint that provides the toolkit under a dual-licensing scheme: via Open Source on GitHub or via a commercial license for proprietary applications.

We're a small startup of passionate engineers - we enjoy innovation, being a part of the wider Open Source ecosystem, and learning.

We're looking for a passionate engineer to work in our team, developing Slint.

You can also learn more about what we do on our blog: https://slint-ui.com/blog/ Our source code is on https://github.com/slint-ui

No :)

Short of building distribution packages and offering those as binaries for the download, this seems like a simple way to offer a download.

It's not perfect though, and I think we're going to try to create binaries for download alternatively.

One of the lesson that I believe is being learned is that general purpose programming languages for UIs make it difficult to do tooling, especially with dynamic typing.

This particular approach (.60) is not a general purpose programming language and it's strongly typed.

It's designed for the user interface, not for writing the rest of the program in it.

I feel this is rather different from the tcl/tk applications we used to see?

No worries :)

Maybe it could be brought over the top by compiling Qt to wasm and mixing that in. A bit tricky with the emscripten runtime vs wasm32-unknown-unknown target mixing of Rust though ;-).

Jokes aside, we added this embedding because of a specific user need.

Python should be fairly straightforward to do.

Golang with the interpreter we well, but the RealThing(tm) would be a full code generator and binding to the runtime library. That would be awesome, but a little bit more work.

I quite like Go, it’s simplicity and GC is really convenient.

Sad to hear that it’s not fluent for you :(

We went for dual licensing (GPL / commercial) in hope of creating a sustainable project.

We do have basic focus handling but the demos don’t really try to show that off - that’s more tailored towards touch based input at the moment. But we’d love to have a17y, full desktop like tab focused etc.

Regarding the compilation: the ability to live preview individual components or the entire design and seeing changes being applied on the fly (we have an interpreter for that) speeds the ui dev cycle a lot. Give it a try :)

Lsp can be used with any IDE, better markup language (static typing, proper module concept), rust and JS APIs, markup compiled to proper C++/Rust AOT, compiler can do asset optimizations (todo) - for example:).

In short: we try to do one thing (UI) and do it well :)

We try hard to avoid that. No magic context properties, good modularity across files (js module concept). Easy to write components. But there is more work to be done.

The software is not built on Qt. The compiler and runtime is written in Rust (Qt is C++), the renderer is a lightweight GLES 2.0 renderer and winit is used for window creation and events.

The runtime’s API is available as plain C++ API (only depends on C++ standard library), JS api in node (via neon) and Rust natively (simply a crate). It’s generally rather lightweight in terms of its surface. Instead the focus is on our compiler generating API for the input design files, to make it easy to manipulate properties or feed data models into the UI.

We’re internally using QStyle calls to produce images of controls when selecting that kind of styling at compile time, but that’s entirely encapsulated. The style you see in the wasm demos for example is entirely done using GLES accelerated primitives (such as SDF based anti-aliases rectangles).

Cool! I’d say that’s the very low end for us, but we think that it should be possible to create decent UIs also for such configurations. It would require additional work for us to target that right now but we’d be happy to take that offline. Drop us an email at [email protected] please if you’re interested:)

Hi ddeck!

We need to make our description a bit more precise - and we're working on comparisons. In terms of pure RAM usage (as opposed to ROM) in our experience the display resolution contributes a lot to what's left (unless there are dedicated frame buffers). So if you mention <= 64kb RAM, what kind of displays are you typically dealing with?

Generally I think we're aiming a little above LVGL/uGFX in terms of configuration, but also with with a much richer UI / features.