Floating windows, UI implementation, and compositor improvements for the new COSMIC desktop environment.

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
  • Michael Murphy (S76)English
    17•6 months ago

    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.

    • @penquin@lemm.ee
      8•6 months ago

      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?

      • Michael Murphy (S76)English
        9•6 months ago

        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.

        • @penquin@lemm.ee
          4•6 months ago

          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.

    • @d_k_bo@feddit.de
      -5•6 months ago

      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/

      • Michael Murphy (S76)English
        6•6 months ago

        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.

        • @d_k_bo@feddit.de
          -1•6 months ago

          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.

          • Michael Murphy (S76)English
            4•6 months ago

            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.

      • trevorEnglish
        2•6 months ago

        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.