Extensions in GNOME 45 – GNOME Shell & Mutter
blogs.gnome.org

By now it is probably no longer news to many: GNOME Shell moved from GJS’ own custom imports system to standard JavaScript modules (ESM).

Extensions that target older GNOME versions will not work in GNOME 45. Likewise, extensions that are adapted to work with GNOME 45 will not work in older versions.

You can still support more than one GNOME version, but you will have to upload different versions to extensions.gnome.org for pre- and post-45 support.

Please file bugs with your favorite extensions or have a friendly conversation with your extension writers so that we can help minimize the impact of this change. Ideally, you could help with the port and provide a pull or merge request to help maintainers.

  • IHeartBadCode@kbin.social
    334·
    1 year ago

    Extensions that target older GNOME versions will not work in GNOME 45

    So basically it’s just another GNOME release gotcha.

    Seriously though, a stable API is not the GTK/GNOME developers’ agenda here. Nobody wanting a stable API should write software with this toolkit. That said, if you’re a true front end aficionado and you’re looking to make your software look awesome every six months, GNOME has got you so covered like the chocolate on a peanut M&M.

    For those wanting to write software that won’t magically kerslode without yet another recompile (or heavily relying on your distro to do that dirty work) stick with KDE/Qt group. They tend to be less breaky each release.

    • Gecko@lemmy.worldEnglish
      8·
      1 year ago

      So basically it’s just another GNOME release gotcha.

      AFAIK, the extension developer needs to explicitly set each version of Gnome they support. Even when the Gnome version doesn’t have any breaking changes, the extension developer still needs to update their extension to enable their extension for the new Gnome version.

      • Vincent@feddit.nlEnglish
        7·
        1 year ago

        It makes sense that you have to explicitly verify that it works on every release - even if there had been no intentional breaking changes. That said, if an extension developer would really prefer to YOLO it, they could just pre-emptively add a bunch of future releases.

        (Of course, ironically that would’ve broken when they switched to 40.)

        • Natanael@slrpnk.net
          4·
          1 year ago

          It would make more sense to specify something like API versions, not software versions, and flag on the client when it changes without the addon being updated (giving you a choice to run it with a warning or not). That is, unless the version update is specifically flagged as breaking compatibility, in which case it would just warn and not offer to run it anyway until it’s been updated.

          • Chewy
            2·
            1 year ago

            Gnome doesn’t really have an extension API and instead the extensions hook directly into Gnome Shell. This allows extensions to do basically anything, but each new Gnome release might break an extension (if the used code path is changed).

    • Ddhuud@lemmy.world
      51·
      1 year ago

      I had to orphan a very simple extension I wrote for gnome 3.2-3.10 It was a bugfix that for some reason upstream didn’t even want to acknowledge it existed, and never accepted the patch. So I made the extension, but after about a year of constant breakages I gave up.

      That ordeal really made me feel unappreciated as a contributor.

    • Spectacle8011@lemmy.comfysnug.space
      1·
      1 year ago

      Seriously though, a stable API is not the GTK/GNOME developers’ agenda here. Nobody wanting a stable API should write software with this toolkit.

      This blog post doesn’t mention GTK, but I’ve heard GTK will sometimes implement breaking changes in minor version bumps. I was thinking about writing some software with GTK, and I haven’t been deterred so I guess I’ll learn the hard way, but has GTK 4 had any of these stability problems yet?