20 ms·
Iced: A cross-platform GUI library for Rust, inspired by Elm
- woodruffw 5y agoAn 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 https://github.com/icedland/iced
- tomcam 5y agoHad no clue this existed. Looks like the Swiss Army knife of reverse engineering. Thank you.
- benatkin 5y agoLooks like the GUI library's crate came out first: https://crates.io/crates/iced/versions https://crates.io/crates/iced/versions https://crates.io/crates/iced-x86/versions https://crates.io/crates/iced-x86/versions I'm not sure there's a naming conflict here. There is little overlap between x86 decoding and a GUI library. If software is eating the world, then it's similar to Giant Bicycles and Giant Food Stores.
- woodruffw 5y agoI didn't mean to imply priority: a clash is just a clash, not a sign that either project isn't entitled to the name. It's just an unfortunate namespace problem: language package managers (overwhelmingly) flatten things into a single-level namespace, and so we end up with things like this. > There is little overlap between x86 decoding and a GUI library. I work on a graphical tool that visualizes x86 binaries! It uses iced (the decoder), and it could very easily end up using iced (the GUI library).
- benatkin 5y agoThe main thing I disagree with you on, is that there is a namespace collision because of the package manager, or that there is a namespace collision because both use Rust. If there is a namespace collision, it should be because they're both tools used by developers. The package manager issue is solved easily by adding something to the package name. As for the language, Rust is shaping up to be more like C++ than Ruby or Python, where the main community is more about the language and the standard library and less about the myriad different uses of it. I think both can keep their names long-term.
- ucosty 5y agoBut then you'd be obliged to call it Ice Cubed
- joseluis 5y agoicequare
- qw3rty01 5y agoThis is the project that the dnSpy author moved to!
- jatins 5y agoThat looks exciting! Congrats on the ship. Have you done any benchmarking on how this compares with Electron on things like binary size, memory usage? Those are usually most common complaints people have with regards to Electron so would be nice to see the improvements this provides.
- api 5y agoAlmost everything is smaller than Electron.
- amelius 5y agoYeah but don't forget that Electron is literally packed with features. For example it can draw SVG, it can play video, it can do 3d stuff, do networking stuff ...
- axelroze 5y agoCries in InteliJ (java) and 1GB+ ram usage.
- api 5y agoIntelliJ is a lot more than a GUI. There's a ton of language modeling and parsing and lookup stuff going on in there. It has tons and tons of features too. Electron is hundreds of megabytes for "hello world."
- rizky05 5y agoElectron is hundred megabytes runtime of 2d + 3d engine, networking, accessibility, sound, etc that you only use for “hello world”
- OJFord 5y agoThis looks great too, but just to point out if you're looking for something like Electron (but rust, or smaller or whatever) then Tauri is a much closer fit, using web stuff (HTML, CSS, JS, wasm, frameworks, whatever you want) for the UI in the same way.
- api 5y agoLooks nice, but like almost all promising new UI toolkits accessibility is not even mentioned.
- zellyn 5y agoI think everyone is waiting for AccessKit to be ready…
- paulgb 5y agoFor those (like me) just hearing about AccessKit, I assume it's this: https://github.com/AccessKit/accesskit 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.
- jamil7 5y agoVery cool, didn't know about AccessKit.
- mwcampbell 5y agoSorry folks, that's not my day job, and I haven't had much energy lately to work on it on the side.
- rauljara 5y agoThanks for the work you did do! It’s out there, so whether you finish it, someone forks it, or it just serves as inspiration for another project, you’ve contributed.
- ginko 5y agoPeople keep bringing up accessibility whenever UI toolkits are mentioned, but wouldn't it be simpler to just have a CLI interface for whatever your program is doing?
- yoz-y 5y ago
- option_greek 5y agoVery nice. If it works on mobile too, could end up being a competitor to flutter.
- lsllc 5y agoPrevious discussion (April 2020): https://news.ycombinator.com/item?id=22766639 https://news.ycombinator.com/item?id=22766639
- amelius 5y agoJust looking at the example, I notice that you have to use Enums to pass messages around. E.g. "IncrementPressed" in the example. Wouldn't it be much easier to use closures for that? Managing Enums sounds like an unnecessary administrative burden.
- Dowwie 5y agoEnums are a natural fit for event handling. If you write an api that can manage 50 different kinds of events, a single enum consisting of 50 variants would be able to facilitate that. A closure isn't identifiable to the request handler. It's just a thing that does stuff, when you're ready to call it. How do you know what stuff to do with it?
- amelius 5y agoWhat I mean is: binding an enum to an action, which then sends a message containing the enum, deciphering it and executing code based on its value, and not forgetting to define the enum somewhere, when ... you could simply bind the closure to the action. So instead of: Button::new(&mut self.increment_button, Text::new("+")) .on_press(Message::IncrementPressed) you would write: Button::new(&mut self.increment_button, Text::new("+")) .on_press(|| MY_CODE_HERE) For comparison, in JavaScript you can write: button.onclick = function(){ ++counter; } That's quite a direct way of formulating what you want to happen. All in a single line and no Enums involved.
- WJW 5y agoThe enum of all possible events is still there, it's just spread over dozens of different callback properties belonging to several different objects. Splitting out via an enum to a big `handle` type function makes it possible to detect whether you have handled all possible events at compile time instead of having to raise an exception at runtime.
- jbverschoor 5y ago
- ecmascript 5y agoLooks cool, how does the DOM updates work here? Is it possible to do whatever kind of update you want?
- clarkmoody 5y agoThere is no DOM, since this is not Web tech. GUI state mutations are triggered by messages passed around the system. Messages can be generated from user interactions for by asynchronous subscriptions (network socket, etc).
- tmccrary55 5y agoIt sure looks like it's using the DOM in the inspector. Which is cool but a custom rendered UI would be cooler.
- clarkmoody 5y agoIced can compile to WASM and be run in a browser, but that's just a single target. There is no concept of DOM in Iced itself.
- tmccrary55 5y agoAh I see what you mean.
- ecmascript 5y agoI get that, but how does the updates in the DOM work in the example? Is it possible to extend it somehow?
- z3ugma 5y agoThe more I use Elm; and the more I look at other reactive frontends like React+Redux and Vue, the more I love thinking in The Elm Architecture (https://guide.elm-lang.org/architecture/ https://guide.elm-lang.org/architecture/) aka Model-View-Update as a pattern for GUI development. To wit: Here's a way to implement it with Python and Tkinter for an old school reactive GUI. https://maldus512.medium.com/how-to-setup-correctly-an-application-with-python-and-tkinter-107c6bc5a45 https://maldus512.medium.com/how-to-setup-correctly-an-appli...
- Narice 5y agoElm is awesome! I would really like an equivalent for software/game dev
- axelroze 5y agoThe Elm Architecture is not that super novel. Actually it came from game development from the Components way of thinking. Take a look at this book. It's a classic for gamedev: - https://gameprogrammingpatterns.com/ https://gameprogrammingpatterns.com/
- tempest_ 5y agoThe language itself seems interesting but from the outside looking in it appears a bit stagnant. Is the community active at all in 2021 or is it just the result of having basically one person working on the language?
- sdeframond 5y agoI would say it is quite active, although still small. I think there is a slow shift toward community built tools such as lambdera. The language itself is pretty stable (and good, IMHO). Most of the news are available on the discourse discourse.elm-lang.org
- G4BB3R 5y agoElm seems stagnant because Evan is not so transparent and prefer work in a private branch and to release work in batches instead of having a release every 6 months, this makes people think it is dead. Elm is still being used in production by dozens of companies with huge codebases (100k~400kloc), and the community is very active, there are amazing projects like elm-pages, elm-review, elm-ui (from mdgriffith), elm-spa, elm-charts, lamdera and others.
- skohan 5y agoHow does it work? Does it render itself, or delegate to native UI components?
- fosefx 5y agoThe project is kept modular. There are renderers for web [1] and native [2]. The project's ECOSYSTEM.md [3] is addressing this in more detail. [1] https://github.com/hecrj/iced/tree/master/web https://github.com/hecrj/iced/tree/master/web [2] https://github.com/hecrj/iced/tree/master/wgpu https://github.com/hecrj/iced/tree/master/wgpu [3] https://github.com/hecrj/iced/blob/master/ECOSYSTEM.md https://github.com/hecrj/iced/blob/master/ECOSYSTEM.md
- conradev 5y agoDoes this use the text input stack provided by the platforms? Or is it parsing raw keyboard events? I only ask because if it doesn't use platform text input, that is a non-starter for mobile. It also would mean having to reimplement platform behavior for text input, like being able to hold Shift on macOS while moving the cursor to change text selection.
- ericls 5y agoThis is an important point for me as well. Not sure on other platforms, but on web, it does support composition.
- conradev 5y agoYes! This is because web browsers use the platform text input stack Browsers are actually a great example of my favorite approach to cross-platform UI, because they sprinkle platform-native widgets throughout the canvas that they render, controlled by a platform-agnostic programming language. Which reminds me that people were trying to use webrender[1] to build native apps in Rust. [1] https://github.com/servo/webrender https://github.com/servo/webrender
- arghwhat 5y agoNot using appropriate text input integration is a no-go in any platform, be it mobile or desktop. Self-implemented keyboard input pretty much only works for the simplest use case in english-native countries.
- ensiferum 5y agoWhy would a widget library need to deal with input stack directly? For portability it'd provide an API where the caller will dispatch abstract events such as mouse events and keyboard events and already translated character events.
- cmrdporcupine 5y agoIf you think it's easy to make an abstraction around keyboard events, stroll through the Chromium and Blink source tree some time and try to understand all the nuances. Keyboard and key event input is much harder than it first appears. From multiple platforms to multiple languages to multiple keyboard interface devices to multiple layouts, and you cannot assume that the operating system provides a workable abstraction on its own.
- est31 5y agoSee also: sixtyfps, which has been started by two KDE contributors. https://github.com/sixtyfpsui/sixtyfps https://github.com/sixtyfpsui/sixtyfps https://news.ycombinator.com/item?id=26958154 https://news.ycombinator.com/item?id=26958154 https://news.ycombinator.com/item?id=24919571 https://news.ycombinator.com/item?id=24919571 It's great to see GUI frameworks being designed in Rust, countering the trend of doing everything in Electron.
- adamnemecek 5y agoYou should also check out the femtovg project, a 2D rendering API that sixtyfps relies on. https://github.com/femtovg/femtovg 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 https://github.com/adamnemecek/femtovg run the demo with `cargo run --example wgpu_demo --release`. Also join the femtovg discord https://discord.gg/V69VdVu https://discord.gg/V69VdVu
- ComputerGuru 5y agosixtyfps is licensed under the GPL, so it's icky for anyone that isn't developing a GPL app and doesn't want to or can't shell out for the commercial license. Iced is licensed under the MIT license.
- ruined 5y agosixtyfps is dual-license. you can contact them and negotiate a license for commercial use. i think this is a better scheme than straight mit which accommodates no demand for financial support to the developers.
- infogulch 5y agoIt looks like there are actually 3 different pricing/license options. https://sixtyfps.io/#offering 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 the revenue to justify the cost during the prototyping phase.
- ZenPsycho 5y agountil this supports accessibility, please don’t use this
- cultofmetatron 5y agocongrats on plugging one of the biggest holes in the rust ecosystem. Looks like an api I'd love working with. Id love to imagine an alt universe where someone builds an entire desktop off this the way gnome was formed from gtk.
- Klonoar 5y agoIced is not new and has been around for some time... it's not plugging a hole in the ecosystem any more than any other framework.
- thibaut_barrere 5y agoIt is pretty cool! I would love to use that for audio programming GUI.
- O_H_E 5y agoGenuine question: Does somebody understand how this compares to Druid https://github.com/linebender/druid https://github.com/linebender/druid
- danachow 5y agoWell for one this seems to do it’s own rendering. Druid depends on a native widget toolkit.
- adamnemecek 5y agoDruid does its own rendering using piet and uses some native controls. Here's an example of Druid rendering a button. https://github.com/linebender/druid/blob/master/druid/src/widget/button.rs#L170 https://github.com/linebender/druid/blob/master/druid/src/wi...
- raphlinus 5y agoI wrote a little on this last year, mostly still valid: https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021.html https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021.... I think there are approximately five viable Rust toolkits: Iced, Makepad, sixtyfps, egui, and Druid (in no particular order). Any of these five could evolve to being a real solution, with enough investment. Of course, it's possible another could arise, or that I've given short shrift to one of the other contenders (areweguiyet has a list, but that resource is not super well maintained). There are some things easier to do in Iced than Druid (especially integration with 3D, which is something we currently don't do at all). On the other hand, we're pushing pretty hard on infrastructure: proper text handling, input methods, subwindows, etc. Currently, Druid relies on platform capabilities for 2D drawing, but my main work right now is a new GPU renderer. And we hope to work with 'mwcampbell on accessibility in the next year (integrating AccessKit). We've got a great community, but tend not to toot our horn very loudly, so people might not be as aware of the progress we're making. By contrast, sixtyfps is a commercial product (in addition to a GPL release) and has weekly updates.
- O_H_E 5y ago
- mftb 5y agoI think the example in the readme is presented and worded in a confusing way, "Finally, we need to be able to react to any produced messages and change our state accordingly in our update logic:". Since your referencing the Elm architecture, it's 1. send msg, 2. update 3. view. This is presented, 1. 3. 2. The code looks right, but the example seems out of order and consequently confusing.
- hecrj 5y agoIn a `Sandbox`, messages can only be produced by your `view` logic. An `update` does not always precede `view`. In fact, `view` is called first after initializing the application. Thus, I believe the example in the `README` is following the proper order :)
- andrekandre 5y agostruct Counter { // The counter value value: i32, // The local state of the two buttons increment_button: button::State, decrement_button: button::State, } impl Counter { pub fn view(&mut self) -> Column<Message> { ... } } this looks like it holds state in the ui layer... wouldn't it be better to keep state in some separate state/model object (struct) and bind the ui to that instead? not doing it this way couples a lot of logic/state to the ui framework which means its much harder to switch ui frameworks later, not to mention testing the logic independently of the ui choice...
- andrekandre 5y agoto whoever downvoted, instead of downvoting, maybe its better to make a counter argument? im asking because i hope to get some insight not a silent downvote
- ensiferum 5y agoI 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/window.h https://github.com/ensisoft/gamestudio/blob/master/uikit/win...
- andrekandre 5y agothats a cool game engine!
- thurn 5y agoThis type of state is typically used for "interface state", e.g. "is this toggled open", "which menu item is selected", etc. It's definitely normal to combine that with a 'database' style model layer, as you say.
- cdaringe 5y agoAgreed. This is not like elm at all. This is much more like react pre v14
- danieltanfh95 5y agoApp developers discover game programming patterns, colorized 2021
- arsome 5y agoSlowly they'll meet with the Electron people and eventually we'll reinvent Delphi and Visual Basic.
- dhbradshaw 5y agoI've been playing with the iced examples, particularly the styling example. The code is beautiful and the result is clean and responsive and fast. Love this.
- no_wizard 5y agoAny idea if mobile support is coming? That’s starting to feel table stakes as time goes on I think, even more important than desktop which can always fall back to web
- qwertygnu 5y agoI'm dislike the not-so-recent trend of companies/projects/libraries that co-opt common words as their name. "Rust" and "elm" and "iced" wouldn't normally have anything to do with computing, but it still feels like a small intrusion on our language.
- ryanianian 5y ago> it still feels like a small intrusion on our language. All languages evolve over time, despite official bodies trying to reject foreign influence. (IIRC the French government has a department that tries to limit loan words from other languages, but good luck with that given the internet.) So what's the actual problem with it? Only downside I see is google-ability and occasional conflicts when two projects use the same name. Both of those exist with any naming Scheme (ha!) and imho haven't really ended badly for projects or their users.
- alpaca128 5y agoYou mean like Apple, BASIC, Lisp, Explorer, Safari, Chrome, Android, ...? This practice has existed from the start and I don't see it as an intrusion into the language. We humans are able to consider context (which is necessary for language either way), and that mostly takes care of it. When someone says "I've got rust on my PC's power supply" or "my python escaped" it's still very obvious it's not the programming language. And an outsider might have trouble following the conversation, but that would happen no matter what words are used. Whether we say "Elm" or "C++", the target audience knows what's meant and others wouldn't be able to follow either way.
- chubs 5y agoWorth mentioning: cryptowatch's great desktop app uses this, it's worth trying as an example of how efficient iced is, i like it: https://blog.cryptowat.ch/sponsoring-rust-gui-library-iced/ https://blog.cryptowat.ch/sponsoring-rust-gui-library-iced/
- ComputerGuru 5y agoThe 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 https://github.com/hecrj/iced/issues/1013 I've had no issues with Iced on any other platforms, fwiw.
- ghgh8888888 5y agohhg
- slmjkdbtl 5y agoI like how the next thing you do after "inventing the universe" is "bake an apple pie"