Check if utility is already running before launching?

[Pidgeot]

This may be to much of a PITA to do cross-platform, but I'll pass on the request anyway - I've been asked a couple of times.

The windows launcher was fairly recently updated to avoid launching a program that was already running - if you try, it pops up a confirm/cancel prompt that defaults to 'no' after twenty seconds. Implementing this in the PyLNP would be appreciated.

[Issue created by PeridexisErrant: 2014-09-18]
[Last updated on bitbucket: 2014-09-19]

[Comment created by Pidgeot: 2014-09-19]
If a program is running, a window like this will now pop up:

It currently shows the full path to make sure the user knows what's being run; I may still choose to cut off most of that (but I haven't decided how much).

The window will automatically close after 20 seconds; only then will it try to launch any further applications.

[Comment created by Pidgeot: 2014-09-19]
Prompt to re-run already running programs (fixes #23)

→ <<cset 811af0685e3d>>

[Comment created by Pidgeot: 2014-09-19]
I've managed to implement the simple solution (cset db95f9b0ca75), and am able to handle point 2 by parsing the output of the ps command on those platforms. That's good enough for me.

Currently it just flat out refuses to run anything it knows is running; there's no mechanism for forcing a new instance. I'll be looking at that later today.

[Comment created by PeridexisErrant: 2014-09-18]
1 is definitely fine, and 2 is still better for utilities and Windows than the current situation.

[Comment created by Pidgeot: 2014-09-18]
This one is slightly problematic because AFAICT Python doesn't have a built-in way of detecting all running processes.

A simple solution would be to simply check if the launcher itself launched the program previously, and if so, whether that program is still running - because that's something I can do. However, that does mean two things:

1. If the launcher is closed and re-opened, it will lose this information (so any utility started manually or in a previous session won't be detected)
2. On Linux and OS X, I don't think it will work for DF itself when DFHack is in use, since those use a secondary application to start the program, and I think they appear to have terminated as soon as the new process is started.

1 is probably acceptable, but 2 probably isn't.

I'll have to do some testing to see if that one really is a problem, but if it is, I'll need to write platform-specific code (I have a decent idea about what Linux and OS X would need; I'm less sure about Windows).