51–60 of 225 posts
Earlier quoted context omitted.
I used `iced` but admittedly I also used a lot of elbow grease. Custom Theme, custom widgets and lots of passion to get it to look Just Right.
Cool. Any publicly available source code? If not, any screenshots at least? I'm curious as what Iced is capable of (with extra widgets/themes/etc. like you mentioned).
So many UI frameworks don't have these and require building them yourself...
This is often a problem with Rust UI frameworks, they may look beautiful, but the moment accesibility becomes a requirement, the whole app needs to be scrapped and rewritten in something more mature.
Does this implement accessibility at all? This is often a problem with Rust UI frameworks, they may look beautiful, but the moment accesibility becomes a requirement, the whole app needs to be scrapped and rewritten in something more mature.
Earlier quoted context omitted.
> The other thing you can do (which is popular in the Bevy community) is to compile the "core runtime" into dynamic library. Then you don't need to recompile that set of crates for incremental builds. I'm curious as to what this means exactly. Are you saying keep the UI stuff in a separate crate from rest of app or ???. And just a separate or an actual dynlib? (wouldn't that imply C ABI? would make it a pain to inter…
An actual dynlib (containing the core framework crates that typically dont change between compiles (and which in C world might be installed as precompiled system libraries)). It doesn't necessarily require C ABI. Rust doesn't make any guarantees about stability of the Rust ABI. But if you compile the app and the dynlib with the same compiler version then it works in practice (and IIRC there are enough things relying…
However, I don't see what advantage this gives. You are going to specify that dependency in your Cargo.toml just like any statically linked crate. Anything that would invalidate the cache for a static crate would invalidate it for a dynamic linked crate. Iow, it seems like separate crates are the magic here, not the linking type. What am I missing?
Thanks for the build stats. Those are helpful. I have an M1 Max currently.
UPDATE: Good points below. As a dynlib it would create a boundary for sure (no LTO, etc.). Worth playing with, thx.
Earlier quoted context omitted.
Same model as Flutter which is a million times more pleasant to write and mature at this particular use case which I don’t actually think Rust is well suited to generally speaking.
I write both swiftUI and flutter daily. I think SwiftUI is the winner if we're going to put names forward. But arguably, not cross platform. But in terms of language adaptability for UI, Swift is king.
Earlier quoted context omitted.
An actual dynlib (containing the core framework crates that typically dont change between compiles (and which in C world might be installed as precompiled system libraries)). It doesn't necessarily require C ABI. Rust doesn't make any guarantees about stability of the Rust ABI. But if you compile the app and the dynlib with the same compiler version then it works in practice (and IIRC there are enough things relying…
I did some quick research. I knew Rust ABI was unstable, but I didn't realize you could create Rust ABI dynlib and Rust would automatically dynamically link it. For intra-app it would work just fine. Neat. Link: https://stackoverflow.com/questions/75903098/dynamic-linking... However, I don't see what advantage this gives. You are going to specify that dependency in your Cargo.toml just like any statically linked crat…
I believe it may "just" be faster link times. Which may seem minor, but link times can often dominate incremental compile times because it's a slow and (at least historically) serial step which is O(total code size) even if the actual compilation is incremental.
See mold's linking benchmarks: https://github.com/rui314/mold. It can be the difference between multiple 10s of seconds with traditional linkers vs There are few strategies for dealing with this:
1. Is just to use a faster multi-threaded linker. On Linux, lld, mold, and wild on Linux are all much faster than the traditional ld/gold (and the latter two another step above lld). On macOS, the new built-in ld64 is pretty good. Not sure what the state is on Windows: possibly lld is best?
2. Is dynamic linking as above. This seems to be faster even though the dynamic links need to resolved at runtime. I presume because at least the links wholly within the dynlib don't need to be resolved.
3. Is tools like Subsecond (https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...) which effectively implement incremental linking by diffing the symbols in object files.