- cross-posted to:
- pop_os@lemmy.world
- pop_os@lemmy.world
- cross-posted to:
- pop_os@lemmy.world
- pop_os@lemmy.world
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
I’ve been waiting for this desktop to release patiently. I can’t wait to try it. I have one question that I never got to ask anywhere, how is this going to work with the whole Qt/GTK apps? Are things going to look weird like they do on (mostly) Gnome and (sometimes) KDE Plasma?
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.
Fair enough. As long as the app goes with the dark/light theme and doesn’t look super tiny on hidpi screens, I personally wouldn’t really lose sleep over it. Will there be an HIG specific to cosmic for devs who want to make apps for it?
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::Applicationtrait. Which includes the header bar, navigation bar, and context drawer.Thank you for answering all these questions. Last question, do you know when an alpha or a beta will be released? I want to test and help out with reporting. I have a spare laptop that I can use to test.
Please don’t automatically generate themes for third-party apps. If an application brings its own styles and icons, it results a weird mix of multiple styles.
If a user wants to style it themselves, they should be able to — at their own risk. But shipping (inherently broken) styles with a distro/DE misrepresents the appplication and creates unnecessary issues for the upstream developers.
https://stopthemingmy.app/
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.
Tell that to my eyes when your application only has a blinding light mode. Theming is an accessibility feature and should be prioritized as such.
It’s 2023. Every application should have a theme engine built-in. If not, that’s on the dev. Let’s not make a movement out of a lack of interest in providing support for accessibility.
Any recent application should respect the global
org.freedesktop.appearance color-schemesetting. If it doesn’t, you should blame the app developer.You’ll likely need something separate that’ll style both of these through the settings, similar to how you would config GTK themes on Plasma, or vice versa. I haven’t checked if they do this on their on yet, but it’ll probably be handled this way eventually. Out of the box, expect any Qt or GTK apps to look like their Breeze and Adwaita defaults look, unless you’ve already changed this on your system
I’d love for one of their devs to announce this or make a video about how it’s going to work.
The Redox Dev is working for System76, I think he discussed this on Techovertea episode
Edit: or maybe Brodie did a video about it, I’m not sure since he hosts that podcast as well
Give it time
Oh, I’m not rushing anyone. I’ve just been anticipating this DE for a long while. I’m very excited for it to be released. I’ve seen some previews and it looks freaking amazing.
Well GTK does not have theming anymore, though it still needs some way to configure fonts and icon theme.
It technically still does if you use their theming app “Gradience”. I use it currently on my laptop. Pretty nifty little app. It still doesn’t theme the shell (the panel, the password box… etc), but it does theme even flatpaks most of the time
Iirc Gradience punches a hole in the flatpak sandbox for xdg-config/gtk-4.0, which usually is in .config. This makes it work and isn’t a security problem.
Gnome Shell is unaffected because it doesn’t use GTK.
What does it use then?
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.
So that means themes will cover everything and things will be unified, unlike how the shell is always dark on gnome? (I know they’re working on a light mode).
Gnome libadwaita apps only change between dark and light mode, which probably can be derived from COSMIC DE’s settings quite easily.
For Qt I’m not sure how it looks by default, but since System76 wants to support multiple toolkits anyway, I guess they’ll have a solution ready.
I truly hope so, because I’m definitely putting this DE on one of my devices.