Tested and merged it, thanks :)

@primeos and @not-fl3, sorry for necrobumping but I just want to learn why this approach is better than just adding wrapGAppsHook to the nativeBuildInputs. That is how I "solved" the problem on my own setup and it feels a bit cleaner because

• there is less repetition since we don't end up redefining the same env vars in every individual package,
• the wrapper can be improved (or broken 😝) and all packages that utilize it will reflect the change
• the wrapper does a bunch of things that are probably good practice in terms of GTK app house-keeping but aren't failing yet because a situation hasn't presented itself to remind us that perhaps the setup is still lacking.

I could imagine that the approach in the PR is better in that it only provides the minimal change necessary to resolve the reported error whereas the wrapper may end up doing a lot more that isn't directly related to this problem.

Would like your 2cts on this. Just trying to learn what to do the next time I run into a similar issue 😉

@vidbina Thanks for your comment :) The answer is actually pretty simple, I just wasn't aware of wrapGAppsHook (should probably be documented in the nixpkgs manual).

Using wrapGAppsHook for this is a better solution (but obviously the old solution worked fine as well) and might fix some other/future potential errors as well (like you've stated). I've changed it in 9a4871a. I've used it a bit differently to avoid creating two wrappers (or even three, if it wraps the existing wrapper and the binary).

@primeos kewl. Asked another noob questions about the [@] bit in gappsWrapperArgs[@] as a comment to your commit. I agree that it should be added to the docs, I also just learned about it after someone commented about it on a GitHub thread I was tracking. And even if it is documented, I don't always find the docs too intuitive to explore.