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
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::Application trait. 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.
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.
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.
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
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.
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).
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.
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.
Add comment