[HN Gopher] iced 0.14 has been released (Rust GUI library)
___________________________________________________________________
iced 0.14 has been released (Rust GUI library)
Author : airstrike
Score : 35 points
Date : 2025-12-07 21:27 UTC (1 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| andsoitis wrote:
| Repo: https://github.com/iced-rs/iced
| andsoitis wrote:
| _Inspired by The Elm Architecture, Iced expects you to split user
| interfaces into four different concepts:
|
| State -- the state of your application
|
| Messages -- user interactions or meaningful events that you care
| about
|
| View logic -- a way to display your state as widgets that may
| produce messages on user interaction
|
| Update logic -- a way to react to messages and update your state_
| k_bx wrote:
| The COSMIC DE (by System76, default in Pop_OS distro) is written
| using their iced fork, which hopefully will be upstreamed
| eventually.
| sho_hn wrote:
| Why did they fork it?
| tomnipotent wrote:
| The last iced release was September 2024, more than a year
| ago. I imagine they had constraints that made it impossible
| to wait for upstream patches to be merged (if at all) and it
| was simply more tenable to fork and worry about merging
| later.
| airstrike wrote:
| They have needs that are specific to COSMIC, so they maintain
| a separate fork, but they update their fork to match the
| latest upstream release.
|
| They also contribute to iced indirectly via cosmic-text and
| other crates.
| nicoburns wrote:
| I believe it's a soft fork where they're treating Iced as
| upstream. Having their own fork just means they can land
| changes quicker.
| wonklebonkle wrote:
| Iced is a wonderful dead-simple framework. I hope it forever
| maintains the simplicity which combines nicely with Rust's
| features.
|
| One thing I love about Iced and miss in Qt is writing the
| software in a single language. Qt has chosen to introduce
| multiple languages into their framework which makes the entire
| codebase a huge learning curve. In Qt you write your display
| layer in QML then your UI logic in Javascript and any backend
| advanced logic in C++. It is frankly exhausting.
|
| In Iced you write in Rust and use Cargo packages. This gives the
| developer ultimate composability and clarity of their application
| as well as powerful tools from an established ecosystem. If Qt
| wanted to provide a powerful Qml tool, they have to write it and
| build all of the IDE integration.
|
| For the record Qt used to be moving in a pure C++ direction but
| that changed when Qml came onto the scene.
| dotancohen wrote:
| I write all my Qt in Python. I've never used the C++ bindings.
| But in Python you don't need to deal with QML or JavaScript.
| wonklebonkle wrote:
| Are you writing QtWidgets or QtQuick in Python? My
| understanding is that QML is mandatory for QtQuick apps.
| dotancohen wrote:
| I use QtWidgets. I've never touched QtQuick.
| amelius wrote:
| I did some Qt programming in Python (PySide6), but ran into
| segfaults, which should of course not happen no matter what
| you do in a scripting language (except when using modules
| like ctypes). Many of these cases were related to object
| lifetime handling which is difficult to do correctly in Qt,
| and many people have written about it. In Python (a garbage-
| collected language) one should not have to worry about this.
| ktpsns wrote:
| Haven't used Qt for a few years, but back then QML, QtQuick,
| etc have been optional features. You absolutely could write all
| your Qt logic in C++ only, in a somewhat similar way like the
| code shown in the iced READMEs. It is the same in any other
| classic GUI toolkit such as GTK+.
|
| Biggest drawback in qt/c++ used to be the MOC. I guess they
| still have not gone rid of it, haven't they?
| rubymamis wrote:
| I actually love that separation. QML is a great language for
| writing beautiful, responsive, modern UI with animations
| easily. C++ is great for performance and logic. I don't like
| Javascript but I don't need to write a whole lot of it. I wrote
| my note-taking app's block editor in QML and C++ if some people
| are curious[1].
|
| [1] https://rubymamistvalove.com/block-editor
| dotancohen wrote:
| I've got a stagnating Python Qt app prototype that I need to
| actually write properly. It's a personal project so I can do that
| without affecting users. I need to decide between Rust and Iced
| or stick with Python and Qt.
|
| Python has a VLC library that embeds VLC behind the scenes for
| audio playback, and Qt had facility to work with it. This is
| terrific as I need to support a wide variety of codecs (voice
| recordings) and I need to change playback speed during playback.
| Does Rust or Iced have such capability to embed VLC? Not the VLC
| UI elements, just to use VLC behind the scenes.
| thorn132 wrote:
| This might be what you're looking for: https://docs.rs/vlc-
| rs/latest/vlc/
|
| There's also PyO3 for using Python libraries from Rust, if no
| bindings or substitutes are available.
| lazypenguin wrote:
| I think the Rust community is sleeping on the potential of iced
| for traditional desktop gui. I monitor the gui space in Rust
| closely and have seen many toolkits come and go. In my opinion a
| desktop gui library/framework needs to solve two things to be
| useful: architecture and advanced widgets.
|
| egui has served me well and is eagerly recommended in "what gui
| should I use" threads since it solves the widget problem well in
| an easy-to-use package. However, any sufficiently advanced
| application ends up needing a nice architecture to maintain
| development speed and enjoyment. I've found whether using
| egui/slint/fltk/etc. you end up having to roll your own system.
| When you start needing things like undo/redo you suspiciously
| start architecting something that smells like the elm
| architecture.
|
| Iced is the only Rust toolkit that I track that solves the
| architecture part upfront. The message pattern is hugely powerful
| but it is hard to appreciate until you've really gotten in the
| weeds on larger applications. Once iced reaches a point where
| there is an advanced set of widgets available I suspect its
| popularity will rise accordingly.
|
| As a comparison, one of the most successful desktop gui toolkit
| of all times (Qt Widgets) solved the architecture/widget duality
| long ago with the signal/slot system and advanced widgets like
| treeviews, datagrid, etc. Since then we must have had hundreds of
| "desktop" toolkits across all languages that can draw buttons and
| dropdowns but nobody has toppled the king yet for building
| advanced desktop GUIs (although there were a few close
| competitors in C# with WPF and Java with Swing they only solved
| the widget part in my opinion). I like to think iced can take
| this mantle one day, best of luck to them and congrats on the
| 0.14 release.
| avtar wrote:
| For anyone curious about accessibility support, looks like it's a
| WIP with contributions from System76 staff <3
| https://github.com/iced-rs/iced/issues/552
|
| And TIL about AccessKit https://github.com/AccessKit/accesskit
___________________________________________________________________
(page generated 2025-12-07 23:00 UTC)