Our great sponsors
-
Slint
Discontinued Slint is a toolkit to efficiently develop fluid graphical user interfaces for any display: embedded devices and desktop applications. We support multiple programming languages, such as Rust, C++ or JavaScript. [Moved to: https://github.com/slint-ui/slint]
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
iced
Blazing fast and correct x86/x64 disassembler, assembler, decoder, encoder for Rust, .NET, Java, Python, Lua (by icedland)
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
The most recent time I evaluated Iced (Aug 2020), it didn't support any of my Linux machines due to broken/non-existent OpenGL support. With the progress the wgpu renderer has made, I'm pleased to report the situation has improved, although on Linux my initial attempt landed me here: https://github.com/hecrj/iced/issues/1013
I've had no issues with Iced on any other platforms, fwiw.
It looks like there are actually 3 different pricing/license options. https://sixtyfps.io/#offering
- GPLv3 - free
- "Ambassador" - free commercial license (after approval), in exchange for marketing as being built with sixtyfps and authorization to use your logo and feedback
- Normal commercial - paid
I kinda like the addition of the "Ambassador" tier. Seems like a fair exchange for an in-development framework, and would be a good option for people that are building a new product and don't yet have enough revenue to cover the cost for a prototype.
An unfortunate name clash with one of the best x86 decoders I've ever used, also written in Rust[1].
[1]: https://github.com/icedland/iced
For those (like me) just hearing about AccessKit, I assume it's this: https://github.com/AccessKit/accesskit
Neat! I really like the Rust ethos of creating modular cross-platform adopters (e.g. winit, getrandom), and from a brief skim this seems to fit that model.
Well, Tauri (or more specifically the 'ri' part: https://github.com/tauri-apps/wry/) uses different engines on different platforms, so I assume there's the potential for quirks.
Genuine question: Does somebody understand how this compares to Druid https://github.com/linebender/druid
The iced package requires the messages to implement the Debug, Clone, and Send traits, none of which are available for closures. I was able to implement something similar to your example[0] but it only supports plain function pointers for the callbacks. The compiler wasn't able to derive a sufficiently general Debug trait for the function pointer due to an issue with the lifetime of the argument, so I had to implement that myself as well.
Incidentally, as long as there are situations where only function pointers can be used and not closures it would be really nice to have some support for anonymous function pointers in Rust (with the fn type and not just the Fn trait) so that one could write e.g. "Message(fn |c| c.value += 1)" instead of "Message({ fn f(c: &mut Counter) { c.value += 1 } f })". Or just infer the fn type for "closures" which don't actually close over any variables without the need for an extra keyword.
[0] https://github.com/nybble41/iced-counter2/blob/master/src/ma...
Redux is to React what the 'update' function is to Elm architecture (first code example in the following link)
https://guide.elm-lang.org/
Answering your question, the difference is Elm has a more expressive type system than javascript, and will catch a lot of errors for you, with excellent error reporting from the compiler.
The layout of the code becomes less important, because the compiler will catch most errors (actually recommended in elm guides not to split in too many files until overwhelmingly necessary)
You guys should also check out the femtovg project, a 2D rendering API that sixty fps relies on.
https://github.com/femtovg/femtovg
It's a decent starting point for trying to build your own toolkit.
I have recently added a wgpu backend but for now it lives in my fork https://github.com/adamnemecek/femtovg
run the demo with `cargo run --example wgpu_demo --release`.
Also join the femtovg discord https://discord.gg/V69VdVu
You guys should also check out the femtovg project, a 2D rendering API that sixty fps relies on.
https://github.com/femtovg/femtovg
It's a decent starting point for trying to build your own toolkit.
I have recently added a wgpu backend but for now it lives in my fork https://github.com/adamnemecek/femtovg
run the demo with `cargo run --example wgpu_demo --release`.
Also join the femtovg discord https://discord.gg/V69VdVu
For Python + WX, there's also re-wx[0] (shameless self-promotion)!
I wanted React with Elm-like architectures in WX enough that I got annoyed and built one ^_^
[0] https://github.com/chriskiehl/re-wx
I had my first encounter with The Elm Architecture through the Go Bubble Tea library (https://github.com/charmbracelet/bubbletea). What a revelation. Such a drastically different way of thinking about UI.
I agree with your point. In fact it's the approach I'm doing myself in my current UI lib (which has a very specific use case but the point still applies).
https://github.com/ensisoft/gamestudio/blob/master/uikit/win...
Yes! This is because web browsers use the platform text input stack
Browsers are a great example of cross-platform UI, because they sprinkle platform-native widgets throughout the canvas that they render. Which reminds me that people were trying to use webrender[1] to build native apps in Rust.
[1] https://github.com/servo/webrender