Development began mid-December, using the work we already did for cosmic-edit as a template. COSMIC Terminal uses the alacritty library, but the frontend interface is designed with our platform toolkit (libcosmic), with full support for bidrectional text and ligatures because we use cosmic-text instead of freetype.

https://fosstodon.org/@soller/111602927867586005

You can see above that between alacritty, cosmic-terminal, and gnome-terminal; cosmic-terminal was the only terminal to render correctly. Since then, we’ve given it the COSMIC treatment and now we have a tabbed interface with settings, search, etc.

https://fosstodon.org/@soller/111733526892594130

We’re still in the process of designing and implementing features, but don’t hesitate to try it out!

NVIDIA believes they’ll have the Vulkan on Wayland issue fixed in the 550 driver that they are planning to release early this year. Someone’s working on a fix in wgpu that happens to also boost performance for every driver in demos.

We’ve been using COSMIC on our systems since summer of last year. Some graphics drivers have issues, particularly NVIDIA drivers using Vulkan on Wayland. There are some XWayland bugs from time to time. It is very usable as is, but some settings aren’t implemented yet, and some toolkit features aren’t fully implemented.

I haven’t used it personally, but our UX lead is designing the theming system, whereas Ashley is working on theme support for libcosmic, and they were looking for something that supports oklch to generate themes from selected accent colors.

This will be used by the COSMIC desktop for generating color schemes for theme customization.

It’s already received many. In fact, the text is being managed by cosmic-text. COSMIC-specific features will remain in libcosmic of course, as well as any widgets and features we want which doesn’t fit with what iced wants.

The application crashes when I start it, perhaps due to wgpu. After switching to iced = { git = "https://github.com/pop-os/iced" }, I’m able to run it and see 7.7 MB memory consumption. We use a software-based renderer by default. Keep in mind though that Windows also doesn’t accurately report memory usage, and in Rust we have everything statically-linked into the binary. And there’s a lot of stuff being embedded and cached in memory at the moment as these libraries are being developed.

I’m mainly referring to how GTK is a very high level toolkit with many layers of abstractions and a number of complex functionalities built-in by default. Whereas iced in comparison is a low level library where you have to bring your own toolkit, or do it raw.

You might be surprised by how heavy some of the more established GUI toolkits are, which you don’t see because the abstractions are hidden from view in dozens of event loops running asynchronously in the background on the same local thread.

Iced widgets are collectively compiled down to a single state machine that pushes messages to a streamlined singular event loop. Commands and subscriptions are spawned on background thread(s). So the API by design keeps the UI thread free to focus on the UI.

The Elm model gives you freedom to manage all of your memory in a central location efficiently. So you can easily render a complex responsive UI at 240 FPS even if you’re using software rendering. How fast it renders is going to depend on how you cache and reuse your data.

You can pass data by reference to widgets so they’re drawn without allocating. You can load images on a background thread and cache them in your app struct so they only need to be decoded once. You can use lazy widgets, and even watch window dimensions to render most things in a single pass. Allocations are unfortunately required when you’re attaching multiple elements to a container, but that can change once Rust’s allocator API is stabilized.

iced does also internally cache some things itself between frames so they don’t have to be re-drawn. And it’ll surely get more sophisticated in this over time. Especially once damage-tracking is fully implemented.

And if you want a higher level abstraction with platform integrations built in, libcosmic is coming around the corner as a high level platform toolkit for making COSMIC applications with iced that’s tightly integrated with the COSMIC ecosystem. So you don’t have to worry about how you’re going to render client-side decorations, integrate with window manager protocols, implement theme support, configuration APIs, accessibility, etc.

As long as you store state in your application’s struct so that there’s no need to calculate and allocate in the view, then the view is quick to generate. You can also use lazy widgets that will avoid being re-recreated unless a given input has changed. Have you benchmarked to compare? You’d be surprised how efficient it is compared to heavier frameworks like GTK.

That’s been resolved by cosmic-text, which is being used by iced now. The cosmic-text crate provides a text editing widget, too.