• @theshatterstone54@feddit.uk
    link
    fedilink
    3411 months ago

    I’ve been following the work on COSMIC (though not super actively) and I keep on saying that I like what I’m seeing because, well, I do! The idea of a tiling DE is a very exciting one and COSMIC really has the potential to become a Major Linux DE.

    • NekuSoul
      link
      fedilink
      1511 months ago

      I particularly like that, just like their current Gnome extension, it supports both tiling and floating, with a quick toggle between them.

      This’ll be a pretty interesting year for people interested in DEs.

      • @leo85811nardo@lemmy.world
        link
        fedilink
        511 months ago

        As a regular i3 user, I was very satisfied on how tiling was implemented into the Pop shell of Gnome. After a few keybind change here and there it almost felt like home maneuvering the windows and workspaces. One minor complain is glitches happen when external monitor is connected/disconnected on the fly (laptop usecase), in which case windows are disoriented and thrown around at random unexpected places instead of staying at where they were. I’m blaming Gnome on that one however, since I’m assuming it is related on how Gnome handle multiple screens and Pop shell act on top of it, so I’m expecting it to be fixed in Cosmic DE

          • Michael Murphy (S76)OP
            link
            fedilink
            English
            4
            edit-2
            11 months ago

            The keyword is alternative. All first party applications are written natively with our libcosmic toolkit, which is based on iced-rs. We are using a fork of iced though because we needed to implement a custom runtime with the sctk (smithay client toolkit) for COSMIC applet development, but our desktop applications will use the original winit runtime.

    • @marlowe221@lemmy.world
      link
      fedilink
      English
      211 months ago

      Yeah, I’m a Pop user and like what they do with Gnome now. I can’t wait to see what it’s like when the desktop isn’t limited by the Gnome extension system.

  • @simple@lemm.ee
    link
    fedilink
    English
    2211 months ago

    I’ve been following Cosmic and really looking forward to it. I love the idea of a Gnome-like desktop without Gnome-like design decisions.

  • @priapus@sh.itjust.works
    link
    fedilink
    English
    1511 months ago

    Incredibly excited to try it. I love the early support for Nix, I plan to run it as soon as a NixOS module becomes available!

    Huge props to the design team here, the aesthetic looks amazing on all of the apps I’ve tried. They all feel consistent and look great.

  • Chewy
    link
    fedilink
    911 months ago

    [cosmic-randr] uses the wlr output configuration Wayland protocols.

    Does this mean cosmic-randr should work on other compositors that support the wlr output configuration protocol (e.g. sway, hyprland, river, …)? It’s great to see cosmic adopting existing protocols, instead of compositor specific protocols (or worse, no external app support at all).

    Also, it’s great how portable Cosmic DE seems to be, as it’s already mostly packaged on NixOS. On first look, cosmic-term seems to be a quick terminal so I might switch to it, as well as cosmic-files.

    • Michael Murphy (S76)OP
      link
      fedilink
      English
      1111 months ago

      If they support the wlr output configuration protocols, then yes it’ll work fine. There are some more advanced features that we want that aren’t supported by the protocol though, so we will likely develop some cosmic protocol extensions for those features.

    • Michael Murphy (S76)OP
      link
      fedilink
      English
      29
      edit-2
      11 months ago

      No, we have been making our own platform toolkit (libcosmic), which is built upon iced-rs. We are using this both for our wayland compositor applets, and our desktop applications.

      • @ExLisper@linux.community
        link
        fedilink
        English
        711 months ago

        iced? Interesting. I though it’s still pretty experimental. There’s no official documentation yet, right? When I was looking at Rust UI libraries Yew and Leptos looked more mature. I guess you’re confident iced have enough backing and isn’t going anywhere.

        How do you find working in Rust on a bigger UI project? Any issues?

        • Michael Murphy (S76)OP
          link
          fedilink
          English
          911 months ago

          Iced is a lower level GUI library, similar to what GDK is to GTK. We built our own COSMIC-themed GUI toolkit around iced, which is called libcosmic. As we’ve gotten more and more widgets and application logic developed, actual application development with libcosmic is a breeze. Even if you do have to create a custom widget, it’s much easier to creating custom widgets in GTK. We’re able to develop much faster than we ever could with GTK now.

          Yew and Leptos aren’t comparable since they’re not native GUI toolkits. These are for web developers rather than application development. It wouldn’t be possible to use this for developing layer shell applets for COSMIC, either.

          • @ExLisper@linux.community
            link
            fedilink
            English
            311 months ago

            This sounds really cool. I don’t see any documentation for libcosmic. Are you planning to promote it as an alternative toolkit for building desktop apps or do you see it more as an internal tool strictly for COSMIC DE development?

              • @devfuuu@lemmy.world
                link
                fedilink
                311 months ago

                What’s the accessibility story for blind users for example?

                Is it going to be suitable to use with proper bindings with other languages or it’s not an interest at this time or are there plans to support things like that and stability of apis, etc?

                • Michael Murphy (S76)OP
                  link
                  fedilink
                  English
                  211 months ago

                  We are integrating AccessKit into libcosmic for accessibility support.

                  If you want to develop applets and/or applications with libcosmic, you must do so with Rust. There are no plans to develop C bindings for libcosmic.

            • Michael Murphy (S76)OP
              link
              fedilink
              English
              3
              edit-2
              11 months ago

              You can generate documentation by running cargo doc and browsing the generated web pages in target/doc. There are also examples in the examples directory of libcosmic, as well as a design demo example which is a WIP.

              libcosmic is an alternative toolkit for building desktop applications and layer shell applets. It wouldn’t make much sense to build a toolkit only for ourselves. It’s the best way to develop layer shell applets for COSMIC, and other Wayland compositors that support the layer shell protocol.

          • @Blisterexe@lemmy.zip
            link
            fedilink
            111 months ago

            Btw, is this the only reason that cosmic isn’t gtk, or are there other reasons? Because afiak gtk uses/can use rust.

            • Michael Murphy (S76)OP
              link
              fedilink
              English
              2
              edit-2
              11 months ago

              The GTK4 project was cancelled for multiple reasons. We originally began working on Relm4 to use GTK4 for COSMIC applets. While others on the team were also experimenting with alternative Rust GUI libraries.

              It required a lot of effort to patch GTK4 to support the Wayland layer shell protocol. Getting those patches merged into GTK4 was also taking a much longer time. There were long delays between code reviews; and they also wanted a series of much larger refactoring changes to be made to GTK4 before exposing the layer shell feature. It was much easier to get layer-shell working with iced, as it is a much leaner and concise code base.

              GTK does not support fractional scaling, which is something we want our applets to support on day one. This was one of our major concerns. A concern that didn’t apply to iced.

              It was also exceedingly difficult to create custom widgets with GTK in Rust. Even those of us with years of experience considered it to be unreasonably difficult. So it was not feasible to expect new hires on the team to be able to comfortably develop COSMIC components with it. In comparison, our team was able to develop custom widgets with iced with much less effort and with greater flexibility, so the demand for iced grew stronger.

              At the end of the day, GTK is not a Rust toolkit, and its API is cumbersome to adapt to Rust. Use of GTK would always be a compromise that lessens the developer experience for COSMIC app and applet development. A compromise that would eventually require us to rewrite everything in a native Rust GUI library the moment it would become possible to do so.

              Since we are developing a desktop environment from the ground up anyway, we decided that there would be much more value for our time if we contribute to the Rust ecosystem and utilize iced to make a fully featured GUI library for application development.

              • @Blisterexe@lemmy.zip
                link
                fedilink
                1
                edit-2
                11 months ago

                Makes sense, thank you for the detailed answer! By the way, I saw that gtk apps will be automatically themed, is that only gtk3 or also gtk4? Edit: typo

                • Michael Murphy (S76)OP
                  link
                  fedilink
                  English
                  111 months ago

                  We will be adding integrations to our theme engine to automatically generate themes for GTK3, GTK4, and libadwaita.

          • Avid Amoeba
            link
            fedilink
            -3
            edit-2
            11 months ago

            Why develop libcosmic around iced instead of going with something else modern that’s easy to develop in such as Flutter? Iced/libcosmic is probably a bit more efficient resource-wise but that probably wasn’t a huge point.

            • Michael Murphy (S76)OP
              link
              fedilink
              English
              3
              edit-2
              11 months ago

              That would compromise our vision of a GUI platform built from the ground up in Rust. It would also not be feasible to use Flutter for applet development. We can easily make modifications directly to iced for all the Wayland integrations that we need in COSMIC, as the iced code base is very lean, and written in Rust.

              • Avid Amoeba
                link
                fedilink
                1
                edit-2
                11 months ago

                Got it. So being written in Rust is one of the requirements. Makes sense. Flutter is great for self-contained applications but we can definitely use another sane native toolkit besides Qt that has wider applicability.

      • Avid Amoeba
        link
        fedilink
        6
        edit-2
        11 months ago

        Beautiful, so there’s a good chance for it to not be a hot mess! Looking forward to it. 😊

  • @pmk@lemmy.sdf.org
    link
    fedilink
    411 months ago

    Just curious, on a scale from cowsay to MS Word, how difficult would it be to port COSMIC to the BSDs, assuming wayland support?

    • Michael Murphy (S76)OP
      link
      fedilink
      English
      311 months ago

      As long as you have access to the latest version of Rust, porting would be somewhere near cowsay.

      • @pmk@lemmy.sdf.org
        link
        fedilink
        111 months ago

        Nice! I know that OpenBSD people have been working on a wayland compatible thing which takes into account Linux-specific things (libinput?), but last I heard it’s not ready. I have my hopes up though! Could be the year of desktop BSD if they port COSMIC.

        • Michael Murphy (S76)OP
          link
          fedilink
          English
          211 months ago

          It would certainly be easier for them to port COSMIC because there are very few dependencies on shared C libraries. Cargo links all Rust libraries statically, so it’s easier to maintain and update components. This will depend how open they are to accepting Cargo and Rust into their ecosystems.

  • I recognize this is an odd comment to make, but I’m glad to see this screenshot tool supports capturing a window in Wayland. My next question is, can the screenshot tool be invoked from the command-line or via a script?

    • Michael Murphy (S76)OP
      link
      fedilink
      English
      40
      edit-2
      11 months ago

      Because that’s not how software development works, and that’s not how you make progress in the field. In order for our technical vision to be integrated with an existing desktop, such as GNOME, it would have required that they give us the reigns to their project to delete their entire codebase and rebuild it into exactly what you see today in COSMIC.

      As in life, sometimes you’ve got to demolish, pave, and build better foundations. There’s a lot of cool technologies available to build a truly next-generation desktop experience in, but you’re not going to get it through rigid bureaucracy and old tools. With COSMIC, we’ve got freedom to make decisions and build something truly unique, and we’re using our talent to show you what we can do.

      • @cybersandwich@lemmy.world
        link
        fedilink
        711 months ago

        Well said. I’m nervous and excited to see what this turns in to. Pop is my daily driver and has been for years. I’m excited to see all this progress.

      • @Unsafe@discuss.online
        link
        fedilink
        -110 months ago

        If you will create “next gen” desktop, you will just solve some problems of already existing ones and create your own. Maturity of software is far more important, than uniqueness. GNOME didn’t evolve into its current state for no reason.

        • Michael Murphy (S76)OP
          link
          fedilink
          English
          2
          edit-2
          10 months ago

          Translation: no one should ever attempt to innovate on the Linux desktop. GNOME is the epitome of software development and everyone else should quietly give up. If GNOME can’t fix an issue, no one can. Only GNOME has the god-given right to make decisions on how desktops are developed for Linux. There can only be one party. The One Desktop principle. Contribute to your party leader, or else…

    • @tiny@midwest.social
      link
      fedilink
      English
      11
      edit-2
      11 months ago

      Sometimes it’s easier to start over than unbreak an existing project. Gnome is old and big so it’s harder to change. So starting over where you don’t have to keep existing features or care about existing users is way easier than fixing gnome and rewriting it in rust. Plus system 76 can. There’s no single party that can stop them from making a desktop

    • Quazatron
      link
      fedilink
      511 months ago

      We do what we must because we can.

      FOSS software development is very much like evolution. Many projects are born but only the best thrive. It is a wasteful system because resources are spread over similar projects, but it creates very good software.

      • @Unsafe@discuss.online
        link
        fedilink
        1
        edit-2
        10 months ago

        Not really. Best Foss projects do not always thrive. Git wasn’t really better than mercurial. But it had happened to be published earlier, so it got wider adoption.

        • Quazatron
          link
          fedilink
          110 months ago

          It doesn’t have to be the best, it just has to be better than the current standard. Git was better than CVS and SVN, so it won.

    • yianiris
      link
      fedilink
      111 months ago

      Because some developers act on their own consciousness and don’t have a slavemaster corporate manager telling them what they need to do or not do.

      When one doesn’t like any of the available choices yet a new one is born. Can you measure how many v.terminals we have, or how many window managers on X11?

      @Unsafe @mmstick

      • @Unsafe@discuss.online
        link
        fedilink
        110 months ago

        Fortunately such “new choices” get abandoned very quickly. Making new solution instead of improving existing ones is counterproductive. Unless there is a large legacy codebase. Smart people have invented Unix principles to avoid that.