Allow multiple instances on macOS

[MWin123]

Currently, it's not possible to open multiple instances of KafkaEsque on macOS without using the following workaround with open.

open The options are as follows: -n Open a new instance of the application(s) even if one is already running.

You can run open -n /Applications/KafkaEsque.app via the terminal to open another KafkaEsque instance.

On Windows you can just open KafkaEsque multiple times, and it works as expected. On macOS it just shows the already opened KafkaEsque instance instead of opening a new one.

I already looked into the badass-runtime plugin that is used to create the binaries, but I couldn't find anything.

Help from other macOS users would be greatly appreciated. Unfortunately @patschuh can't test it himself on Windows.

[pkleindl]

KafkaEsqueLauncher.zip My most comfortable solution was to include the command mentioned above in an "application" and add it to my apps folder. Every double-click starts a new instance of KafkaEsque. I tried to include the command inside KafkaEsque itself, but it didn't work.

[barbeer]

That's not really possible, it's by design in macOS. You can open new instance from terminal (open -na) or from ObjC/Swift code (https://developer.apple.com/documentation/appkit/nsworkspace/3172700-openapplication - that's how native apps implement menus like "new instance" etc.), but you can't change default OS behavior for an app.

What you can do, is to "wrap" it with Launcher, similar to what @pkleindl proposed, but with a trick:

Here all but the main executable (Info.plist, PkgInfo, Resources) are copied from the original app, and MacOS contains current KafkaEsque.app (highlighted on screenshot) + KafkaEsque executable shell script with this:

#!/bin/sh  
open -n "$(dirname -- "$0")/KafkaEsque.app"

Here's the wrapper, to make it work you should put real KafkaEsque.app inside, into Contents/MacOS wrapper.zip

[MWin123]

@pkleindl @barbeer is there a way to include that in the current builds?

Unfortunately the Contents/MacOS directory exists only after the build is done inside the dmg file, and not in the repo itself because it's created programmatically.

For the build Gradle is using jpackage via the badass-runtime plugin to create those files, so they are not part of the repo.

Maybe you could do it somehow with CI after everything is built but I'm not sure if that would break the already flaky self signed signature of the dmg file which also has to work in the custom Homebrew repo (https://github.com/patschuh) for an easy install (brew install patschuh/esque/kafkaesque) & auto upgrades (brew upgrade).

I'd prefer a solution with Gradle or jpackage instead of manually editing built files. But if that's the only solution, and it doesn't break the self signature or Homebreak, feel free to submit a PR.