As is often the case with scientific research which many people believe to be pointless, technological innovations aren’t always made by achieving the end goal, but through the technologies developed to reach that goal.
Development on COSMIC Edit has lead towards improvements to the cosmic-text library, which is used by many GUI libraries in the Rust ecosystem now. Similarly, the UX designs for the text editor improves the COSMIC interface guidelines, and puts design theories to practice. Likewise, widgets that are necessary for the editor are added to the COSMIC platform toolkit, and existing widgets and features are improved to improve the development experience for applications like this.
No one would want to build applications for a platform that lacks widgets capable of properly displaying, formatting, and editing text. Many would also find it debilitating to have a desktop environment without a text editor preinstalled. Imagine if GNOME didn’t have Gedit, and KDE didn’t have Kate.
Besides, this is a default text editor for a desktop environment. It is really not that complex. The goal is not to develop an IDE, but a text editor that anyone would feel comfortable using as their default editor on the COSMIC platform.
GNOME was focusing on building Rust bindings for GTK for many years before Qt development picked up. The GTK bindings were usable within a year or two after Rust’s 1.0 release. Yet even today, those looking to build applications in Rust will find that GTK is the only mature toolkit right now. And if you’re doing that today, I’d recommend starting with Relm4 for the best GTK Rust experience.
Rust does not support the C++ ABI, and Qt does not provide a C interface, so much work has to be done on building the tooling for binding C++ libraries to Rust. That work is still ongoing, so some have opted to use QML instead of interfacing with Qt C++ libraries. Yet if you’re looking to use Qt or QML, you may as well use Slint instead. It’s developed by former Qt/Trolltech developers and has a similar approach as QML.
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.
I am still actively maintaining Pop!_OS. COSMIC has not changed that aspect of my job. Just within the last week I packaged Linux 6.6.8, Mesa 23.3.2, Just 1.22, Rust 1.75.0, and updated Popsicle’s dependencies to fix a bindgen build error with recent versions of Clang. We have a systemd update that was packaged today, and I’ll be doing another linux-firmware backport soon. So I don’t understand why you’d think it is stagnant. We’re even shipping Pipewire 1.0.0 by default, which Ubuntu hasn’t yet done in the latest version. People usually complain that we update too often.
2022 was only a year and a half ago, and we ship the latest Linux kernel, firmware, Mesa libraries, NVIDIA drivers and libraries, Pipewire/Wireplumber, ZFS, Firefox, Alacritty, Lutris, Steam, and Rust. Since when did we start considering that to be “incredibly ancient”? The next LTS release is not yet available to base Pop!_OS upon, but we ship newer kernels and drivers than the latest version of Ubuntu.
We will attempt to automatically generate themes for common toolkits, but the desktop environment has no control over how the toolkit chooses to render itself or operate.
They commented on their video that it was their fault. There was never a packaging issue. The issue was that we pushed a systemd source package update to Launchpad, which silently didn’t build or publish the 32-bit systemd library packages, because Ubuntu had systemd on a blacklist for 32-bit package builds. We noticed this minutes after packages were published, and had it fixed within an hour later.
This didn’t actually affect any systems in the wild because apt held back the update until we had worked around the restriction on Launchpad (there was an invisible ceiling to the package version number). They were only affected during that time period because they manually entered that sentence from the prompt in a terminal. We stopped using Launchpad with 21.10, so all packages released since then are the same packages that are built and tested by our packaging server, and used by our QA team internally.
The drama and reputational damage that LTT caused was unnecessary. Especially given that they uploaded this video a week later, and never attempted to reach out. They still have yet to properly edit the video.
You are misunderstanding the data. It is not the number of users, but a percent of posts to ProtonDB, which only applies to PC gamers. There can be a disproportionately larger number of reports from those who need to spend time tweaking their system as opposed to using it, or that are particularly vocal about sharing their tweaks.
The total number of users playing games on Linux is rising each year. Pop!_OS was the first OS that a lot of people tried a few years ago, and so you’ll see a lot more diversity in choice now. People who are new to Linux, yet particularly heavily invested in it, tend to like to try out a lot of different distributions in the following years.
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.
Make sure you have the latest firmware for your motherboard. This sounds like unstable voltages for memory, or an overly-aggressive PBO curve. Did you try disabling the XMP profile on the RAM, disabling PBO, and upping the voltages (within safe limits) of the SOC, DDR, and VDDP? You might find some useful info here[0] or here[1] if you intend to run your memory at 3200 MHz.
It’s not stable in the Debian sense. We’ve always had rolling release updates for the system base; and people often complain about regressions in Linux, Pipewire, Mesa, and NVIDIA updates. I get them packaged shortly after they’re released. As long as they pass QA tests in the System76 hardware lab, they get released within a week.
Yes, the libcosmic toolkit automates a decent chunk of the process to building an application with our interface guidelines. If building an application with the cosmic::Application trait. Which includes the header bar, navigation bar, and context drawer.
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.
You’re so silly. If the developer doesn’t want a themeable application, then either don’t use a themeable toolkit, or hardcode the theme so that the system theme is ignored.