Nice! I know that OpenBSD people have been working on a wayland compatible thing which takes into account Linux-specific things (libinput?), but last I heard it’s not ready. I have my hopes up though! Could be the year of desktop BSD if they port COSMIC.
It would certainly be easier for them to port COSMIC because there are very few dependencies on shared C libraries. Cargo links all Rust libraries statically, so it’s easier to maintain and update components. This will depend how open they are to accepting Cargo and Rust into their ecosystems.
I recognize this is an odd comment to make, but I’m glad to see this screenshot tool supports capturing a window in Wayland. My next question is, can the screenshot tool be invoked from the command-line or via a script?
[cosmic-randr] uses the wlr output configuration Wayland protocols.
Does this mean cosmic-randr should work on other compositors that support the wlr output configuration protocol (e.g. sway, hyprland, river, …)? It’s great to see cosmic adopting existing protocols, instead of compositor specific protocols (or worse, no external app support at all).
Also, it’s great how portable Cosmic DE seems to be, as it’s already mostly packaged on NixOS. On first look, cosmic-term seems to be a quick terminal so I might switch to it, as well as cosmic-files.
If they support the wlr output configuration protocols, then yes it’ll work fine. There are some more advanced features that we want that aren’t supported by the protocol though, so we will likely develop some cosmic protocol extensions for those features.
I’ve been following the work on COSMIC (though not super actively) and I keep on saying that I like what I’m seeing because, well, I do! The idea of a tiling DE is a very exciting one and COSMIC really has the potential to become a Major Linux DE.
As a regular i3 user, I was very satisfied on how tiling was implemented into the Pop shell of Gnome. After a few keybind change here and there it almost felt like home maneuvering the windows and workspaces. One minor complain is glitches happen when external monitor is connected/disconnected on the fly (laptop usecase), in which case windows are disoriented and thrown around at random unexpected places instead of staying at where they were. I’m blaming Gnome on that one however, since I’m assuming it is related on how Gnome handle multiple screens and Pop shell act on top of it, so I’m expecting it to be fixed in Cosmic DE
Yeah, I’m a Pop user and like what they do with Gnome now. I can’t wait to see what it’s like when the desktop isn’t limited by the Gnome extension system.
I’m just happy there’s a rust DE being written in slint. KDE is nice and all, but it’s all C++. No way am I touching that trainwreck of a language again.
A great start to the week - @pop_os_official will collaborate with us to offer Slint as an alternative toolkit for application development on Cosmic Desktop.
The keyword is alternative. All first party applications are written natively with our libcosmic toolkit, which is based on iced-rs. We are using a fork of iced though because we needed to implement a custom runtime with the sctk (smithay client toolkit) for COSMIC applet development, but our desktop applications will use the original winit runtime.
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.
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.
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.
Add comment