Notable changes:
- Tracking improvements. For example, if you use the launcher to launch an application and then switch workspaces, it will still launch in the workspace you opened it from;
- Supported the ext-session-lock protocol, which authenticates the user and informs the compositor when the session should be unlocked
- XDG activation and DBus activation support
- work on HDR
- Ongoing work to package COSMIC on NixOS: tracking issue
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.
I want that individual users are able to theme my app. I don’t want that distributors and DEs automatically theme my app and expect that it still works the same.
It’s a bit like websites: I’m absolutely fine if a user wants to inject some CSS in my website. On the other hand, if a browser manufacturer decided to inject CSS into all websites to customize their look, it would be a nightmare for web developers.
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.