Regarding GStreamer this is useful: https://gstreamer.freedesktop.org/documentation/plugins.html

This documentation was helpful in getting icons to actually work in a GTK app I am developing.

It would be really nice to get this in the nixpkgs manual.

The one problem I did run into was with hicolor-icon-theme, as mentioned above. The documentation makes it sound like all you need to do is add this as a buildInput and icons should be visible. However, it doesn't look like the hicolor-icon-theme derivation actually contains any icons. Instead I had to use gnome3.adwaita-icon-theme.

Other than that, this looks good and is a 👍 from me.

The one problem I did run into was with hicolor-icon-theme, as mentioned above. The documentation makes it sound like all you need to do is add this as a buildInput and icons should be visible. However, it doesn't look like the hicolor-icon-theme derivation actually contains any icons. Instead I had to use gnome3.adwaita-icon-theme.

Actually, nowadays I just prefer to let users install an icon theme of their own choosing.

Actually, nowadays I just prefer to let users install an icon theme of their own choosing.

What is the correct thing to do? Specify hicolor-icon-theme in buildInputs, then have the end-user specify something like gnome3.adwaita-icon-theme in environment.systempackages?

I'm guessing that adding gnome3.adwaita-icon-theme to environment.systempackages doesn't automatically add it to a system-wide XDG_DATA_DIRS, so how should this be setup? Is there something in the NixOS options that will do this automatically?

I just prefer to let users install an icon theme of their own choosing

As a developer, I'd rather have my application work for my users even if they don't have an icon theme setup correctly. It's a really bad experience if someone runs my software and icons don't work correctly. As a developer, I definitely want to avoid that.

Is there some way to set this up? For instance, I'd like to specify that my app should use the adwaita icon theme, unless the user has their own icon theme set somewhere. Do you know of a good way to do that?

The roxterm application also has this problem. If the end user doesn't have their own icon theme setup, then icons don't appear. I'd like to fix this so that icons appear even if the end user doesn't have their own icon theme setup, but I'd appreciate your input on how this should be resolved.

edit: I just took a look at both the nixos manual and the nixpkgs manual, and it doesn't look like there is anything about GTK icon themes. It might be nice to add something about this to either the nixos or nixpkgs manual, depending on how it should work.

Unfortunately, there is no other way – you either include an icon theme in the package’s closure, or you might not have icons on insufficiently configured systems. (Side note: It would be nice to have a mechanism for specifying system dependencies but we are not there yet.)

In my opinion, if you do not use DE, you are expected to create it yourself.

xdg.icons.enable = true;
environment.systemPackages = [ pkgs.gnome3.adwaita-icon-theme ];

should be enough.

I really need to write a chapter on creating a baseline freedesktop system though, as many NixOS users run some kind of bare-bones WM.

I really need to write a chapter on creating a baseline freedesktop system though, as many NixOS users run some kind of bare-bones WM.

Yeah, this would be really nice. I run XMonad, but not configured from /etc/nixos/configuration.nix. It would be great to have a guide as to how all the freedesktop stuff is supposed to work in nix.

In my opinion, if you do not use DE, you are expected to create it yourself.

What about people e.g. using nixpkgs on a non-NixOS distro? I think that such issues that can be solved at package-level should be solved at package-level to avoid delivering completely broken applications on non-GNOME environments.

What about people e.g. using nixpkgs on a non-NixOS distro?

They can still install the icon theme, either with nix or their native package manager.

I think that such issues that can be solved at package-level should be solved at package-level to avoid delivering completely broken applications on non-GNOME environments.

Well, the main issue with depending on adwaita-icon-theme is that it increases closure size for everyone, even when want to use a different icon set. Additionally, it depends on librsvg for build; though this is not currently a problem, as librsvg is already needed for wrapGAppsHook.

This pull request has been mentioned on Nix community. There might be relevant details there:

https://discourse.nixos.org/t/request-for-help-packaging-gnome-extensions/2366/2

Don't fret, just resolved the conflict and added a little commit separately.

* `GTK Themes`
  maybe not say it's no longer needed. I know for Pantheon their theme is needed or it's all broken, and they're still gtk apps.

✔️ Fixed.

* `Various plug-ins`
  I think we have duplicated docs on gstreamer, this one https://github.com/NixOS/nixpkgs/blob/ac2eb3151df879602c58280d09e9c205fcff8534/doc/stdenv.xml#L2636
   explaning the GST_PLUGIN_SYSTEM_PATH variable.

Hmm, should we move the whole setup hook section to stdenv? On the other hand, this locality is useful when reading the GNOME subchapter as a whole.

* `Icons`
  Does gtk require adwaita-icon-theme, at least as a fallback on the system?
  If so, we could say to install it.

From my test with Nautilus with adwaita-icon-theme carved out of the expression, GTK will always use gtk-icon-theme-name setting and fallback to hicolor for missing icons (e.g. application icons). So with the setting being elementary, it will not touch Adwaita icon theme. We already mention that user needs to install the theme but these details are better suited to a “Creating a custom DE” in NixOS manual.

Hmm, should we move the whole setup hook section to stdenv? On the other hand, this locality is useful when reading the GNOME subchapter as a whole.

Perhaps we should remove it from stdenv, and just keep it in GNOME sub-chapter. I'd like those setup hooks to be documented in the locality of the GNOME sub-chapter.

Updated the stdenv section:

@jtojnar That's perfect 👍

Backported in 9d8e161