New launcher creates separate app, breaking Mac OS X conventions

That will be fixed, in the console is written

---- YOU CAN CLOSE THIS LAUNCHER IF THE GAME STARTED OK ----
---- YOU CAN CLOSE THIS LAUNCHER IF THE GAME STARTED OK ----
---- YOU CAN CLOSE THIS LAUNCHER IF THE GAME STARTED OK ----
---- (We'll do this automatically later ;D) ----

There is no way around 'opening a second window', we have to start a secondary VM to give you guys control on its settings. Also there is no way to gain control from the outside and control 'activity' from the launcher that didn't start the game.

The idea is to keep the launcher running while the game is running and we'll have to research if its possible to give some form of 'focus' control that way. Also, you should be able to start multiple minecrafts, however the normal restrictions on OSX still apply in regards to starting the launcher twice.

@Kumasasa This is not about closing the launcher. All three of the problems I describe will occur even if it auto-closes.

@Grum Starting multiple Minecrafts is a bug, not a feature: the expected behavior on Mac OS X is that opening the same icon twice brings the app to the front, not opens a second copy. A user who wants multiple copies can simply duplicate the application file to give it a second identity-for-launching-purposes.

Interesting point that you have uses for creating a separate JVM. I have an idea about how it might still be possible to solve this problem — let me get back to you after an experiment.

Grum is one of the Minecraft developers. If he says that starting multiple instances of Minecraft is a feature, then it's a feature, not a bug.

How do other games with launchers (a large number of MMOs, these days) function on a Mac?

You copy the .app folder so you can start them twice ....

Sorry, I said I'd get back to this but I didn't get around to writing an actual test app. Anyway, a lot of programs that self-update will internally quit and relaunch themselves, and I was thinking you could do something like that here:

Replace the launcher bundle's regular executable (JavaApplicationStub) with a small program (it can be a shell script, even), which I will call the “bootstrap program”, to allow the following behavior.

1. If opened normally, the bootstrap program will just exec the JavaApplicationStub to let the launcher run.

2. When the user clicks “Play”, the launcher should start another process which is not a GUI process, and then exit. The MC launcher icon will thus go away or return to “not running” state.

3. This temporary process should then run the bootstrap program with special command line arguments (or environment variables) which tell it to exec the JVM for Minecraft itself. This will get the same dock icon as the launcher, because it is the launcher bundle's executable.

Thus, it looks to the system like the single Minecraft app quits and relaunches itself, and there will only be one dock icon and everything will work Properly™ and be awesome.

Note — I'm pretty sure this will work (I've played with running GUI processes directly, and Java GUI programs in .app bundles, quite a bit) but I haven't tried this particular scheme. If it turns out that this doesn't work, then I suggest looking at applications with self-updating functionality, as they have to do basically the same thing (minus the switch-to-a-different-code-path part).

As a Mac user, I don't think this breaks conventions.

If Grum thinks this issue is something to be resolved, he can reopen it, however from my point of view this is a feature request, because the launcher is working as intended, and isn't "bugged."