Link to `Contents` folder in trampoline instead of creating separate app?

[christian-burger]

When investigating how to solve the general issue of putting Nix Apps into Spotlight and the Dock. Did you originally try to link the Contents folder in your trampoline instead of creating a whole seperate App with applet and your custom Info.plist?

I ask, because this works for me and solves the issue I'm addressing in #26. It would not just make the whole set-up easier, but makes #24 not your problem any more, because then it is in LnL7/nix-darwin's purview.

And this might solve #17, though I cannot reproduce the issue. Maybe it's because I'm not using home-manager and it might have to do something with that. But I just tried this:

… and it works fine. I opened the app multiple times and closed the current project to see if it was not just the fluke and it somehow remembered the previously opened project.

Both variants work for me: You can either link directly to Contents folder in the Nix store. Or link to the Contents folder in /Applications/Nix Apps.

Since according to the Apple documentation, here, the Contents folder is the only subfolder of any app bundle on macOS and at least on my system there is no app with anything apart from Contents, this just might work.

Am I missing something? 🤷

[hraban]

Very interesting! I hadn't thought of it at all I had just defaulted to using osacompile to make a trampoline. I'll give this a spin tonight, if it works that's a big improvement. Thanks for flagging up!

[hraban]

Finally got round to doing this and it works great on my machine! Very interesting idea, I can't believe it. Surely we're missing something?

Can you please give this a try with the link-contents branch, so input github:hraban/mac-app-util/link-contents?

[joneshf]

Just to add two more datapoints to this idea:

• vscode-with-extensions has been doing this symlink thing for more than 3 years.
  • It looks like it was intended to keep the closure size down: vscode: Fix vscode-with-extensions with #70486 NixOS/nixpkgs#71264 (comment), not particularly to solve a problem similar to what mac-app-util is concerned about.
  • That said, it's been like this for so long, I have to assume that means that it works.
• I've been trying this out with a derivation for Godot with .NET support and it also seems to work.
  • The important part of the derivation is here: https://github.com/joneshf/home-manager/blob/bf5d582162856ae9bf4e9c5245008595d726ed42/packages/godot-mono/darwin.nix#L34-L54.
  • It needs DOTNET_ROOT and the PATH set so that it can even start properly. And trying to do that on a GUI macOS Application Bundle is far harder than it seems like it should be.
  • What I'm doing is symlinking everything, then using makeBinaryWrapper to set the DOTNET_ROOT and PATH and point it at the original binary.
  • I've only been using it for a few days, but it seems to work both from Finder/Spotlight and opening from a terminal.

So yeah, this change gets my vote! (for whatever that's worth 😅)

[hraban]

Those are similar but distinct because they get into the nitty gritty of symlinking individual elements of the bundle. This is a symlink of the contents directory wholesale. I have to go back and read the entire original nix-darwin / home-manager threads on this issue because I seem to recall there being some kind of edge case problem with this... or maybe that was just with the symlinking of the .app bundle itself?

[joneshf]

Ah. Sorry, got too excited about the idea 😄.

Well I'm trying out the branch, and it's working over here with a handful of different Applications!

Just as a heads up, there's an extra / on the symlinks (like Applications/Something.app//Contents:

$ readlink ~/Applications/Home\ Manager\ Trampolines/*/Contents
/nix/store/v9b8d6w1lz8fzj21gqp00rk7258jr8zs-godot-4.4.1-stable/Applications/Godot.app//Contents
/nix/store/8x902a6nz5vnsykwxxwmrrpdx1qicvw5-godot-mono-4.4.1-stable/Applications/Godot_mono.app//Contents
/nix/store/03fvy1ip7hcgv6ljp45c9c461dz8pm3v-moonlight-qt-6.1.0/Applications/Moonlight.app//Contents
/nix/store/pxc8jqipmgdj6b626s0478s6n6hymnzl-openscad-2021.01/Applications/OpenSCAD.app//Contents
/nix/store/i837jyixzvbyjdmllrshg807v9nwwgg2-rectangle-0.86/Applications/Rectangle.app//Contents
/nix/store/ciwkyc4h1k0ixrrs79djh0n457kvsvqk-spotify-1.2.40.599.g606b7f29/Applications/Spotify.app//Contents
/nix/store/z8277czhp648jywa3k3slnxgr6p78cjs-utm-4.5.4/Applications/UTM.app//Contents
/nix/store/9jlmqb8snvkzam4iag3wjv4q3z38n0rq-wireshark-qt-4.4.4/Applications/Wireshark.app//Contents
/nix/store/5708s8y8xri2040mkjgv032p4nbwg8nb-zotero-7.0.15/Applications/Zotero.app//Contents

It doesn't seem to affect Spotlight finding the Applications or anything running, though.

[hraban]

thanks good catch

[christian-burger]

Just tested your link-contents branch on my end. Works perfectly. Though, I'm only using it for Spotlight integration. So, I cannot judge for the other use cases …

[hraban]

Spotlight integration and dock pinning are the two only explicit features of this module so that's 50% of it covered :) the rest (preserving icons etc) is bonus but best effort. If this works for dock pinning as well I'm going to merge it in (after double checking the other thread to see if there's a prior attempt at solving the problem this way)

[christian-burger]

I tried putting Visual Studio Code in the dock. Updated it to the nixpkgs-unstable version. Works. Even when keeping it open, while updating: No problems. Just close the running instance after updating and immediately start it (from the same symbol just running moments ago) again via the Dock; and voilà the updated version has started. So even this is transparent to the user.

[christian-burger]

Before I was creating this ticket I was superficially looking for any other who has tried linking the Contents folder. In case there is some obvious hurdle, I did not consider. I had no luck finding any reference in my quick search. Obviously you are far more involved and know the various threads where ideas were discussed …

But I just did another search just to be thorough and found PR 1396 at nix-darwin (created 3 weeks ago) — and I'm not totally happy with that. They considering to copy the whole app from the /nix/store … sure space is plenty on modern systems, but still no reason to waste it … 🤷 I did not link the PR because that would make a reference at their end. And since this here is your project, I would want to give you the chance to approach them.

I would appreciate it, if they are not doubling the space requirements for every app … this seems like very very unnecessary, 😅considering the solution we have worked out here …

[hraban]

Copying the entire .app directory was discussed at length in nix-community/home-manager#1341 and breaks down for apps built from source in nixpkgs in myriad ways. They're often not built to withstand copying. Maybe they found a solution, I'll have another look. If it works then that'd be great!

[joneshf]

That is a good point though. If making an Application Bundle directory and only symlinking the Contents directory ticks all the boxes, maybe home-manager/nix-darwin could do that instead of it needing to be done in mac-app-util?