COSMIC Edit with project-wide search
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.
Yes, this can already be seen when configuring a personal theme in the Desktop > Appearances page in COSMIC Settings. Compositor elements, applets, the login and lock screens, and COSMIC applications automatically adjust in realtime to the configuration changes.
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.
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.
It uses a custom UI framework, St, using renderer primitives built into the compositor, mutter. Whereas COSMIC is using the same libcosmic library inside the compositor, applets, and desktop applications. Thanks due to our Smithay client toolkit being used to provide a renderer for iced which supports the Wayland layer shell protocol.
Any instructions for QA to replicate the issue?
I hope to see Linux brought to the Web 2.0 era with proper use of Git forges. As it is, most people won't bother to go through the existing processes unless they're paid to do it. Raising the barrier to entry in order to discourage low quality submissions is a poor excuse. The existing system makes it difficult to get any changes approved or reviewed with a serious eye, regardless of their quality.
Matrix is a better platform for realtime communication, but it has the same issue with needing an account and being difficult to search. Any discussions that take place on Discord or Matrix will be fleeting, as it prioritizes only the most recent discussion in the chat. Thus making long form discussions about particular topics impossible.
All technical discussions should be archived on a searchable forum. If you are using a source forge like GitHub and GitLab, then public discussions should take place there. There's no better place for discussions and questions about code than in the same place where the code is hosted itself. Platform integrations make it very easy to associate discussions to commits and merge requests.
While not ideal, even hosted forum platforms like Lemmy and Reddit are still better than using a chat client. If only to serve as a platform for broader public discussions and questions. People are more likely to already have a Lemmy or Reddit account than they are to have a GitHub or GitLab account.
I don't need Google to tell me what I already know since writing software in Rust for the last 8 years. It was your argument that Rust is not suitable for newbies. So if you want to change the topic to what language a person should learn, then Rust is most definitely at the every top. It's a life-changing experience that significantly boosts your programming skill once learned. There's a reason why it's been the most loved programming language on Stack Overflow for seven consecutive years. Not because it's hard, but because it's enjoyable to learn and use. The patterns and techniques that Rust teaches are useful in every language.
The Rust community is a very diverse group of people with many different opinions. It is not a universal truth that the Rust community believes Rust to be an awful first language. I've known plenty of people who started their careers with Rust. I started my career with Rust, too. The complaint with difficulty adapting to the borrow checker has been irrelevant since the 2021 edition of Rust. The borrow checker has become smarter about rearranging borrows and automatically tagging lifetimes in most cases. The remaining constraints that the compiler enforces are also hard requirements to learn when developing software in any other language. The same practices equally apply to all software. For example, mutating an array while iterating it in Python or JavaScript will lead to unexpected behavior. Python and JavaScript's lack of a proper type system causes a lot of software to explode at runtime when you think inputs are always X but suddenly in one case it happens to be Y.
I believe you're mistakenly assuming it's more difficult to work with than it really is. For example, imagine telling someone that pattern matching in Rust is more difficult than constructing unions and casting pointers in C. Even something as simple as string manipulation is a lot easier to do with Rust than in C or C++. I've worked with a number of people over the years that had little experience in programming outside Rust. It's not that difficult.
You're not making the strong case that you think you are. Quite the opposite. The ease of "shooting yourself in the foot" is precisely what makes it so difficult to learn. Segmentation faults and random memory corruption make it incredibly hard to get started with programming. The compiler typically providing no help at all for diagnosing where the memory handling flaws are. You need to learn how to use a debugger to get anywhere with fixing them. Many people give up when it gets too difficult to diagnose them
Rust's constraints are very clear and concise in comparison, with a helpful compiler that will teach you how to handle memory correctly by pointing out the precise location where a borrow error occurs, and provides a suggestion for how to change your code to fix it. There's never a question about whether a value will be passed or cloned. Cargo's API documentation is also extensive in comparison to typical C or C++ documentation. It is a major boon for beginning programmers that the language ships a tool which automatically generates high quality documentation for every library you will ever use.
This is very over-exaggerated. A lot of people started with C or C++ as their first language. Both of which are significantly harder than learning Rust. In fact, I had a much easier time learning Rust than I had with Python and Java because the Rust compiler's always had great error messages and documentation. Which then significantly boosted my ability to write C and C++. If, in an alternate reality, I had started learning programming today, I would recommend to my alternate self to start with Rust. Especially now that it's gotten so much easier than when I had learned Rust when it was still in alpha. Error messages have gotten very detailed lately, to the point where many of them show the precise code to write to fix the error. The compiler's also much less strict with borrowing and lifetimes.
For the past two years, I have also been the lead developer of AccessKit
When COSMIC development was officially announced, we mentioned that we would be using AccessKit for accessibility support. While certain people in GNOME were spreading concern and doubts about COSMIC supporting accessibility, work was already underway to integrate AccessKit into COSMIC, successfully.
You can ask on the System76 subreddit
Every Intel-based System76 laptop ships day one with Coreboot firmware preinstalled. The System76 firmware interface is also written in Rust using Redox libraries.
Yes, there are vim keybindings and some vim commands supported.