@worldofpeace I'm not clear on the etiquette, hope you don't mind me pinging you here, but just thought this PR might be one you'd be best equipped to review if you get a chance as I see you've worked on a lot of pantheon/elementary PRs?

Apologies if this note is bad form, couldn't find any documentation on how to find a good reviewer for a new package.

@worldofpeace I'm not clear on the etiquette, hope you don't mind me pinging you here, but just thought this PR might be one you'd be best equipped to review if you get a chance as I see you've worked on a lot of pantheon/elementary PRs?

Apologies if this note is bad form, couldn't find any documentation on how to find a good reviewer for a new package.

Oh it's not in bad form in all. Actually, you've found the perfect person because I maintain pantheon in nixpkgs, and also can co-maintain any elementary appcenter application.
Ref https://github.com/NixOS/nixpkgs/blob/master/pkgs/desktops/pantheon/default.nix#L59.

In the future I hope we add maintainer teams

• lib: Add lib.maintainer-groups #72125

so people can discover who to request reviews on a certain domain.

It also seems you've by in large authored this
https://github.com/bytepixie/snippetpixie/graphs/contributors

That's pretty cool, thanks for submitting it to nixpkgs 👍

Thanks for the review @worldofpeace, hopefully I've addressed most of your feedback.

and this does appear to have scattered several at-spi2-* temporary directories.

I do have at-spi-bus-launcher running.

Hmm, I don't see all the warnings you see, but I suspect I'm running the build differently...

Another warning was

** (com.github.bytepixie.snippetpixie:19326): WARNING **: 05:53:30.036: Application.vala:821: Could not find desktop file with name: com.github.bytepixie.snippetpixie.desktop

This is weird because DesktopAppInfo should work because the docs state...[snip]

I don't get this warning either, the desktop file is created dynamically if missing, for me that's in ~/.config/autostart/.

So I think that's because I've just tested it as per the quick start guide after a nix-env -f . -iA snippetpixie, which means it's a local nix profile install rather than read-only system level install?

How do you build/install/test so that I can try and reproduce?

@ianmjones You can run it like

nix-build -A snippetpixie
./result/bin/$binary
$binary

and I think it should be reproduced in nix-shell too

nix-build -A snippetpixie
nix-shell -p ./result
$binary

Oh, I didn't emphasize enough that it's run uninstalled. That's why I mentioned that application is wrapped to have the nix store path with its XDG_DATA_DIR.

Edit: Completely forgot I've disabled at-spi in Pantheon due to defunct bugs. Ignore that warning.

I tested it installed and the

** (com.github.bytepixie.snippetpixie:4421): WARNING **: 18:08:44.607: Application.vala:821: Could not find desktop file with name: com.github.bytepixie.snippetpixie.desktop

error goes away. Though for the reason at

This is weird because DesktopAppInfo should work because the docs state

https://valadoc.org/gio-unix-2.0/GLib.DesktopAppInfo.DesktopAppInfo.html
GIO is looking for a desktop file with this name in the applications subdirectories of the XDG data directories (i.e. the directories specified in the XDG_DATA_HOME and XDG_DATA_DIRS environment variables).

and to support running applications uninstalled, for purity, our wrapper scripts set

export XDG_DATA_DIRS='/nix/store/fyajylfficz2kd1lnbbrg

the child process (the actual program) will inherit adding the share dir of the package to XDG_DATA_DIRS via the wrapGAppsHook script. Meaning, for reasons documented in glib, this shouldn't be an issue.

@worldofpeace Thanks for the steps to reproduce the error, I can reproduce, but I also have no idea why it doesn't find the default desktop file that's right there in ./result/share/applications/com.github.bytepixie.snippetpixie.desktop when running ./result/bin/com.github.bytepixie.snippetpixie.

When running the installed version all seems to be fine, I get a properly generated ~/.config/autostart/com.github.bytepixie.snippetpixie.desktop file based on the original. ¯\(ツ)/¯

For example, I got that shrug above with my shrug` abbreviation while writing this in Quilter, running in SwayWM, on NixOS 19.09!

@worldofpeace Thanks for the steps to reproduce the error, I can reproduce, but I also have no idea why it doesn't find the default desktop file that's right there in ./result/share/applications/com.github.bytepixie.snippetpixie.desktop when running ./result/bin/com.github.bytepixie.snippetpixie.

When running the installed version all seems to be fine, I get a properly generated ~/.config/autostart/com.github.bytepixie.snippetpixie.desktop file based on the original. ¯_(ツ)_/¯

For example, I got that shrug above with my shrug` abbreviation while writing this in Quilter, running in SwayWM, on NixOS 19.09!

Yeah, it has me confused also, should just work.

I think we can add the issue to your tracker and merge, since it does function as expected installed.
cc @jtojnar, am I confusing how works https://valadoc.org/gio-unix-2.0/GLib.DesktopAppInfo.DesktopAppInfo.html?

@ianmjones Could you rewrite your history to #75472 (comment)?

@worldofpeace If I recall correctly from my experiments with the interface, it also does some validation. Most notably whether the command referenced in Exec is in PATH.

Found the code in question for glib

• https://gitlab.gnome.org/GNOME/glib/blob/master/gio/gdesktopappinfo.c#L1785

Guess this will be an issue for glib and nixos, so I guess that's out of scope per this PR.

@ianmjones Could you rewrite your history to #75472 (comment)?

@worldofpeace Had a go, first time I've ever done that, so hopefully it's ok? I applied the maintainer list change first in the pick list, but it's date puts it second, hopefully that's not an issue.

@ianmjones Could you rewrite your history to #75472 (comment)?

@worldofpeace Had a go, first time I've ever done that, so hopefully it's ok? I applied the maintainer list change first in the pick list, but it's date puts it second, hopefully that's not an issue.

Yeah, that's just github being silly. It as actually ordered before the init.