Is there a practical workflow for developing Gnome Shell extensions on Wayland?

144 views Asked by At

I'm trying to work on a Gnome Shell extension project (to see if it can be ported to Gnome 45), on a Wayland device. The workflow I have so far is:

  1. Open GEdit and edit the code.
  2. Build the extension zip.
  3. Install the extension zip.
  4. Log out of the entire system.
  5. Select my user and enter my password.
  6. Open the extension manager, find my extension, and read the error message about why Gnome couldn't load it.
  7. If there isn't one, open journalctl and use its pager to search for the most recent stack trace mentioning my extension.
  8. Open Firefox, restore session, and consult the Gnome Shell docs to figure out what isn't allowed anymore.
  9. Repeat from step 1.

I think that steps 2 and 3 could be eliminated by editing the extension code in place in ~/.local. And I think that the giant journalctl logs could be managed better with a grep for the contexts around the name of my extension, and a tail to only get the most recent ones.

But the part I just can't deal with is where every time I want to run anything I have to close down my whole dev environment, log out, log in, and open it all up again. Apparently this is needed because Wayland apps can't handle a display server that vanishes, Gnome Shell is the Wayland display server, and Gnome Shell doesn't know how to reload its extensions without restarting itself.

Is there a workaround for this? Is there a Looking Glass function call or CLI command to reload an extension on Gnome Shell 45 on Wayland? I saw this answer which gives a script to paste into Looking Glass, but I don't think it can work on Gnome Shell 45, because it needs to access stuff that needs to be imported, which on Gnome Shell 45 needs to be done with ESM import statements, which can't work in a REPL like Looking Glass.

Better yet, is there a way to run Gnome Shell in a window in a Wayland environment, so I can run my extension in a different Gnome Shell instance than the one I am using to swap between my browser and my editor? Or is there a way to run a unit test on my extension, so I can make sure it doesn't immediately crash when enabled/disabled, without loading it manually into a full Gnome Shell?

1

There are 1 answers

0
andy.holmes On

The short answer is that you should use a nested GNOME Shell, which allows running a nested instance on Wayland.

I think that steps 2 and 3 could be eliminated by editing the extension code in place in ~/.local.

This is possible, but you still need to either login/logout or run a nested session. JavaScript runtimes weren't designed to "unload" code in the way you're probably thinking.

Or is there a way to run a unit test on my extension, so I can make sure it doesn't immediately crash when enabled/disabled, without loading it manually into a full Gnome Shell?

I don't know of anyone that's come up with a good way to unit test an extension, other than reftests (see Simon Schneegan's CI tests).