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.
I particularly like that, just like their current Gnome extension, it supports both tiling and floating, with a quick toggle between them.
This'll be a pretty interesting year for people interested in DEs.
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
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.
#rustlang
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.
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've been following Cosmic and really looking forward to it. I love the idea of a Gnome-like desktop without Gnome-like design decisions.
Incredibly excited to try it. I love the early support for Nix, I plan to run it as soon as a NixOS module becomes available!
Huge props to the design team here, the aesthetic looks amazing on all of the apps I've tried. They all feel consistent and look great.
Tldr: New desktop environment designed for PopOS (but usable elsewhere)
[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.
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. 😊
I’m really excited to test the Alpha, it’s looking really good so far!
Just curious, on a scale from cowsay to MS Word, how difficult would it be to port COSMIC to the BSDs, assuming wayland support?
As long as you have access to the latest version of Rust, porting would be somewhere near cowsay.
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?
Why do we invent new DEs instead of making proper settings app in already existing ones?
Because that's not how software development works, and that's not how you make progress in the field. In order for our technical vision to be integrated with an existing desktop, such as GNOME, it would have required that they give us the reigns to their project to delete their entire codebase and rebuild it into exactly what you see today in COSMIC.
As in life, sometimes you've got to demolish, pave, and build better foundations. There's a lot of cool technologies available to build a truly next-generation desktop experience in, but you're not going to get it through rigid bureaucracy and old tools. With COSMIC, we've got freedom to make decisions and build something truly unique, and we're using our talent to show you what we can do.
Well said. I'm nervous and excited to see what this turns in to. Pop is my daily driver and has been for years. I'm excited to see all this progress.
If you will create "next gen" desktop, you will just solve some problems of already existing ones and create your own. Maturity of software is far more important, than uniqueness. GNOME didn't evolve into its current state for no reason.
Translation: no one should ever attempt to innovate on the Linux desktop. GNOME is the epitome of software development and everyone else should quietly give up. If GNOME can't fix an issue, no one can. Only GNOME has the god-given right to make decisions on how desktops are developed for Linux. There can only be one party. The One Desktop principle. Contribute to your party leader, or else...
Sometimes it's easier to start over than unbreak an existing project. Gnome is old and big so it's harder to change. So starting over where you don't have to keep existing features or care about existing users is way easier than fixing gnome and rewriting it in rust. Plus system 76 can. There's no single party that can stop them from making a desktop
We do what we must because we can.
FOSS software development is very much like evolution. Many projects are born but only the best thrive. It is a wasteful system because resources are spread over similar projects, but it creates very good software.
Not really. Best Foss projects do not always thrive. Git wasn't really better than mercurial. But it had happened to be published earlier, so it got wider adoption.
It doesn't have to be the best, it just has to be better than the current standard. Git was better than CVS and SVN, so it won.
Welcome to FOSS lol
Because some developers act on their own consciousness and don't have a slavemaster corporate manager telling them what they need to do or not do.
When one doesn't like any of the available choices yet a new one is born. Can you measure how many v.terminals we have, or how many window managers on X11?
Fortunately such "new choices" get abandoned very quickly. Making new solution instead of improving existing ones is counterproductive. Unless there is a large legacy codebase. Smart people have invented Unix principles to avoid that.
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.
I particularly like that, just like their current Gnome extension, it supports both tiling and floating, with a quick toggle between them.
This'll be a pretty interesting year for people interested in DEs.
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
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.
CC BY-NC-SA 4.0
COSMIC is being written in libcosmic, which is based on iced.
I'm confused. Slint says it's working with System76?
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.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've been following Cosmic and really looking forward to it. I love the idea of a Gnome-like desktop without Gnome-like design decisions.
Incredibly excited to try it. I love the early support for Nix, I plan to run it as soon as a NixOS module becomes available!
Huge props to the design team here, the aesthetic looks amazing on all of the apps I've tried. They all feel consistent and look great.
Tldr: New desktop environment designed for PopOS (but usable elsewhere)
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.
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. 😊
I’m really excited to test the Alpha, it’s looking really good so far!
Just curious, on a scale from cowsay to MS Word, how difficult would it be to port COSMIC to the BSDs, assuming wayland support?
As long as you have access to the latest version of Rust, porting would be somewhere near cowsay.
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.
OpenBSD -release seems to be at rust 1.72, but -current has 1.75.
https://openbsd.app/?search=rust¤t=on
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?
Why do we invent new DEs instead of making proper settings app in already existing ones?
Because that's not how software development works, and that's not how you make progress in the field. In order for our technical vision to be integrated with an existing desktop, such as GNOME, it would have required that they give us the reigns to their project to delete their entire codebase and rebuild it into exactly what you see today in COSMIC.
As in life, sometimes you've got to demolish, pave, and build better foundations. There's a lot of cool technologies available to build a truly next-generation desktop experience in, but you're not going to get it through rigid bureaucracy and old tools. With COSMIC, we've got freedom to make decisions and build something truly unique, and we're using our talent to show you what we can do.
Well said. I'm nervous and excited to see what this turns in to. Pop is my daily driver and has been for years. I'm excited to see all this progress.
If you will create "next gen" desktop, you will just solve some problems of already existing ones and create your own. Maturity of software is far more important, than uniqueness. GNOME didn't evolve into its current state for no reason.
Translation: no one should ever attempt to innovate on the Linux desktop. GNOME is the epitome of software development and everyone else should quietly give up. If GNOME can't fix an issue, no one can. Only GNOME has the god-given right to make decisions on how desktops are developed for Linux. There can only be one party. The One Desktop principle. Contribute to your party leader, or else...
Sometimes it's easier to start over than unbreak an existing project. Gnome is old and big so it's harder to change. So starting over where you don't have to keep existing features or care about existing users is way easier than fixing gnome and rewriting it in rust. Plus system 76 can. There's no single party that can stop them from making a desktop
We do what we must because we can.
FOSS software development is very much like evolution. Many projects are born but only the best thrive. It is a wasteful system because resources are spread over similar projects, but it creates very good software.
Not really. Best Foss projects do not always thrive. Git wasn't really better than mercurial. But it had happened to be published earlier, so it got wider adoption.
It doesn't have to be the best, it just has to be better than the current standard. Git was better than CVS and SVN, so it won.
Welcome to FOSS lol
Because some developers act on their own consciousness and don't have a slavemaster corporate manager telling them what they need to do or not do.
When one doesn't like any of the available choices yet a new one is born. Can you measure how many v.terminals we have, or how many window managers on X11?
@Unsafe @mmstick
Fortunately such "new choices" get abandoned very quickly. Making new solution instead of improving existing ones is counterproductive. Unless there is a large legacy codebase. Smart people have invented Unix principles to avoid that.