8 ms·

Iced 0.14 has been released (Rust GUI library)

113 points by airstrike 11mo ago

k_bx 11mo ago
The COSMIC DE (by System76, default in Pop_OS distro) is written using their iced fork, which hopefully will be upstreamed eventually.
- sho_hn 11mo ago
  Why did they fork it?
  - tomnipotent 11mo ago
    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.
    - tuananh 11mo ago
      they had release just yesteday but yeah, it's quite long between releases. https://github.com/iced-rs/iced/releases/tag/0.14.0 https://github.com/iced-rs/iced/releases/tag/0.14.0
      - tomnipotent 11mo ago
        For perspective Cosmic DE went from Alpha 1 to Beta 1 in that same timeframe.
  - airstrike 11mo ago
    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 11mo ago
    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.
andsoitis 11mo ago
Repo: https://github.com/iced-rs/iced https://github.com/iced-rs/iced
andsoitis 11mo ago
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
wonklebonkle 11mo ago
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 11mo ago
  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 11mo ago
    Are you writing QtWidgets or QtQuick in Python? My understanding is that QML is mandatory for QtQuick apps.
    - dotancohen 11mo ago
      I use QtWidgets. I've never touched QtQuick.
  - amelius 11mo ago
    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.
dotancohen 11mo ago
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 11mo ago
  This might be what you're looking for: https://docs.rs/vlc-rs/latest/vlc/ https://docs.rs/vlc-rs/latest/vlc/ There's also PyO3 for using Python libraries from Rust, if no bindings or substitutes are available.
  - dotancohen 11mo ago
    Nice, thank you! I see grt_rate() and set_rate() methods, so that might just work. I'll be setting up a prototype soon, much appreciated.
lazypenguin 11mo ago
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.
- bikelang 11mo ago
  In case you’re not aware - Pop!_OS has built their cosmic desktop environment on top of iced.
  - Klonoar 11mo ago
    On their fork of Iced. They contribute back but it’s a notable distinction.
- satvikpendem 11mo ago
  Alternatively, Flutter desktop with flutter_rust_bridge works great. Sure, not fully Rust, but Flutter has way more packages on the GUI side than, I'd say, all of the Rust GUIs combined, simply due to how much older it is.
avtar 11mo ago
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 https://github.com/iced-rs/iced/issues/552 And TIL about AccessKit https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit
stackghost 11mo ago
I use Halloy, one of the applications featured in the readme, on the regular. It's great and the UI is very pleasant. I don't enjoy writing rust and very much wish someone would port iced to other languages.
- clumsysmurf 11mo ago
  From the GUI perspective, I hope Halloy correctly supports proportional fonts soon. They kinda work but not everything is aligned correctly.
mootoday 11mo ago
I recently started to get an interest in writing a GUI with Rust. In particular, a database GUI. Initially, I thought Tauri with Svelte. Then I learned about gpui (https://www.gpui.rs/ https://www.gpui.rs/) and I'm intrigued. TIL about iced, which seems to have been around for a while. Before I embark on building a prototype UI for my app with all three libraries, does anyone have hands-on experience they can share?
- airstrike 11mo ago
  i'm building "Cursor for business users" with spreadsheets and documents in lieu of a code editor. I'm 90kloc in and couldn't be happier I encourage you to join the Discord and look around
- jenadine 11mo ago
  There is also Slint, if you want another option. https://slint.dev https://slint.dev
- chironjit 11mo ago
  I've built apps with Iced, Dioxus and PopOS's version of Iced. Here is my opinion: 1) Iced requires you to style everything in their own styling methods. It's not as intuitive as CSS. I found that, coming from using CSS, I struggled to recreate the style to the same high bar I expected from websites using css. 2)LLMs are not as familiar with Iced's styling, and will struggle with helping you plus also dealing with the breaking changes between Iced versions. Same to a lesser extent with Dioxus 3) Dioxus is easier to build by hand and via LLMs since you just use CSS/tailwind CSS. That said, even Dioxus is rough on the edges, you occassionly get some weird bugs, that you just have to deal with 4)PopOS' Iced version is great if you're using it on PopOS specifically but will require you to install a separate style pack on other linux distros to get the styling of the windows to show correctly. It's more mature than the original Iced IMO, though it's opinionated styling(of it's starter boilerplate) may be less to your liking. While I haven't used it in some time, I would consider it an almost independent fork by now 5) Last but most important negative IMO of Iced and Dioxus is their release cadence. Iced 0.14 has now launched more than a year since 0.13. For some the stability is great, but for frameworks that are still maturing with lots of improvements pending, I think it's actually important to have faster release cadences so that you know issues you face are not left hanging for a fix for a year. Now onto more practical stuff: 1) If you need simple, standalone apps, any one will work. I think this may be true for your app idea If you need speed of change, multi platform, etc, you will likely end up with Tauri. In that case, you might as well use the front-end framework you like. 2) None of the frameworks give you a pathway to publishing except Tauri. Basically, only Tauri really puts that as part of its guide, and so when you are going to Publish, you will be using Tauri's guide anyway 3) If you need multi-processing, Dioxus is out of your option, or you will end up using Tauri with Dioxus as your front-end
globalnode 11mo ago
tcl/tk in python is boring but gets the job done, and its not that hard to customise buttons with a canvas if you really want. i think its underrated.
eviks 11mo ago
[flagged]
- przmk 11mo ago
  It would have helped if you told us what you think is broken in Iced.
  - eviks 11mo ago
    You're right, unfortunately, don't have a good iced-specific list, so left it out, but here a few things: startup is blazingly slow (one of the big issues of all those awful electron apps which the native frameworks can supposedly avoid), https://github.com/iced-rs/iced/issues/2455 https://github.com/iced-rs/iced/issues/2455 https://github.com/iced-rs/iced/issues/615 https://github.com/iced-rs/iced/issues/615. Or high memory use, another fatal flaw of all those electron apps https://github.com/iced-rs/iced/issues/820 https://github.com/iced-rs/iced/issues/820 Or window can't be centered (while this is basic, it's in a bit of a blame-the-broken-Wayland niche https://github.com/iced-rs/iced/issues/1287 https://github.com/iced-rs/iced/issues/1287) Or lack of accessibility https://github.com/iced-rs/iced/issues/552 https://github.com/iced-rs/iced/issues/552 Or poor keybinding support (though in the case of iced I see it's somewhat improved in this release with some IME support and non-latin https://github.com/iced-rs/iced/pull/3134 https://github.com/iced-rs/iced/pull/3134, so don't know exactly what's left broken) The there are non-runtime issues like lack of documentation
    - thorn132 11mo ago
      My iced apps startup much faster than the Qt(Pyside) and Electron apps they replaced, and run faster too. Similarly, memory usage is much lower, and shipping a single 25MB binary to customers is preferable to bundling some multi-GB runtime environment. So in practice I'm glad development focuses more on completing the framework before playing performance metric golf, even if minimizing startup time and memory usage would be nice. The 'lack' of documentation was only a problem for me when I was doing a cursory comparison of UI frameworks. Once I seriously started learning iced, the resources available, including the community on discord, was plenty to start being productive on making real apps within a week or two (and I had very limited Rust experience before that).

113 points by airstrike 11mo ago

k_bx 11mo ago

The COSMIC DE (by System76, default in Pop_OS distro) is written using their iced fork, which hopefully will be upstreamed eventually.

sho_hn 11mo ago
Why did they fork it?
- tomnipotent 11mo ago
  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.
  - tuananh 11mo ago
    they had release just yesteday but yeah, it's quite long between releases. https://github.com/iced-rs/iced/releases/tag/0.14.0 https://github.com/iced-rs/iced/releases/tag/0.14.0
    - tomnipotent 11mo ago
      For perspective Cosmic DE went from Alpha 1 to Beta 1 in that same timeframe.
- airstrike 11mo ago
  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 11mo ago
  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.

andsoitis 11mo ago

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

andsoitis 11mo ago

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

wonklebonkle 11mo ago

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 11mo ago
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 11mo ago
  Are you writing QtWidgets or QtQuick in Python? My understanding is that QML is mandatory for QtQuick apps.
  - dotancohen 11mo ago
    I use QtWidgets. I've never touched QtQuick.
- amelius 11mo ago
  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.

dotancohen 11mo ago

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 11mo ago
This might be what you're looking for: https://docs.rs/vlc-rs/latest/vlc/ https://docs.rs/vlc-rs/latest/vlc/ There's also PyO3 for using Python libraries from Rust, if no bindings or substitutes are available.
- dotancohen 11mo ago
  Nice, thank you! I see grt_rate() and set_rate() methods, so that might just work. I'll be setting up a prototype soon, much appreciated.

lazypenguin 11mo ago

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.

bikelang 11mo ago
In case you’re not aware - Pop!_OS has built their cosmic desktop environment on top of iced.
- Klonoar 11mo ago
  On their fork of Iced. They contribute back but it’s a notable distinction.
satvikpendem 11mo ago
Alternatively, Flutter desktop with flutter_rust_bridge works great. Sure, not fully Rust, but Flutter has way more packages on the GUI side than, I'd say, all of the Rust GUIs combined, simply due to how much older it is.

avtar 11mo ago

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 https://github.com/iced-rs/iced/issues/552 And TIL about AccessKit https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit

stackghost 11mo ago

I use Halloy, one of the applications featured in the readme, on the regular. It's great and the UI is very pleasant. I don't enjoy writing rust and very much wish someone would port iced to other languages.

clumsysmurf 11mo ago
From the GUI perspective, I hope Halloy correctly supports proportional fonts soon. They kinda work but not everything is aligned correctly.

mootoday 11mo ago

I recently started to get an interest in writing a GUI with Rust. In particular, a database GUI. Initially, I thought Tauri with Svelte. Then I learned about gpui (https://www.gpui.rs/ https://www.gpui.rs/) and I'm intrigued. TIL about iced, which seems to have been around for a while. Before I embark on building a prototype UI for my app with all three libraries, does anyone have hands-on experience they can share?

airstrike 11mo ago
i'm building "Cursor for business users" with spreadsheets and documents in lieu of a code editor. I'm 90kloc in and couldn't be happier I encourage you to join the Discord and look around
jenadine 11mo ago
There is also Slint, if you want another option. https://slint.dev https://slint.dev
chironjit 11mo ago
I've built apps with Iced, Dioxus and PopOS's version of Iced. Here is my opinion: 1) Iced requires you to style everything in their own styling methods. It's not as intuitive as CSS. I found that, coming from using CSS, I struggled to recreate the style to the same high bar I expected from websites using css. 2)LLMs are not as familiar with Iced's styling, and will struggle with helping you plus also dealing with the breaking changes between Iced versions. Same to a lesser extent with Dioxus 3) Dioxus is easier to build by hand and via LLMs since you just use CSS/tailwind CSS. That said, even Dioxus is rough on the edges, you occassionly get some weird bugs, that you just have to deal with 4)PopOS' Iced version is great if you're using it on PopOS specifically but will require you to install a separate style pack on other linux distros to get the styling of the windows to show correctly. It's more mature than the original Iced IMO, though it's opinionated styling(of it's starter boilerplate) may be less to your liking. While I haven't used it in some time, I would consider it an almost independent fork by now 5) Last but most important negative IMO of Iced and Dioxus is their release cadence. Iced 0.14 has now launched more than a year since 0.13. For some the stability is great, but for frameworks that are still maturing with lots of improvements pending, I think it's actually important to have faster release cadences so that you know issues you face are not left hanging for a fix for a year. Now onto more practical stuff: 1) If you need simple, standalone apps, any one will work. I think this may be true for your app idea If you need speed of change, multi platform, etc, you will likely end up with Tauri. In that case, you might as well use the front-end framework you like. 2) None of the frameworks give you a pathway to publishing except Tauri. Basically, only Tauri really puts that as part of its guide, and so when you are going to Publish, you will be using Tauri's guide anyway 3) If you need multi-processing, Dioxus is out of your option, or you will end up using Tauri with Dioxus as your front-end

globalnode 11mo ago

tcl/tk in python is boring but gets the job done, and its not that hard to customise buttons with a canvas if you really want. i think its underrated.

eviks 11mo ago

[flagged]

przmk 11mo ago
It would have helped if you told us what you think is broken in Iced.
- eviks 11mo ago
  You're right, unfortunately, don't have a good iced-specific list, so left it out, but here a few things: startup is blazingly slow (one of the big issues of all those awful electron apps which the native frameworks can supposedly avoid), https://github.com/iced-rs/iced/issues/2455 https://github.com/iced-rs/iced/issues/2455 https://github.com/iced-rs/iced/issues/615 https://github.com/iced-rs/iced/issues/615. Or high memory use, another fatal flaw of all those electron apps https://github.com/iced-rs/iced/issues/820 https://github.com/iced-rs/iced/issues/820 Or window can't be centered (while this is basic, it's in a bit of a blame-the-broken-Wayland niche https://github.com/iced-rs/iced/issues/1287 https://github.com/iced-rs/iced/issues/1287) Or lack of accessibility https://github.com/iced-rs/iced/issues/552 https://github.com/iced-rs/iced/issues/552 Or poor keybinding support (though in the case of iced I see it's somewhat improved in this release with some IME support and non-latin https://github.com/iced-rs/iced/pull/3134 https://github.com/iced-rs/iced/pull/3134, so don't know exactly what's left broken) The there are non-runtime issues like lack of documentation
  - thorn132 11mo ago
    My iced apps startup much faster than the Qt(Pyside) and Electron apps they replaced, and run faster too. Similarly, memory usage is much lower, and shipping a single 25MB binary to customers is preferable to bundling some multi-GB runtime environment. So in practice I'm glad development focuses more on completing the framework before playing performance metric golf, even if minimizing startup time and memory usage would be nice. The 'lack' of documentation was only a problem for me when I was doing a cursory comparison of UI frameworks. Once I seriously started learning iced, the resources available, including the community on discord, was plenty to start being productive on making real apps within a week or two (and I had very limited Rust experience before that).