GNOME Shell extensions support

[balsoft]

It would be awesome if home-manager would be able to change GNOME Shell configuration. I believe that extensions would be a good place to start, as they simply are directories under ~/.local/share/gnome-shell/extensions.

[rycee]

Yeah, that would indeed be awesome! 🙂 Right now Home Manager is only able to configure GNOME Terminal (through the dconf command line tool) which has been working quite well for me.

I'm not using GNOME Shell, though so I can't really work on this module myself but I would be happy to assist.

For the specific case of extensions it does indeed seem pretty straight forward from what I can tell, just to put the unzipped extension directories in the right place and enable the extensions through dconf.

[balsoft]

@rycee , that's exactly what I though about :+1: Right now I'm trying to understand how to write home-manager modules and it seems pretty straight-forward. Tomorrow I'll try to implement a first version.

[balsoft]

Actually, after some research it appears to me that it would be nicer if we would use the already-existant DBUS interface for installing extensions (org/gnome/Shell org.gnome.Shell.Extensions). There are InstallRemoteExtension(string uuid), ListExtensions() methods. Although there is a caveat: InstallRemoteExtension requires user interaction (it shows a dialog asking user if he wants ti download and install extension). It would be a nuissance to install all extensions every time, so I think first we should ListExtensions and figure out what exactly we need to install&enable and what we need to disable. Although I don't quite know of any way to do that. Another option is, as @rycee already mentioned, is to just fetch tarballs manually, then link them to ~/.local/share/gnome-shell/extensions and enable them with dconf. In short: should I use DBUS or fetchTarball for installing extensions?

[rycee]

To download extensions at activation time is not really an option, mostly because it reduces atomicity (i.e., we cannot guarantee that activating a generation twice will install the exact same extension binary). We also cannot guarantee that there actually is networking available.

Neither is doing graphical prompts since the activation may happen when no graphical interface is available, for example when using the Home Manager NixOS module. Unfortunately, at the moment dconf doesn't work when using the NixOS module because the session dbus is not available but at least this should be a solvable problem.

So yeah, the extensions should be downloaded using a fetch command and put into place by Home Manager.

[balsoft]

Thank you for the explanation. I am currently working on the module.

чт, 7 июн. 2018 г. в 21:18, Robert Helgesson [email protected]:

To download extensions at activation time is not really an option, mostly because it reduces atomicity (i.e., we cannot guarantee that activating a generation twice will install the exact same extension binary). We also cannot guarantee that there actually is networking available.

Neither is doing graphical prompts since the activation may happen when no graphical interface is available, for example when using the Home Manager NixOS module. Unfortunately, at the moment dconf doesn't work when using the NixOS module because the session dbus is not available but at least this should be a solvable problem.

So yeah, the extensions should be downloaded using a fetch command and put into place by Home Manager.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rycee/home-manager/issues/284#issuecomment-395516626, or mute the thread https://github.com/notifications/unsubscribe-auth/ARnLU204IVm2ksH9dX7g66CzPImWlnNvks5t6W6AgaJpZM4Ua-wB .

-- С уважением, ученик МБОУ "Гимназия №2 "Квантор" Бантьев Александр [email protected] [email protected]

Best regards, Alexander Bantyev aka balsoft [email protected] [email protected]

[rliang]

The following example works for me. You can also replace fetchGit with fetchTarball or something for stable versions.

{ pkgs, ... }: {
  home.file.".local/share/gnome-shell/extensions/[email protected]".source = builtins.fetchGit {
    url = "https://github.com/rliang/gnome-shell-extension-tilingnome.git";
  };
  dconf = {
    enable = true;
    settings = {
      "org/gnome/shell".enabled-extensions = ["[email protected]"];
    };
  };
}

[bjornfor]

If the extension is in nixpkgs you can also do this:

{ pkgs, ... }:
{
  dconf.settings."org/gnome/shell".enabled-extensions = [
    pkgs.gnomeExtensions.clipboard-indicator.uuid
    pkgs.gnomeExtensions.system-monitor.uuid
  ];
}

[terlar]

This is a quite complete solution in the wild: https://github.com/tadfisher/flake/blob/master/home/modules/programs/gnome-shell.nix

Perhaps @tadfisher would like to upstream it. I created a ticket for it: https://github.com/tadfisher/flake/issues/1

I wonder for it to work with user-installed packages though, I think we have to symlink all of them into ~/.local/share/gnome-shell/extensions/${uuid} as well.

[terlar]

I extended the module with the following code:

      dconf.settings."org/gnome/shell".disable-user-extensions = false;

      xdg.dataFile = listToAttrs (map ({ id, package }: {
        name = "gnome-shell/extensions/${id}";
        value = { source = package; };
      }) cfg.extensions);

This ensures the extensions are symlinked into the correct place and will appear on user installations and won't have to be added as system packages. Also it ensures that the user extensions are not false so they will be enabled.

[tadfisher]

@terlar Thanks, I'll clean up my module and get a PR up here. Glad to see that someone can find use out of it.

[terlar]

Thank you @tadfisher, greatly appreciated. Not sure if you noticed my previous comment, since it was 1 min apart. But that might save you some time, if you plan to incorporate that.

[tadfisher]

@terlar Your expression doesn't work for extensions in nixpkgs, because they produce $out/share/gnome-shell/extensions/${uuid} in their outputs. So I'm modifying it to symlink that path instead.

[terlar]

@tadfisher I am also using extensions from nixpkgs and it is working. The thing is that home manager xdg.dataFile resolves to ~/.local/share, this name here refers to the attribute that will be added to the xdg.dataFile attribute set.

https://github.com/nix-community/home-manager/blob/master/modules/misc/xdg.nix#L68

E.g. It will result in:

xdg.dataFile."gnome-shell/extensions/${id}".source = package

[tadfisher]

@terlar see https://github.com/nix-community/home-manager/pull/1795

[tadfisher]

@terlar That will result in a symlink to the path root in /nix/store, so you end up with ~/.local/share/gnome-shell/extensions/${id}/share/gnome-shell/extensions/${id}.

[terlar]

Ah! Yes, you are right, I checked mine and that is how it is, so perhaps it is working due to me getting the XDG_DATA_DIRS working at the same time. I thought it was not respecting the XDG_DATA_DIRS because it was not working, so then I added this, but perhaps I fixed the XDG_DATA_DIRS at the same time. In that case this is not needed, sorry for the confusion, what do you think should we skip it then? Since the packages are installed via home.packages and ending up in the profile.

[tadfisher]

I don't think just adding to home.packages will work for non-NixOS systems, but I could be wrong. But then again, I'm not sure how adding extension packages to home.packages worked in the first place, given that NixOS links $out/share of packages into $XDG_DATA_DIRS in the system environment, so I wouldn't expect packages in home.packages to be added this way.

@rycee Could you shed some light on this? I suspect xdg.mime is making this possible through

XDG_DATA_DIRS=$out/share

but that's not guaranteed if $out/share/mime/packages doesn't exist in the profile.

[rycee]

Sorry, I don't know anything about how GNOME Shell extensions work so I can't help much. I also don't know much about xdg.mime since I don't use that either 🙂

[tadfisher]

I think in the long term, centralizing XDG_DATA_DIRS in a configuration option makes the most sense. Currently we have two separate modules (targets.genericLinux and xdg.mime) competing to be the source of truth. If we have something like xdg.system.dataDirs, then we can populate it with the $out/share dir of each extension package, avoiding the need to symlink into XDG_DATA_HOME and allowing users to develop extensions in that prefix.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

If you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information.

Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[terlar]

There is a PR for this and it is almost mergeable. It is still a valid and useful request.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

If you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information.

Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[terlar]

@tadfisher Would you like to update the PR #1795 to make it ready for merge, if you don't have time, I guess I could take a stab at it as well. It is only the final uuid attribute rename that needs to be handled as far as I can tell.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

If you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information.

Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[terlar]

Still interested in this, will try to bump it up on my prio-list

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

If you have nothing of substance to add, please refrain from commenting and allow the bot to close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information.

Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[terlar]

Time flies, was busy with personal matters, hopefully can get some time soon

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[terlar]

There is now an open PR for this (#2843)

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.