iced VS fltk-rs

Another thing to note is that Iced.rs is very much in early and active development. While it’s absolutely possible to build basic apps with it, the ecosystem isn’t particularly mature yet. Besides the docs and examples, at this early stage, it’s a bit rocky to get started, especially if you’re trying to build something complex.

I originally had this idea to learn rust a little better by making a cross-platform pokedex with [iced](https://github.com/iced-rs/iced). I'm not sure if I will end up making that, but now I'm focused on making a wrapper for the API that can use different HTTP clients like [ureq](https://lib.rs/crates/ureq) for sync, and [reqwest](https://lib.rs/crates/reqwest) for async.

Iced https://github.com/iced-rs/iced

Or do you prefer Rust-only toolkits ? Those are not so advanced yet, but egui and iced look promising. Also have a look at "are we gui yet"

Hmm I'm not seeing similar memory usage on my Mac. I believe this could be related to iced.

Not too difficult, essentially you will need to implement two traits from iced, one to handle the rendering of the component and one to handle events i.e mouse events/keyboard events. You can use an existing component as a template and modify it to your needs.

2- I used iced and it's nice and generally easy but the GUI ecology in rust is still in development.

What's written in this article isn't the development of a GTK fork, but some reasoning for exploring alternatives to GTK. There aren't very many suitable candidates in this space, but Rust GUI toolkits like Iced have potential. Personally, I would add that OrbTk is also a suitable candidate.

But I could also be way off-base here! I only looked into it briefly. And I imagine what you have planned for this would be bigger than the functionality currently present. In any case, thanks for sharing. You might also be interested in iced, which provides an Elm-inspired API for web/GUI dev... except it uses the dodrio virtual DOM on web builds.

try https://github.com/fltk-rs/fltk-rs, support everything you need. highly composable, fits with GL based randering and WGPU as well.

fltk-theme is a theming crate for fltk-rs (the gui crate).

FLTK

fltk-rs is a crate that provides high-level Rust bindings for the FLTK Graphical User Interface library.

Sorry I just saw this, here is a guide to crosscompiling fltk apps: https://github.com/fltk-rs/fltk-rs/wiki/cross-compiling

fltk-rs is a Rust wrapper for FLTK, the gui library. FLTK itself offers 4 basic themes (schemes) which are wrapped by fltk-rs. fltk-theme offers extra color and widget themes which attempt to mimic several known platforms themes, in addition to some extras. You can check some screenshots in the repo's README: https://github.com/fltk-rs/fltk-theme

But becuase all of our messages are enum variants, we need to pattern match. The thing is, as our app grows in size, and we have 50, 80, 300+ different kinds of unique message variants, this pattern matching become increasingly cluttered and hard to navigate. Take this segment from the fltk-rs calculator example, where we handle messages sent by the various calculator buttons to mutate a value:

I'm working on implementing a Drag and Drop system in my fltk-rs app, and in order to do so need some way for each draggable parent widget to "know" about the nodes in a droppable widget. Having access to a graph structure becomes even more important when we consider that their might be droppable widgets within droppable widgets, and that some droppable widgets might also be draggable widgets (see this example made with react-beautiful-dnd example).