cc #92769 (@mogorman @Technical27 @operator-name)

This looks like it might be a duplicate of #102150

Oh, right. I was certain that we already had a PR open but could not find it with GitHub search 🤷‍♀️

Oh, neat to see someone get around to packaging this! I've had a commit sitting around waiting for a 1.0 release that might help a bit - I see this doesn't install the glib schema or set the uuid like other gnome extensions.

Also, it might be nice to also package pop-shell-shortcuts (https://github.com/pop-os/shell-shortcuts) to go with it, I believe otherwise the extension will try to open a website with the shortcuts.

Here's my commit for pop-shell that does both things I mentioned: https://github.com/maxeaubrey/nixpkgs/commit/e46df8ddff5facaf57b86e5e7d5be189000e15a1
And here's pop-shell-shortcuts: https://github.com/maxeaubrey/nixpkgs/commit/5c14f15e6a2bfc9b6a11457ccb048a3668f10259

@maxeaubrey Looking at the source code, it should install schemas:

https://github.com/pop-os/shell/blob/1.0.0/Makefile#L74
https://github.com/pop-os/shell/blob/1.0.0/Makefile#L43

@maxeaubrey I had uuid set first, but i was advised to remove it if it is unnecessary.
Regarding pop-shell-shortcuts: I haven't had the problem with the website opening up and currently am using the package without shell-shortcuts. But maybe it's a good thing. Maybe putting it up as a second package is a good idea.

@remunds Oh, I guess uuid is obsolete now? 🤷‍♀️ Fair enough.

@jtojnar I had problems with the schema being missing and the extension not working correctly otherwise, but I cannot reproduce right now. Soz, what I said can be ignored on that.

I would recommend submitting patches upstream for locating the system path if the default GLib subprocess launcher can't find the binaries in your system path. You may add additional search paths with a subprocess launcher. There are a couple areas in Pop Shell that call out gjs, including some of the default plugins which are gjs scripts.

@mmstick The point of Nix is that there is not system path – every package is self-contained and hardcodes paths to everything it needs (in theory anyway). For some things like script shebangs, we have tooling that hardcodes the correct path but for exec calls in code, a more manual approach is required.

The code that manually calls upon gjs can be changed to make use of the shebang line.

Right, that would be better for us too, we did the same with GSConnect. @remunds are you able to submit such patch upstream?

I've found another issue, although I'm not sure if it's maybe only on my end:
Deactivating "Show window titles" doesn't hide title bars.

This one is probably due to using Wayland where this is not supported upstream.

@jtojnar I will have a look at that later that day, but I am not sure whether I am capable enough. I'll let you know. Do I understand it right that the current approach is to create a patch that puts the shebang #!/usr/bin/env gjs in every file that needs it and then somehow modify the way those files are called?

@ymarkus that works for me.

@remunds Yes, that is correct. The files need to be invoked as scripts. Also, for that to work, you will need to make them executable if they are not already.

I'll give that a try, thanks :)

I was able to get the "floating window exception"-window with the other approach though.

Now its just the active hint color that doesn't work. Does anyone have an idea?

I've been using this for a few weeks now (updated to 1.2.0 though) on NixOS 20.09 under GNOME 3.36.5 Wayland and apart from the known upstream Wayland wonkiness, this actually works quite nicely.

Tangentially related in case anyone is interested: https://blog.system76.com/post/648371526931038208/cosmic-to-arrive-in-june-release-of-popos-2104

https://github.com/pop-os/cosmic

It has pop-shell as a dependency.

I marked this as stale due to inactivity. → More info

Solved in #147542 - i believe we could close this PR now.
Maybe you add yourself to maintainers ;)