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.
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.