OSX Application Icons

[sp1ritCS]

Hi, I hope this is the right place to ask, since I have no experience with Homebrew nor OSX.

I'm currently trying to build NoteKit on OSX because a user asked for a OSX port (blackhole89/notekit#90) . I've got NoteKit running in a OSX VM with software rendering, and the experience (after figuring out OSX's wierd keyboard- shortcuts & combinations) porting it was a lot easier than to Windows.

However I face an issue now in-that, what ever equivalent of freedesktop's deskop entry OSX uses is. Because NoteKit does not have an icon in the dock (see screenshot in linked issue) nor does it have a proper title in the top left corner (it just uses the name of the binary). Additionally if I pin NoteKit to the dock, close and reopen it, a terminal window pops, printing out the stdout it received from notekit.

If anyone has experience building GTK applications with Homebrew and knows how to add a desktop entry or equivalent, I'd greatly appreciate if you could tell me how.

---

Additionally I'd love to hear some feedback on my "Formula"s for NoteKit and cLaTeXMath (both are in the linked issue) since it's my first time writing one. I know they wouldn't pass the Formula requirement's due to using a git source without commit id and having an uncommented patch (required to build NoteKit on llvm clang).

[sp1ritCS]

bump

[SMillerDev]

No need to bump, clearly nobody has an answer for you. And some maintainers have notifications enabled.

[tlk]

If anyone has experience building GTK applications with Homebrew and knows how to add a desktop entry or equivalent, I'd greatly appreciate if you could tell me how.

I don't have any experience with that but maybe you can come up with a solution based on https://gist.github.com/mathiasbynens/674099 or some of the links in the comments. On macOS a GUI application consists of a particular folder structure with an icon file, libraries and an executable file inside the folder structure. When the macOS user interface recognises a folder structure like this, it will render the icon and hide the underlying folder structure (but you can right-click any .app and inspect it via "Show Package Contents").

Additionally I'd love to hear some feedback on my "Formula"s for NoteKit and cLaTeXMath (both are in the linked issue) since it's my first time writing one. I know they wouldn't pass the Formula requirement's due to using a git source without commit id and having an uncommented patch (required to build NoteKit on llvm clang).

You may be interested in https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap as this will allow you to host formulas yourself.

TLDR; If you publish a formula file to https://github.com/USERNAME/homebrew-XYZ/blob/master/Formula/myfancyapp.rb it can be installed by this command: brew install USERNAME/XYZ/myfancyapp.

[sp1ritCS]

@gromgit , yeah I know. Alls those formulae extract the binary from the app bundle (the make process of those applications build them) and puts them into bin, that they can be launched from a shell.

However our meson file automatically installs the binary into bin, and then I just want to copy the notekit binary from bin to the empty app bundle skeleton.

As I've said

Guess I now have inverted the thing with write_exec_script.

:D

[gromgit]

Well, since your install process is somewhat bass-ackwards from typical app-related installs, "idiomatic" just got tossed out the window. 😀

[tlk]

Thanks, that helped me a lot. I now have a NoteKit Application that seems to work without issues.

That's great!

However, it seems to be discouraged in "Acceptable Formule" to build an .app bundle and I assume there is reason for it. Instead upstream is supposed to build an .app that can be distributed through homebrew/cask.

I don't know if there is another reason than that Homebrew is currently missing this functionality.

Additionally, we don't want to publish notekit as a bundle, because that would put us at fault if some dep has a security issue, that's why we'd rather let homebrew handle dependencies.

That makes sense, but I believe this approach is different from how the vast majority of macOS GUI applications are distributed today.

On my systems /usr/local/Homebrew is almost 800Mb so it may be a bit much to ask users to install Homebrew just to be able to install your GUI app.

If you provide a .dmg with myfancyapp.app in it, most macOS users will know how to copy this into /Applications.

I wrote a Github workflow file (for a Swift project) that automatically builds a .app bundle and publishes it on Github in a .dmg-file when you push a release tag. Maybe you can find inspiration in that.

Note that this approach means that the .app will not be signed and notarized as required by macOS.

For those users who already have Homebrew, you can provide a simple Homebrew cask which is just another .rb file pointing to the latest .dmg-file, its hash-value and a version number. (fx https://github.com/USERNAME/homebrew-XYZ/blob/master/Cask/myfancyapp.rb)

Homebrew users can then work around the missing app signing and notarizing by installing the app with brew install --no-quarantine --cask USERNAME/XYZ/myfancyapp.

For non-homebrew users you will have to refer to https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac, unless of course you go ahead and setup proper app signing + notarization.

I have only tested this briefly, so I may have misunderstood a thing or two here...

🌵🐛

Regarding dependencies and security issues, I believe the prevalent practice for macOS GUI applications is that upstream makes new releases whenever a dependency needs to be updated. Github provides some tools that may help with this (see https://docs.github.com/en/code-security/supply-chain-security/about-dependabot-version-updates). This way you may receive automatic pull-requests when dependencies need to be upgraded, and the changes can go through the usual CI pipeline before you publish a new release.

[sp1ritCS]

I wrote a Github workflow file (for a Swift project) that automatically builds a .app bundle and publishes it on Github in a .dmg-file when you push a release tag. Maybe you can find inspiration in that.

Note that this approach means that the .app will not be signed and notarized as required by macOS.

If I have understood this correctly, I'd be required to set up Apple's XCode IDE for that. As I only have a QEMU/KVM VM with Software Rendering, I assume the experience would be quite bad. I also have no Idea from where I'd get the dependencies, as there a quite a lot of them (not necessarily directly from NoteKit, but gtk/mm just has a lot of them)

I believe the prevalent practice for macOS GUI applications is that upstream makes new releases whenever a dependency needs to be updated. Github provides some tools that may help with this (see https://docs.github.com/en/code-security/supply-chain-security/about-dependabot-version-updates)

I know about it. However as NoteKit is written in C++ and all libraries it links against are available as Homebrew formulae. (Which are not supported by GitHub, because there is no package.json/Cargo.toml/requirements.txt equivalent for it :))

If you provide a .dmg with myfancyapp.app in it, most macOS users will know how to copy this into /Applications.

Very true, however NoteKit is still just a (realtime) Markdown editor, that is mostly used by developers (And despite the prejudices against Apple users 😆 , I assume they are capable of using a terminal).

On my systems /usr/local/Homebrew is almost 800Mb so it may be a bit much to ask users to install Homebrew just to be able to install your GUI app.

You mean after installation of homebrew? Because I taught there shouldn't be much of a filesize difference between the statically linked bundle, and a Homebrew setup with just NoteKit installed. Or does it cache source code and/or intermediate compiler output?

[tlk]

I am not sure you need to set up XCode IDE for this, but it sure would be a lot more work for you than your current solution.

Regarding the disk consumption, it is Homebrew formulas and source code that take up all that space. It was not like this until recently, but since Homebrew/brew#9383 Homebrew will download and store a copy of the entire history of the homebrew repositories plus a checkout, and that adds up:

$ du -sh /usr/local/Homebrew/**/.git | head -n 4
 75M	/usr/local/Homebrew/.git
2.4M	/usr/local/Homebrew/Library/Taps/homebrew/homebrew-bundle/.git
322M	/usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask/.git
239M	/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/.git