106

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.

top 50 comments
sorted by: hot top controversial new old
[-] aphlamingphoenix@lemm.ee 38 points 1 year ago

I am a daily Gnome user. There are many things which I actually dislike about Gnome, but I have solved them all through extensions. Fine, I'm not bothered because it can be customized.

But every time they introduce something like this, it takes me a while to get a functional desktop back. It takes time for those extensions' developers to respond to these things. They have to research the change, implement it, test it, go through extra work to stay backward compatible, etc. These people aren't being paid for this, so it takes some time.

I'm just frustrated about this. I know someday I will run updates and suddenly find all my extensions broken.

[-] zephr_c@lemm.ee 18 points 1 year ago

I really, really hope Cosmic turns out to be a good DE, because Gnome does a lot of cool stuff that I really like, but the actual experience of using it is miserable for me. It always feels like it's fighting against everything I want to do.

I'm glad Gnome exists, but we need an option that does some of the cool and unique things they do while also being less opinionated.

[-] Holzkohlen@feddit.de 1 points 1 year ago

I mean there are a bunch of GTK based desktops besides Gnome already. Mint team's Cinnamon, Budgie, Pantheon, Mate and of course: XFCE

[-] aksdb@feddit.de 3 points 1 year ago

None of them support Wayland, though.

[-] zephr_c@lemm.ee 1 points 1 year ago

I know, and I've used all of them. I'm currently using Cinnamon. There's a lot more to Gnome then just gtk though.

[-] regalia@literature.cafe 16 points 1 year ago

Agree, my work flow is basically entirely broken without dash-to-panel, which is maintained by like one guy lol.

[-] selokichtli@lemmy.ml 3 points 1 year ago

The ideas behind the GNOME Shell desktop metaphor have stayed consistent through the 3.x cycle, at least from ~3.10. The "problem" with GNOME 3.x is that it implements core ideas in the workflow that the user needs to grasp. Either you use it as they thought you should or you are better off with some other DE.

Sure, you may need some extension to feel more comfortable. I do use a couple, but if you need extensions to make it functional you really should consider switching to another DE/WM.

[-] aphlamingphoenix@lemm.ee 2 points 1 year ago

I really like a lot about Gnome. It's things like getting rid of the system tray that don't make sense to me. I understand it's not in the system's ideology, but you can't force that on every application developer who still has to support that feature for other desktops. If it's a common application feature, then it's just broken on Gnome. That's a hard thing to sell me.

[-] selokichtli@lemmy.ml 1 points 1 year ago

This is why I feel more comfortable using Cinnamon in my main PC, but I still use GNOME in my laptop.

[-] skadden@ctrlaltelite.xyz 1 points 1 year ago

Yeah, it's kind of ridiculous. At this point my most starred git repos are all patches to get various extensions working on the current gnome release.

I've been looking to switch away but nothing I've used has had the it factor I want.

[-] const_void@lemmy.ml 0 points 1 year ago

One of the reasons I prefer KDE or MATE. Too many extensions needed to make it usable. I also don't like the fact that they're installed through their website instead of your local package manager.

[-] bennyp@kbin.social 31 points 1 year ago

It will be annoying for a minute but this change is good: it will help developers ship extensions faster and with fewer bugs by using standard JavaScript modules and IDE support. As mentioned in the blog: modules were standardized in 2015! At what point does it become acceptable to drop non-standard features?

load more comments (4 replies)
[-] IHeartBadCode@kbin.social 29 points 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.world 8 points 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.nl 7 points 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 points 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.

[-] Chewy7324@discuss.tchncs.de 2 points 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).

[-] AProfessional@lemmy.world 6 points 1 year ago

GTK never broke public API.

[-] Ddhuud@lemmy.world 4 points 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.

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?

[-] LeFantome@programming.dev 21 points 1 year ago

I am all for hating in GNOME for constantly breaking things. In this case though, are they not moving away from their non-standard system to the JavaScript standard? That seems like something to be supported and, in the long run, it will likely lead to less breakage.

Or am I misunderstanding?

[-] Crazazy@feddit.nl 3 points 1 year ago* (last edited 1 year ago)

Yes but it would have been nicer to have a transition period in which both methods are supported for a little while so that you don't literally break every extension in existence up to this release

[-] Koffiato@lemmy.ml 2 points 1 year ago

I find it naive to think GNOME would suddenly start caring about compatibility as moving to a standard doesn't guarantee such.

[-] Vincent@feddit.nl 21 points 1 year ago

I will say, as a JavaScript developer, the new module system is a pain everywhere. Node.js went to great pains to allow for an upgrade path without breaking changes, and it's still a PITA for developers because there are so many edge cases that could go wrong, so you still have to actually keep testing in both older and newer versions.

A hard break like this is painful, but I'm not sure if there's a better solution. On the upside, it looks like it'll be easier for someone like me to contribute fixes for this, even if I don't know the specifics of extension development otherwise.

[-] OldFartPhil@lemm.ee 15 points 1 year ago

See, this is the beauty of running Debian stable as your daily driver. I'll be on Gnome 43 for two more years, so by the time I upgrade to Gnome 45+ extensions should be compatible. Only half-joking, I really do avoid a lot of early adopter regressions and breakage.

[-] aleph@lemm.ee 1 points 1 year ago

Arch does too, albeit to a lesser extent. Gnome updates usually take around 4 to 5 weeks after the official release to hit the Pacman repos.

Means you can stay bleeding edge but avoid day 1 breakages for the most part.

[-] warmaster@lemmy.world 1 points 1 year ago

Is there a distro that ships with the latest kernel and gnome packages?

[-] hottari@lemmy.ml 1 points 1 year ago

Opensuse Tumbleweed.

[-] regalia@literature.cafe 11 points 1 year ago

So what I'm reading is to wait to upgrade until my dash-to-panel and app-indicator extensions are updated

[-] d_k_bo@feddit.de 10 points 1 year ago

gnome-shell-extension-appindicator moved to the new modules system 3 weeks ago

[-] dingdongitsabear@lemmy.ml 7 points 1 year ago

I have a question: wtf is javascript doing in a modern desktop?

[-] bamboo@lemm.ee 18 points 1 year ago

Yeah! They should have invented their own obscure language for no reason rather than use probably the single most well known programming language on earth!

load more comments (2 replies)
[-] Ddhuud@lemmy.world 9 points 1 year ago

The same it does everywhere else. Capitalizing on the sheer number of web devs, and the fact that we get things done without being petty about things we don't like.

[-] d3Xt3r@lemmy.nz 8 points 1 year ago* (last edited 1 year ago)

Um, you're like more than a decade too late to ask this question. Javascript is pretty much everywhere now, whether you like it or not.

For the record, I dislike it as well - not the language itself mind you, but the fact that they're using it to make bloated desktop apps and desktop UX. Long gone are the days when devs cared about performance, sometimes going as far as writing code in ASM to get the most out of paltry hardware.

Nowadays, even a $25 computer like the Raspberry Pi has enough computing resources to run bloated JS apps, so no one really cares any more, except for old fogies like us who grew up using entire operating systems that fit on a single floppy disk.

[-] Holzkohlen@feddit.de 3 points 1 year ago

I like to tell people Chris Sawyer wrote Rollercoaster Tycoon 1 and 2 by himself entirely in ASM. Still amazing games in 2023

[-] d3Xt3r@lemmy.nz 1 points 1 year ago* (last edited 1 year ago)

Equally (or more?) impressive is the procedurally generated 3D FPS .kkrieger, which weighed a paltry 96KB. 96KB in 2004 was quite impressive, considering that Doom, released a decade prior, was 2.39 MB, and even the original Wolfenstein 3D, released in '92, was 1MB.

[-] AProfessional@lemmy.world 2 points 1 year ago* (last edited 1 year ago)

JavaScript itself is not particularly bloated. It is smaller than Python and fast as luajit. Probably the best scripting choice.

If you want to write a modern shell in assembly have fun.

[-] d3Xt3r@lemmy.nz 2 points 1 year ago

I never claimed that Javascript itself was bloated - it's about using the right tool for the right job. The bloat comes from using awful frameworks like Electron to create fake "native" apps, and then fooling users into thinking they're getting a native app, wasting tons CPU resources and sysadmin time trying to fix these bloody Electron apps into shape (speaking as a DevOps guy).

Also, there's a world of options to chose from for shell programming that strike a better balance between performance and practicality, in the spectrum between ASM and JS. Oh, and writing a modern shell in ASM is most definitely fun, you should give it a try sometime. ASM shells - actually, entire operating exists already, if you aren't aware of it. You really should check out MenuetOS or KolibriOS sometime. Sure, it's nothing more than a hobby project, but it's quite fun to take it for a spin, and experience a preview of how fast and effecient operating systems could be.

[-] LeFantome@programming.dev 1 points 1 year ago

You could still get a basic Linux system on a floppy if you really wanted to.

[-] d3Xt3r@lemmy.nz 1 points 1 year ago

Yeah, but not a full-fledged GUI OS with all your basic GUI tools, including a GUI web browser. QNX had a floppy version back that that fit everything - even a bunch of games - on a single 1.44MB floppy.

In saying that, there are modern GUI OSes which you can fit on a floppy, such as MenuetOS and KolibriOS. And because they're coded fully in assembly, it can actually fit and do a lot more that what QNX-floppy could do back then, which is very impressive for modern code.

load more comments (2 replies)
[-] ikidd@lemmy.world 5 points 1 year ago

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.

Holy fucking lol

load more comments (1 replies)
load more comments
view more: next ›
this post was submitted on 03 Sep 2023
106 points (98.2% liked)

Linux

47984 readers
1992 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS