No, we have been making our own platform toolkit (libcosmic), which is built upon iced-rs. We are using this both for our wayland compositor applets, and our desktop applications.
iced? Interesting. I though it’s still pretty experimental. There’s no official documentation yet, right? When I was looking at Rust UI libraries Yew and Leptos looked more mature. I guess you’re confident iced have enough backing and isn’t going anywhere.
How do you find working in Rust on a bigger UI project? Any issues?
Iced is a lower level GUI library, similar to what GDK is to GTK. We built our own COSMIC-themed GUI toolkit around iced, which is called libcosmic. As we’ve gotten more and more widgets and application logic developed, actual application development with libcosmic is a breeze. Even if you do have to create a custom widget, it’s much easier to creating custom widgets in GTK. We’re able to develop much faster than we ever could with GTK now.
Yew and Leptos aren’t comparable since they’re not native GUI toolkits. These are for web developers rather than application development. It wouldn’t be possible to use this for developing layer shell applets for COSMIC, either.
This sounds really cool. I don’t see any documentation for libcosmic. Are you planning to promote it as an alternative toolkit for building desktop apps or do you see it more as an internal tool strictly for COSMIC DE development?
What’s the accessibility story for blind users for example?
Is it going to be suitable to use with proper bindings with other languages or it’s not an interest at this time or are there plans to support things like that and stability of apis, etc?
You can generate documentation by running cargo doc and browsing the generated web pages in target/doc. There are also examples in the examples directory of libcosmic, as well as a design demo example which is a WIP.
libcosmic is an alternative toolkit for building desktop applications and layer shell applets. It wouldn’t make much sense to build a toolkit only for ourselves. It’s the best way to develop layer shell applets for COSMIC, and other Wayland compositors that support the layer shell protocol.
Why develop libcosmic around iced instead of going with something else modern that’s easy to develop in such as Flutter? Iced/libcosmic is probably a bit more efficient resource-wise but that probably wasn’t a huge point.
That would compromise our vision of a GUI platform built from the ground up in Rust. It would also not be feasible to use Flutter for applet development. We can easily make modifications directly to iced for all the Wayland integrations that we need in COSMIC, as the iced code base is very lean, and written in Rust.
Got it. So being written in Rust is one of the requirements. Makes sense. Flutter is great for self-contained applications but we can definitely use another sane native toolkit besides Qt that has wider applicability.
It doesn’t use GTK does it?
No, we have been making our own platform toolkit (libcosmic), which is built upon iced-rs. We are using this both for our wayland compositor applets, and our desktop applications.
Beautiful, so there’s a good chance for it to not be a hot mess! Looking forward to it. 😊
iced? Interesting. I though it’s still pretty experimental. There’s no official documentation yet, right? When I was looking at Rust UI libraries Yew and Leptos looked more mature. I guess you’re confident iced have enough backing and isn’t going anywhere.
How do you find working in Rust on a bigger UI project? Any issues?
Iced is a lower level GUI library, similar to what GDK is to GTK. We built our own COSMIC-themed GUI toolkit around iced, which is called libcosmic. As we’ve gotten more and more widgets and application logic developed, actual application development with libcosmic is a breeze. Even if you do have to create a custom widget, it’s much easier to creating custom widgets in GTK. We’re able to develop much faster than we ever could with GTK now.
Yew and Leptos aren’t comparable since they’re not native GUI toolkits. These are for web developers rather than application development. It wouldn’t be possible to use this for developing layer shell applets for COSMIC, either.
This sounds really cool. I don’t see any documentation for libcosmic. Are you planning to promote it as an alternative toolkit for building desktop apps or do you see it more as an internal tool strictly for COSMIC DE development?
As of today, https://pop-os.github.io/libcosmic/cosmic/ is now available.
What’s the accessibility story for blind users for example?
Is it going to be suitable to use with proper bindings with other languages or it’s not an interest at this time or are there plans to support things like that and stability of apis, etc?
We are integrating AccessKit into libcosmic for accessibility support.
If you want to develop applets and/or applications with libcosmic, you must do so with Rust. There are no plans to develop C bindings for libcosmic.
You can generate documentation by running
cargo docand browsing the generated web pages intarget/doc. There are also examples in the examples directory of libcosmic, as well as a design demo example which is a WIP.libcosmic is an alternative toolkit for building desktop applications and layer shell applets. It wouldn’t make much sense to build a toolkit only for ourselves. It’s the best way to develop layer shell applets for COSMIC, and other Wayland compositors that support the layer shell protocol.
Why develop libcosmic around iced instead of going with something else modern that’s easy to develop in such as Flutter? Iced/libcosmic is probably a bit more efficient resource-wise but that probably wasn’t a huge point.
That would compromise our vision of a GUI platform built from the ground up in Rust. It would also not be feasible to use Flutter for applet development. We can easily make modifications directly to iced for all the Wayland integrations that we need in COSMIC, as the iced code base is very lean, and written in Rust.
Got it. So being written in Rust is one of the requirements. Makes sense. Flutter is great for self-contained applications but we can definitely use another sane native toolkit besides Qt that has wider applicability.