mmstick

GNOME users wouldn't be happy having to install KDE dependencies to use a KDE text editor which doesn't have a consistent look and feel on their desktop. Same applies for KDE users.

You are heavily overestimating how much effort is required to develop a text editor. It's a single person project using components that had to be developed for use in multiple applications; regardless of whether there is a text editor or not. Components that you'd be silly not to develop through a text editor project.

You are trying too hard to justify that we not make a text editor. It feels like you don't want us to make a text editor at all. No one is on a path to burnout. Everyone is paid a full time salary to work on their respective areas. COSMIC development is doing really well.

Ask our compositor engineer on the compositor's source repo: https://github.com/pop-os/cosmic-comp

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.

Git integration now in progress

Git integration now in progress

Yes, there are vim keybindings and some vim commands supported.

It is bundling the icons now for improved Windows support. The same feature will be built into libcosmic soon.

The vendor would have to expose a system file for configuring this in the kernel, and then contribute a patch to the cosmic-power applet to connect it with the existing toggle.

That said, I would be surprised if the battery manufacturer isn't already limiting the max charge to 80% from the firmware in the battery's own charging controller.

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.

You don't seem to realize that this is equivalent to that. The user already made the choice to install a desktop environment which generates themes. So if you make the choice to build an application with GTK, and you want users to be able to use system themes with it, then consider it done.

To argue otherwise would make you a hypocrite. It would mean that you don't actually want users to use themes, so you take issue with desktop environments which make it easy to do so by default. So if you want people to be able to use themes, then you shouldn't complain when people choose to use a desktop which enables that use case.

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.