Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: add GNOME #43150

Merged
merged 3 commits into from
Sep 9, 2019
Merged

doc: add GNOME #43150

merged 3 commits into from
Sep 9, 2019

Conversation

jtojnar
Copy link
Member

@jtojnar jtojnar commented Jul 7, 2018

Work in progress documentation on packaging GNOME ecosystem applications. Comments and questions welcome.

Closes: #16285

@jtojnar jtojnar added 6.topic: GNOME GNOME desktop environment and its underlying platform 2.status: work-in-progress This PR isn't done 8.has: documentation This PR adds or changes documentation 9.needs: community feedback labels Jul 7, 2018
<title>Icons</title>

<para>
When an application uses icons, an icon theme should be available in <envar>XDG_DATA_DIRS</envar>. The default <link xlink:href="https://www.freedesktop.org/wiki/Software/icon-theme/">hicolor-icon-theme</link> is recommended, unless the application needs some specific icons not available in there.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently, hicolor-icon-theme does not contain any icons. Nevertheless, we should mention it for its setup hook that removes index.theme files.

</listitem>
<listitem>
<para>
<package>gobjectIntrospection</package> setup hook populates <envar>GI_TYPELIB_PATH</envar> variable with <filename>lib/girepository-1.0</filename> directories of dependencies, which is then added to wrapper by <package>wrapGAppsHook</package>. It also adds <filename>share</filename> directories of dependencies to <envar>XDG_DATA_DIRS</envar>, which is intended to promote GIR files but it also <link xlink:href="https://github.com/NixOS/nixpkgs/issues/32790">pollutes the closures</link> of packages using <package>wrapGAppsHook</package>.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to fix the pollution.

@GrahamcOfBorg GrahamcOfBorg added 2.status: merge conflict This PR has merge conflicts with the target branch and removed 6.topic: GNOME GNOME desktop environment and its underlying platform labels Jul 7, 2018
@jtojnar
Copy link
Member Author

jtojnar commented Jul 21, 2018

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

cdepillabout added a commit to cdepillabout/termonad that referenced this pull request Dec 27, 2018
This uses wrapGAppsHook to be able to make it so that Termonad can see
the GTK icons it uses.

This is as described in NixOS/nixpkgs#43150.

It appears that hicolor-icon-theme doesn't actually contain any icons,
so instead I'm using adwaita-icon-theme.
@cdepillabout
Copy link
Member

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.

@jtojnar
Copy link
Member Author

jtojnar commented Dec 27, 2018

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.

@cdepillabout
Copy link
Member

cdepillabout commented Dec 27, 2018

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.

@jtojnar
Copy link
Member Author

jtojnar commented Dec 27, 2018

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.

@cdepillabout
Copy link
Member

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.

@Ma27
Copy link
Member

Ma27 commented Jan 12, 2019

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.

@jtojnar
Copy link
Member Author

jtojnar commented Jan 12, 2019

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.

@nixos-discourse
Copy link

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

@worldofpeace
Copy link
Contributor

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

@worldofpeace
Copy link
Contributor

worldofpeace commented Sep 5, 2019

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.

@jtojnar
Copy link
Member Author

jtojnar commented Sep 6, 2019

Updated the stdenv section:

image

@worldofpeace
Copy link
Contributor

@jtojnar That's perfect 👍

@jtojnar jtojnar force-pushed the gnome-docs branch 3 times, most recently from 0aa3f23 to 6275823 Compare September 6, 2019 04:18
@jtojnar jtojnar merged commit 23e2a6c into NixOS:master Sep 9, 2019
@jtojnar jtojnar deleted the gnome-docs branch September 9, 2019 22:50
@jtojnar
Copy link
Member Author

jtojnar commented Sep 10, 2019

Backported in 9d8e161

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.status: work-in-progress This PR isn't done 8.has: documentation This PR adds or changes documentation 9.needs: community feedback 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Document wrapGAppsHook
7 participants