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.
The GTK4 project was cancelled for multiple reasons. We originally began working on Relm4 to use GTK4 for COSMIC applets. While others on the team were also experimenting with alternative Rust GUI libraries.
It required a lot of effort to patch GTK4 to support the Wayland layer shell protocol. Getting those patches merged into GTK4 was also taking a much longer time. There were long delays between code reviews; and they also wanted a series of much larger refactoring changes to be made to GTK4 before exposing the layer shell feature. It was much easier to get layer-shell working with iced, as it is a much leaner and concise code base.
GTK does not support fractional scaling, which is something we want our applets to support on day one. This was one of our major concerns. A concern that didn’t apply to iced.
It was also exceedingly difficult to create custom widgets with GTK in Rust. Even those of us with years of experience considered it to be unreasonably difficult. So it was not feasible to expect new hires on the team to be able to comfortably develop COSMIC components with it. In comparison, our team was able to develop custom widgets with iced with much less effort and with greater flexibility, so the demand for iced grew stronger.
At the end of the day, GTK is not a Rust toolkit, and its API is cumbersome to adapt to Rust. Use of GTK would always be a compromise that lessens the developer experience for COSMIC app and applet development. A compromise that would eventually require us to rewrite everything in a native Rust GUI library the moment it would become possible to do so.
Since we are developing a desktop environment from the ground up anyway, we decided that there would be much more value for our time if we contribute to the Rust ecosystem and utilize iced to make a fully featured GUI library for application development.
Makes sense, thank you for the detailed answer! By the way, I saw that gtk apps will be automatically themed, is that only gtk3 or also gtk4? Edit: typo
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.
I had a 3700x that was doing that sort of thing. It seemed mostly random, but moving big files would crash it pretty often. It ran memtest86 for 3 days no problem. I replaced part by part, and it ended up being the CPU. I’d bought it second hand so it may have been abused.
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.
The crashes are in the middle of browsers (both Firefox and chrome embedded in Spotify), if you try a simple mprime stress test (from the AUR mprime-bin) does it crash too?
Thank you for making your comment licensed under creative common. I’ll now steal it, repackage it and sell for 9.99$ without even acknowledging your existence
But… it’s a Non-commercial Attribution license. /s/ns
I’m joking, but on a more serious note for those that don’t know, not all Creative Commons licenses allow you to monetize, and be sure to actually read which version of license is used if you plan to use a CC work for anything other than personal use.
I don’t think linking to a licence that increases the rights of third parties to do things with your words (over the default all rights reserved) will do very much for you there.
I think you’re missing my point. You are giving people more rights to use your comments by putting them under CC licence than not putting them under any.
No, how was I supposed to infer that you were fine with non-commercial AI from your two letter response to why you were licencing your comment?
I think its fairly naive to think that linking to a licence will do anything to stop commercial AI but not open ones, but you go for it if you think it’s worthwhile.
You joke but when “media” outlets boldly steal 90% of their content directly from reddit posts and comments without attribution for commercial use, maybe including a license isnt crazy anymore?
The worst documentation of a linux distro I have ever encountered, but the declarative model has convinced me I don’t want something else. Now I’m just waiting for other distros to pop up that are declarative as well. (Guix? No thanks, I’m not a fan of endless parentheses)
I would suspect that making a stable desktop inside docker ensures it would work everywhere else, no matter what the hw/sw of the host is.
I've only known docker as a building environment that ensures rebuildability and I can't say I ever liked it. I think its popularity comes from some myth of safety and security.
Despite the CPU being 64-bit, the distro MUST be 32-bit. This is because of the MacBook’s BIOS, which prevents 64-bit bootloaders from working.
That’s the thing, you can run a 64-bit distro as long as you’ve a 32 bit grub starting it :) You run Debian 12 amd64 on a 32 bit EFI:
As of 2023 and Debian 12 the amd64 installation media (available in netinst form) includes the UEFI boot loaders necessary for both i386 and amd64 boot. By selecting “64-bit install” from the initial boot menu, debian-installer will install a 64-bit (amd64) version of Debian. The system will automatically detect that the underlying UEFI firmware is 32-bit and will install the appropriate version of grub-efi to work with it.
I am running 10.6. Chromium Legacy is for 10.7 and above, and the same is true of a lot of software. Meanwhile, on my Linux partition, I can have Firefox Nightly if I want. It’ll run heavily, but it’s possible.
As it happens, I do have a somewhat recent browser installed in OSX, but it’s not great.
Also, running an older OS like that isn’t a good idea, as it won’t have received security patches or microcode updates.
That’s the thing, you can run a 64-bit distro as long as you’ve a 32 bit grub starting it :)
I hadn’t quite considered that somebody had implemented this. Thanks for the info!
There was also another user who gave me a link to some software that modifies mixed-mode ISOs so that they will boot on my potato laptop.
I am running 10.6. Chromium Legacy is for 10.7 and above
Can’t you run 10.7 on that laptop? It seems like you can, and that will greatly improve your software situation. Another thing to consider is to replace the HDD with an SSD. That computer will run any SATA drive (I’ve tested with modern WD blue drives), just grab something like 250GB for 30€ and enjoy speed.
There was also another user who gave me a link to some software that modifies mixed-mode ISOs so that they will boot on my potato laptop.
Yes but Debian provides that out-of-the-box and officially supported. That means everything will work fine and as stable as Debian is usually.
i think they are already mentioning it: MS has a help webpage on how to install linux, both WSL2 on Windows machine, or how to burn iso and install linux on bare metal. learn.microsoft.com/en-us/linux/install
Microsoft have quite a bit of software that runs on Linux (PowerShell, VS Code, .NET, Azure tools, Intune / Endpoint Manager, even SQL Server) so it’s understandable that they’d have documentation to explain it to their customers.
Yep, they run it themselves even. Previously their motto was “Linux is a Cancer” now they have embraced it and developed their own distro (CBL). With how everything is going WebApp these days, I can see a day when Windows will be linux based kernel.
They already have a Windows version for a handheld. The Xbox runs a modified version of Windows 11. All they’d need to do to bring it in line with PC handhelds is allow the install of third party launchers (they probably wouldn’t do this though).
[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.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.