Iced Toolkit For Rust GUIs Reaches v0.12 With New Features

[mcirsta]

So far, it’s the most promising retain rust UI.

I would say Slint is much more advanced, mature and supports more targets but I haven't used any so far. I do plan to use Slint though, not this one.

[Quackdoc]

Its purpose is not to provide a ready made style. The developer creates custom widgets with custom styling. This is a low level GUI library.

would it be fair to analogize Winit to GDK and libcosmic to GTK, and Iced somewhere inbetween?

[soulsource]

would it be fair to analogize Winit to GDK and libcosmic to GTK, and Iced somewhere inbetween?

I've no clue about GDK, so I can't say how Iced relates to it, but I can give a quick summary how Iced works:
It's an application framework, but heavily customizable.

You describe your application by writing a type that holds the application state, and implementing the 'Application' trait (Rust traits are similar to interfaces in object oriented languages) for it. That trait has methods that reflect the Elm architecture (update, view,...), and some associated types that define how the application looks (Theme) and runs.

Iced has default implementations for those associated types, but you can make your own to customize it further.

In addition, you can make your own widgets, as long as you implement the required traits for them.

Making an Iced application with the default theme and layouting widgets is extremely fast.

The coolest part, however is the Elm architecture itself. You have two methods, one that gets a (user-defined) message and the old application state as input, to generate a new application state, and one that takes the application state as input, and gives the GUI as output (and tells the GUI elements which messages they should send to the update function).

[mmstick]

would it be fair to analogize Winit to GDK and libcosmic to GTK, and Iced somewhere inbetween?

It is closer to GDK than GTK. High level platform features such as Wayland integrations, system themes, settings subscriptions, and application instances aren't available.

Each widget in iced has an Appearance struct to influence how it is drawn, along with a custom stylesheet trait that is used to request Appearance structs from a generic theme type. The developer defines the theme type when implementing the Application trait on their applications' struct.

The default widgets and theme type in iced are reference implementations. The developer must create their own theme type and implement the stylesheet traits for each widget their theme supports. If you need deeper integrations with custom theming, you have to create widgets which are specialized to your custom theme type. This theme type must implement the stylesheet traits for every widget used in the application.

COSMIC applications are based on libcosmic, which is a high level platform toolkit and widget library based on iced. It sits on the same level as GTK. It contains a fully featured theme type that implements COSMIC design features, as well as system theme and settings integrations. It also implements a custom widget library that is specialized to the COSMIC theme type.

libcosmic also provides its own Application trait that automatically implements many high level platform integrations, such as Wayland integrations, application instances, settings subscriptions, theme subscriptions, and COSMIC interface elements. Elements such as the header bar, context drawer, and navigation bar. The developer can build applications using COSMIC design aesthetics and idioms without the boilerplate.

So all COSMIC applications are iced applications, but not all iced applications are COSMIC applications. COSMIC widgets cannot be used in iced applications because they are specialized to the COSMIC theme type.

If you have a specific vision in mind for how you want your application to look, you would use iced so that you can control every visual aspect of your widgets. If you want to develop a COSMIC application, then you'd opt to build with libcosmic as your starting point.