Making gsettings see a schema from a derivation

Elyhaka · March 17, 2020, 4:57pm

Hello,

I’m currently creating the derivation for the new pop-shell extension for gnome-shell. It works well but I have an issue making it detect the gsettings schema:

While the file is placed in the correct folder inside my derivation:

{ stdenv, fetchFromGitHub, nodePackages, glib }:

stdenv.mkDerivation rec {
  pname = "gnome-shell-extension-pop-shell";
  version = "2020-03-16";

  src = fetchFromGitHub {
    owner = "pop-os";
    repo = "shell";
    rev = "843f1c764a165896787f539bd2532c52e458aa46";
    sha256 = "141l90l4xm3m0vspsmbysc040agmn2b2rq37l61b2nn39zkxaxdn";
  };

  nativeBuildInputs = [
    nodePackages.typescript
    glib
  ];

  makeFlags = [ "INSTALLBASE=$(out)/share/gnome-shell/extensions" ];

  postInstall = ''
    mkdir -p $out/share/gsettings-schemas/pop-shell-${version}/glib-2.0
    cp -R $out/share/gnome-shell/extensions/${uuid}/schemas \
          $out/share/gsettings-schemas/pop-shell-${version}/glib-2.0/schemas
  '';

  uuid = "pop-shell@system76.com";

  meta = with stdenv.lib; {
    description = "i3wm-like keyboard-driven layer for GNOME Shell";
    homepage = "https://github.com/pop-os/shell";
    license = licenses.gpl3;
    maintainers = with maintainers; [ elyhaka ];
    platforms = platforms.linux;
  };
}

Is there something needed to “announce” that the derivation is providing a gsettings schema ?

Additional information:

If that’s relevent, i’m installing this derivation from my home-manager profile.

Thank you very much !

jtojnar · March 17, 2020, 6:46pm

The schemas are supposed to be in $out/share/gnome-shell/extensions/$uuid/schemas:

github.com

pop-os/shell/blob/51791470a7ed187de7e175b845a13b9809ac7c9f/src/settings.ts#L10


      
          const ExtensionUtils = imports.misc.extensionUtils;
          const extension = ExtensionUtils.getCurrentExtension();
          const Gio = imports.gi.Gio;
          
          
export class Settings {
              inner: any;
          
          
    constructor(schema: string) {
                  const GioSSS = Gio.SettingsSchemaSource;
                  const schemaDir = extension.dir.get_child("schemas");
          
          
        let schemaSource = schemaDir.query_exists(null) ?
                      GioSSS.new_from_directory(schemaDir.get_path(), GioSSS.get_default(), false) :
                      GioSSS.get_default();
          
          
        const schemaObj = schemaSource.lookup(schema, true);
          
          
        if (!schemaObj) {
                      throw new Error("Schema " + schema + " could not be found for extension "
                          + extension.metadata.uuid + ". Please check your installation.")

There should be a XML file and a gschemas.compiled file.

The extension’s schemas are not available globally so dconf-editor will not see them. That really should not be taken for granted even with regular apps that install the schemas to regular path.

Elyhaka · March 17, 2020, 7:08pm

Thanks for your answer:

They are indeed there, the postInstall was a try.

They are both indeed there.

Noted for dconf-editor. Is it also available for gsettings list-schemas ?

The base issue that made me think this was related to the gsetting schema is that the extension seems to have trouble reading its value from dconf. Maybe it’s an upstream issue, if that’s the case I will report it to them

jtojnar · March 17, 2020, 7:58pm

dconf-editor is slightly stronger since it shows all things stored in the configuration databases (even when schema for the data is not available).

gsettings tool is fully dependent on the schemas being available and it cannot show things that it lacks schemas for. (On Nix, we rely on the schemas being found in XDG_DATA_DIRS environment variable.)

Unfortunately, due to the global nature of GSettings system we sometimes have to resort to ugly hacks so it is likely our bug. Could you share more details about the issue you are seeing?

Elyhaka · March 17, 2020, 8:44pm

The issue I’m seeing is the following:
for the context : In this extension you can choose the gaps between the windows (like i3 if you’re familiar with it)

This gap value is set inside a menu:
When changed in the menu, the value is saved in its dconf variable and the gaps change.
If I change the value from dconf-editor nothing happens.

But the strange parts is this :

When I reboot the value in dconf is still the one set from the menu, but the menu shows the default value (16). EDIT : The gaps are also at 16 and not 8. It’s like the setting is completely ignored.

More context:

I’ve tried to set the value directly with dconf from home-manager :

dconf = {
  enable = true;
  settings = {
    "org/gnome/shell/extensions/pop-shell" = {
      "active-hint" = false;
      "gap-inner" = 8;
      "gap-outer" = 8;
      "show-title" = false;
      "snap-to-grid" = false;
      "tile-by-default" = true;
    };
  };
};

Even with this, it still loads 16 when rebooting which gave me the impression that it was kind of related to the schema.

jtojnar · March 18, 2020, 12:12am

Looking at the schema, the value is not regular integer but an unsigned one:

github.com

pop-os/shell/blob/51791470a7ed187de7e175b845a13b9809ac7c9f/schemas/org.gnome.shell.extensions.pop-shell.gschema.xml#L10


      
          <?xml version="1.0" encoding="UTF-8"?>
          <schemalist gettext-domain="pop-shell">
              <schema id="org.gnome.shell.extensions.pop-shell" path="/org/gnome/shell/extensions/pop-shell/">
                  <!-- Appearance Options -->
                  <key type="b" name="active-hint">
                      <default>false</default>
                      <summary>Show a hint around the active window</summary>
                  </key>
          
          
        <key type="u" name="gap-inner">
                      <default>16</default>
                      <summary>Gap between tiled windows</summary>
                  </key>
          
          
        <key type="u" name="gap-outer">
                      <default>16</default>
                      <summary>Gap surrounding tiled windows</summary>
                  </key>
          
          
        <key type="b" name="show-title">

If you use the dconf tool (CLI variant of dconf-editor), you will see the value in the database:

$ dconf dump /org/gnome/shell/extensions/pop-shell/
[/]
gap-inner=uint32 10

I do not think home-manager supports creating values in other types than Nix supports at the moment:

Elyhaka · March 18, 2020, 7:39am

Oh, I think I understand now ! Thank you

EDIT : I confirm, using the quickfix extraSettings PR I’ve made on home-manager to force the type made it works correctly.

The fun fact is I encountered this exact same issue in dconf module of home-manager but for another type that I could not express (array of tuple-2 of strings). I didn’t realized that it was in fact the same issue.

I’ll try to do some testing on the gvariant branch, to see if I can map all of the edge-cases I’ve found :).

Is there any example of how gvariant types can be used ?

pbogdan · April 9, 2020, 11:18am

Sorry for bumping an old thread - are you planning to PR this to nixpkgs at some point @Elyhaka?

Elyhaka · April 9, 2020, 11:35am

Hello, not at all, but for a good reason : the home-manager teams worked on a way better approach than me for this issue !

pbogdan · April 9, 2020, 11:37am

Oh, I meant just pop-os-shell derivation itself, sorry for the confusion!

Elyhaka · April 9, 2020, 11:48am

No problem ! My bad

I’m not sure I will make a PR until the first stable release. And even then, I will do the PR only if I use it on a daily basis (meaning that’s good enough for a daily usage). Otherwise, I could miss some updates, and not maintain it properly.

But anybody that wants to take maintainership of this package can use the derivation I’ve created as a base and open a PR (cf. the first message of this thread), it was working quite well when I opened this thread (not tested it since ~20 days, because of containment I cannot access to my work computer which is the one on Gnome).

pbogdan · April 9, 2020, 12:08pm

No worries . And yeah, that makes perfect sense. I might give it a spin via local overlay instead, thank you for posting the derivation in this thread.

matthew · July 29, 2020, 3:35pm

Hi @Elyhaka! Thanks for your work on this. I’m new to NixOS (coming from Pop!_OS) and, if you are willing, I’d really appreciate walking through on how to get pop-shell working on my otherwise vanilla GNOME NixOS 20.03 configuration. The two main questions I have are: 1) how do I configure Nix to use GNOME from the unstable channel (i.e., 3.36 or later), and 2) how/where do I write the code for installing GNOME extensions and pop-shell [from GitHub]? Thank you again!

P.S. I’m sure both of these questions are fairly standard, I’ve just unfortunately not been able to find relevant docs yet!

Elyhaka · July 29, 2020, 4:02pm

Hello @matthew, welcome to NixOS .

Unfortunately I might be able to help you only for the second point. I’ve never used a gnome version from another channel, maybe somebody of this thread can give you a hint on this one.

On the “where to write the code” question, you must create a file that will contain the derivation to build the extension, let’s say /etc/nixos/pop-shell.nix.
Once done, you have to add (pkgs.callPackage ./pop-shell.nix {}) inside the environment.systemPackages array, that should be enough.

I should disclaim that since I wrote the original derivation the extension might have been updated (and that the build procedure declared in the derivation might be obsolete, and thus broken, for newer version).

matthew · July 29, 2020, 4:43pm

Thanks for the quick response @Elyhaka!

I just simply switched my entire NixOS configuration to nixos-unstable, which gives me GNOME 3.36.

Now, as far as trying to get pop-shell working-- should I try to update the fetchFromGitHub call with a new rev and sha256?

What else might I need?

Elyhaka · July 29, 2020, 5:01pm

I’ve tried it, and switching the src to:

  src = fetchFromGitHub {
    owner = "pop-os";
    repo = "shell";
    rev = "9e8ab29cb976b078aa6e8fab59b09527a092a1b8";
    sha256 = "1za5jj95p095z4ffjli0ir3prd8fiv2bdjgjmb7h6wnni65cwfa3";
  };

seems to be enough

matthew · July 29, 2020, 5:03pm

Great! I tried using nix-prefetch-url myself to get the SHA256 hash, but somehow I ended up with a different hash than yours for the same source commit. I just passed https://github.com/pop-os/shell/archive/9e8ab29cb976b078aa6e8fab59b09527a092a1b8.zip to it. Am I doing something wrong?

Elyhaka · July 29, 2020, 5:05pm

It will be easier to simply change the rev (commit hash) then change the hash itself. It is the “more natural” way of doing it when interacting with Github projects.

EDIT: Oh, I’ve misunderstood your question. To obtain the right hash I’ve used nix-prefetch-git not nix-prefecth-url. The former will hash the content of the repository while the latter will hash the archive itself, thus making the difference you noticed.

matthew · July 29, 2020, 5:16pm

Ahh, that makes sense! Thanks again! You’ve been a tremendous help.

I have pop-shell running now, works well! Sweet.

matthew · July 31, 2020, 3:57pm

Hi @Elyhaka sorry to bother you again, but I’ve noticed in using pop-shell this week that the Ctrl+/ quick launcher only allows already opened apps to be switched to/launched. Do you have the same experience?