141–150 of 152 posts
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.
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
What is a "menu bar?" Something other than a regular application menu?
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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
Earlier quoted context omitted.
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…
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.
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
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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.
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…
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.
Earlier quoted context omitted.
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.