Developing Gnome Shell extension is a giant waste of time

Desktop
1
  1. no examples at all, just “docs” and source code that “obfuscated” to a level where I can not even search anything by variable/class/api name
  2. I spend days reading docs, docs that missing large important pages and have lots of mistakes
  3. no test environment, no debug tools, magic “top level Shell” with its own elements that also requires learning what objects it has and events
  4. horrible extension API design, when API comes to point where “developer have to free everything created in proper order on destroy event” - this is an absolute disaster for API design. I have about 30 objects and events that connect with each other, and when I “free/destroy” them I still have memory allocated(huge memory leak) because I remove my objects/events in not correct order, and whole development come to point where I have to “brute force” combination of destroy events for 30 objects, just putting free events in new random order and test again. This is an absolute disaster of extension API design.
  5. https://wiki.gnome.org/Projects/GnomeShell/Extensions/Review half of the extensions that already in Gnome Shell extensions website don’t follow these rules and crash Gnome Shell just by enabling them.
  6. Gnome Shell has very different behavior on different Linux OS distributive(different crashes, different errors), and in one of most popular Linux on Ubuntu 20.10 Gnome shell seems to be in a very “broken” state because Gnome Shell there restart itself just by using empty “example” extension. This look very unsupported and untested, I can understand why Gnome Shell extensions disabled by default on Ubuntu.
2

So you seem a bit heated here. :slight_smile:

Developing Gnome Shell extension is a giant waste of time

People value time differently, my experiences as an extension developer have taught me a great deal and shaped my career path. So :man_shrugging:

clarifications

Some quick clarifications…

  1. Documentation is hard, and it is a moving target. We are a community-driven project, especially when it comes to Extensions. We’re compiling a lot of resources into Extensions | GNOME JavaScript and working on replacing the existing Extensions site to better support the community.

    That said, searching through GNOME Shell is very possible. Classes are named in a standard way and you can follow the imports object. Eventually we’ll probably switch to ECMAScript 2015+ imports which will make IDE support even more friendly :smiley:

    Nothing is “obfuscated”… this isn’t Minecraft server development.

  2. Try asking questions in extensions on Matrix, we’re always happy to point people in the right direction.

  3. There are some debugging tools (looking glass, for example) but realistically you’re adding JavaScript extensions onto a host application. Building “debugging” tools for that is incredibly challenging, building debugging for the Shell itself is already hard.

    If you don’t want to debug on your actual shell you can open nested shells or use a VM for testing day-to-day.

  4. There is no extension “API design”. You’re adding things on top of the existing GNOME Shell API design, which isn’t necessarily optimized for extensions.

    Other than that most “cleanup” is actually fairly straight forward if you understand at a fairly basic level how event listeners, garbage collection, dynamic languages, etc. works. (also GObject know-how is helpful)

    The rest of this commentary seems… like a very specific issue. You could (nicely) hit up the very nice people who volunteer their time to aid new extension developers… I’m fairly certain your extension could be cleaned up without massive out-of-order non-deterministic issues.

  5. Part of the problem we had was people using extensions on unsupported versions, in GNOME 40 onward the Shell won’t load unsupported extensions.

    We review for grievous cleanup errors, obvious leaks, very laggy code, and most importantly potential security issues.

    We can’t QA beyond that given current resources (we are literally volunteers) but hey there are some really cool folks working on a “smoke test” to check that an extension can at least load without crashing the shell automatically. :man_shrugging:

  6. Yeah we don’t control this, Distros which heavily modify things risk extension incompatibilities - especially if there is an extension used which doesn’t play nice with others. Fedora, Arch, and Debian provide a fairly clean experience while Ubuntu is skinned but not as heavily extended. Others like PopOS ship a very modified shell that will introduce incompatibilities.

tldr

Anyways, tldr, we’re just a bunch of nice people volunteering our time to build what we view as an amazing desktop (with extensions!). There’s always a hard balance to strike and we have limited resources.

Heated rants don’t really help the community improve, if there is specific documentation you’re missing or a specific query there are people who can help.

My two cents.

EDIT: You can find me as @ewlsh in most places now, forgot this was an older account

7 Likes
3

Thanks for the reply.

I know that and respect your work very much.
My post is “thinks can be better than it is now”.

yes till it comes to synchronization between not a single storage (not a single device where you can allocate data and bind events)
Javascript in webbrowsers Blink/Chromium has literally the same problem - its impossible to free something when it not just in default RAM.

My case with Gnome extension and GJS is - VRAM, freeing VRAM is a very “black box” in this case.

very cool to see such an active community, maybe il try it thank you

I did not expect this Gnome-related website and community to be so active, base on my experience with other opensource projects that ruled by large corporations, support there locked by ten emails and months of waiting time for an answer…

6

For future reference: you should have started with this.

Your topic uses an incendiary, needlessly confrontational style that is more typical of trolls and other platforms.

Please remember that people working on GNOME are all volunteers—even when employees of companies; companies pay people to work on their products, and some of them happen to encourage working upstream first.

An additional reminder: GNOME has a code of conduct that applies to all of its online spaces.

3 Likes
7

When you are monkey patching a code you need to know the basics and the architecture of that code. If you know that, your job is super easy.

I think at this point we have enough docs and videos to have a good start. After that, you need to read the shell ui source code.

btw, I don’t think developing extensions is a waste of time. That’s the gate to know GNOME Shell source code better and knowing that is not waste of time.

1 Like
8

This conversation can be closed.
My case is:
I spend a week of time developing extension and reading docs, endup having worked extension, and when I start testing - it bugged. Bugged because Gnome gjs tool and there no way to fix.
Bugs in basic api calls and literally no “test” or examples for these API calls this is the reason why these bugs exist.

I don’t see any connection between “bad state of the project and its developing model”
Lots of very good not-commercial free and opensource projects exist with just a single developer or few developers.
Talks about the “current state of the project” should not be censored.

10

I guess you missed:

companies pay people to work on their products, and some of them happen to encourage working upstream first.

But since this is your second contribution to this thread in which you peddle Red Hat conspiracy theories, I guess you really want to have your account banned.

3 Likes
11

can you close or delete this thread please, thanks

You don’t have permission to delete this topic. If you really want it to be deleted, submit a flag for moderator attention together with reasoning.

I mean I happy and thanksful for fast reaction and answers on this forum and Gnome Matrix that I got, so my “questions” in this thread can be count as solved (and point of this thread was not to spread toxicity, but point the problems)