For example, if the regular settings file is similar to:

[EnvironmentVariables]
FOO=bar

.. and the additonal settings file is similar to:

[EnvironmentVariables]
FOO=bie

Assuming the additional settings is passed to the launcher using the --launcher-additional-settings command line option, the environment variable FOO will be set to bie.

This is not always the desired behavior. Indeed, sometimes it makes sens for the additional settings to update the environment variable instead of overwriting it.

To allow environment variable already set by the launcher to be considered, the following mechanism could be implemented. Considering this additional settings file:

FOO=<env:FOO>:bie

... the corresponding environment variable set by the launcher will be bar:bie.

Similarly, if the additional settings file is:

FOO=bie:<env:FOO>

... the corresponding environment variable set by the launcher will be bie:bar.

Related to #17

When packaging application on MacOSX (as bundle), no launcher is needed since all the libraries are "fixed up" so that they can be referenced relatively to the location of the executable.

When building a cross platform application, it resumes the path and other environment variables are setup in multiple location:

• Launcher settings for application distributed on windows/linux
• main.cpp or Q(Core)Application derived class.

On MacOSX, by creating a launcher library that could be linked (statically) against our application, we could ensure that all paths/environment variables are set a common location for all platform.

Thanks @finetjul for suggesting this approach.

When running AppLauncher with no ini settings, the duration of the splashscreen is too short to really see it.
It should be increased for at least a couple hundreds of milliseconds (800 msecs) by default.

See http://www.na-mic.org/Bug/view.php?id=2767

If GIT_EXECUTABLE is not found, package name will be named:

CTKAppLauncher-0.1.12-linux-amd64.tar.gz

This is misleading because a release package for version 0.1.12 would also have the same name.

See http://na-mic.org/Mantis/view.php?id=1455

From @finetjul:

README in repository is empty, it is not obvious for a new developer to know where 
to find documentation of the launcher. 
Maybe the contents of the following page could be in README:
http://www.commontk.org/index.php/Tools:_Application_launcher

Thanks to @fedorov for reporting the issue.

This issue is related to #6

While running ./Slicer --launch xcalc works, trying to run an executable that is located in the path specified in the settings fails.

See http://www.na-mic.org/Bug/view.php?id=2376

A general settings named consoleOutputArguments

Having the test numbered from AppLauncherTest1 to AppLauncherTest8 make understanding of the dashboard more difficult. Test should be name as function of what they are testing.

See associated issue #21

Community contributions are welcome :-)

See http://my.cdash.org/viewBuildError.php?type=1&buildid=368016

ld: warning: QList<QString>::detach_helper_grow(int, int)has different visibility (default) in bin/libCTKAppLauncherBase.a(ctkAppLauncher.cpp.o) and (hidden) in /path/to/libQtCore.a(qstring.o)
ld: warning: QList<QString>::removeAll(QString const&)has different visibility (hidden) in /path/to/libQtCore.a(qcoreapplication.o) and (default) in bin/libCTKAppLauncherBase.a(ctkAppLauncher.cpp.o)
ld: warning: QList<QString>::~QList() has different visibility (hidden) in /path/to/libQtCore.a(qdir.o) and (default) in bin/libCTKAppLauncherBase.a(ctkAppLauncher.cpp.o)
ld: warning: QList<QString>::append(QString const&)has different visibility (default) in bin/libCTKAppLauncherBase.a(ctkAppArguments.cpp.o) and (hidden) in /path/to/libQtCore.a(qstring.o)

See https://bugreports.qt-project.org/browse/QTBUG-3995 for a possible solution

When the build system was originally setup, there was no standard location to upload packages. It would be now a good time to update it to upload on http://packages.kitware.com

Step to reproduce

1. Configure and build project
2. Delete launcher
3. Build

=> The launcher won't be available

Workaround

• Delete LauncherSettings* files.

Solution:

• Add an extra dependency to the custom_command configure the launcher

Following my first investigation, it resumes that developing a small tool (ie CTKResEdit) that could be used to change the icon embedded in a window pre-build binary.

It could also be worth doing more research to confirm that can't be done using the tool provided with Visual Studio.

In any case, one (or more) CMake function(s) will have to be developed and should be available after generating the package on windows.

See:

• http://na-mic.org/Mantis/view.php?id=1156
• https://github.com/jcfr/ResEdit
• http://social.msdn.microsoft.com/forums/en-US/vclanguage/thread/e624d438-f84b-4d76-a323-cd86b72e0a73
• http://msdn.microsoft.com/en-us/library/ms648008.aspx

./Slicer --help displays the help text twice.

See part2 reported in #8

Get sources, in build dir, configure and build AppLauncher
from a console, type: ./bin/AppLauncher
errors are output because no --launch is passed -> ok
Then a natural step is to do: ./bin/AppLauncher --help
-> doesn't output the available launcher options or more details on how to use it

After reading documentation, it appears that it should be --launcher-help. Maybe if no application to launch is given --help could print what --launcher-help would

For example:

$ bin/CTKAppLauncher --launcher-verbose --launch /bin/ls -a -l 
info: LauncherDir [/home/jchris/Projects/CTKAppLauncher-Debug/bin]
info: LauncherName [CTKAppLauncher]
[...]
info: ApplicationToLaunch [/bin/ls]
info: ApplicationToLaunchArguments [-a -l]
info: <APPLAUNCHER_DIR> -> [/home/jchris/Projects/CTKAppLauncher-Debug/bin]
info: Starting [/bin/ls]
info: argument [-a]
info: argument [-l]
info: argument [-a]
info: argument [-l]
info: launcher-timeout (ms) [-1000]
[...]

When using the launcher associated with ApplicationFoo while testing if some plugin can be loaded within ApplicationFoo, it could be useful to "temporary" associate settings without having to update the main settings.

The concept of additional-settings could be introduced.

Part1 - See #9

The command line argument --launcher-additional-settings could be used to associate one (or more - see part3) setting file(s) that will be merge at run time with the settings read from the "main" settings file.

Part 2 - See #10

The parameter additional-settings could eventually be a parameter read from the "main" settings file.

If both 'additional-settings' is set within the main settings and the command line parameter '--launcher-additional-settings' are passed, all the settings will be "merged" together. This behaviour could be avoided by passing the command line --ignore-additional-settings.

Part3 - See #11

Support mutliple settings file passed using --launcher-additional-settings

See part1 reported in #8

Test case:

Your test case does not cause the problem for me, however I can reliably recreate this with:

$ mkdir /path/to/test_bin
$ export PATH=/path/to/test_bin:$PATH
$ ln -s /path/to/Slicer-4.2.2-1-linux-amd64/Slicer /path/to/test_bin/SlicerTest
$ SlicerTest
error: Failed to obtain launcher executable name !

See http://na-mic.org/Bug/view.php?id=3075

See part3 reported in #8

On windows, the --launcher-timeout test is currently disabled . Indeed, in that case, the function QProcess::terminate() sends a WM_CLOSE event and our App4Test doesn't handle it.

It may be possible to use SetConsoleCtrlHandler

Regression from #113 led to crashes as described in Slicer/Slicer#5078.

See http://my.cdash.org/testDetails.php?test=9468287&build=368007`

Consider Slicer, which has e.g. an extra application argument --gdb. If I want to read GDB's CLI help, I would run /path/to/Slicer --gdb --help. This works okay, but, the launcher also reads the --help option and shows the help for Slicer as well.

Also, the launcher does not recognize -- to ignore following options.

For extra applications, the launcher should ignore any arguments following the extra application argument, at least when preceded by --.

The splash screen is not transparent even if the provided image is transparent.
I wonder if it is because the Qt::SplashScreen window flag is missing.

As the launcher is a Qt application, it "eats" the "-style=motif" command arguments and doesn't propagate them to the launched application.

Calling
./Slicer -style=motif
doesn't pass "-style=motif" to SlicerQT-real

Here is a list of arguments that are "eaten": http://doc.qt.nokia.com/latest/qapplication.html#QApplication

See http://www.na-mic.org/Bug/view.php?id=2356

As suggested by @lassoan , a robust way of keeping track of the original environment using the following approach:

We could save the original values of the modified/added/removed environment variables in other environment variables?

For example:

PATH=...new path with additional values...
PYTHONPATH=...modified by this applauncher...
LD_LIBRARY_PATH=...modified by this applauncher...
APPLAUNCHER_LEVEL=0
APPLAUNCHER_0_PATH=...original path before the applauncher modified it...
APPLAUNCHER_0_PYTHONPATH=...original path before the applauncher modified it...
APPLAUNCHER_0_SOME_DELETED_VAR=...stores value of a deleted env var DELETED_VAR...
APPLAUNCHER_0_SOME_ADDED_VAR=

To restore previous level's environment, you would just need to go through all the APPLAUNCHER__* variables and set them. Set to empty value deletes an env var, so this can be used for deleting added env vars as well.

APPLAUNCHER_LEVEL can be used for cleanly managing multiple levels off app launching (applauncher library running an application that uses applauncher). For example:

PATH=...new path with additional values...
PYTHONPATH=...modified by this applauncher...
LD_LIBRARY_PATH=...modified by this applauncher...
APPLAUNCHER_LEVEL=1
APPLAUNCHER_0_PATH=...original path before the applauncher modified it...
APPLAUNCHER_0_SOME_DELETED_VAR=...stores value of a deleted env var DELETED_VAR...
APPLAUNCHER_0_SOME_ADDED_VAR=
APPLAUNCHER_1_PATH=...original path before the applauncher modified it...
APPLAUNCHER_1_SOME_DELETED_VAR=...stores value of a deleted env var DELETED_VAR..
APPLAUNCHER_1_SOME_MORE_DELETED_VAR=...stores value of a deleted env var SOME_MORE_DELETED_VAR...
APPLAUNCHER_1_SOME_ADDED_VAR=
APPLAUNCHER_1_SOME_MORE_ADDED_VAR=

If a launcher did not modify any env vars then it would just increment APPLAUNCHER_LEVEL.

AppLauncher library could be responsible for creating environments from previous levels.

As far as I understand, it should allow to pass further arguments only to the launched binary, but:

</details>

A test should also probably be added.

Thanks @vovythevov for reporting the issue.

Related to #6

On the different platform, this option could respectively generate a

• BAT file (windows)
• Shell script (Mac OSX and Linux)

Later on an option --exec-wrapper-script-format allowing to override the auto-selected wrapper script format could be added.

The generated wrapper script could be used to set the environment without having to use the launcher. It could for example be set as a exec-wrapper in gdb

When setting environment variable in either

(1) the regular

or

(2) the additional settings file,

the special variable <env:VARNAME> should evaluate to either

(1) the associated system environment variable if one is set

or

(2) first the associated variable set in the regular settings if any and then the associated system environment variable if one is set.

Related to #16

See KitwareMedical/SlicerVirtualReality#39 (comment)

Hi developers,

I forked and patched and pushed... so here is the branch I created for ctklauncher to be able to compile it on OpenIndiana (~Solaris) with Solaris's own compilers (unpatched Studio 12.3's cc/CC)
Also changed one .h file that gave warnings about superfluous ";" at the end of four lines - it's only a cosmetic change; cc/CC is more picky than gcc.
Here it is:
https://github.com/acetylsalicyl/AppLauncher/tree/solaris

Could you please consider to merge these changes?
Thanks a lot,
Attila Nagy

When using the option --launcher-show-set-environment-commands on windows within Git bash, the list of path are separated using ; whereas : is expected.

For example, in a posix shell on either windows or unix, the following is expected:

PATH=/path/thing1:/path/thing2
PYTHONPATH=/path/module1:/path/module2

but on windows, in a posix shell .. the following is returned:

PATH=/path/thing1;/path/thing2
PYTHONPATH=/path/module1;/path/module2

The issue is here in function generateEnvironmentScript.

An internal function named pathSep(bool posix) could be added.

Reported by @vovythevov

Path should starts with \c\Program Files\ otherwise they will be ignored.

Reported by @vovythevov

Related to #53

Ideally, if it applies, two executables could be created and packaged:

• CTKAppLauncher : With console I/O
• CTKAppLauncherW: Without console I/O

The W means that the executable has been built with the /SUBSYSTEM:WINDOWS. See http://msdn.microsoft.com/en-us/library/fcc1zstk%28v=vs.90%29.aspx

Check that DESTINATION_DIR has been specified.

See KitwareMedical/SlicerVirtualReality#39 (comment)

.. or set the default value to an empty string.

This will ensure the AdditionalUser settings are loaded by Slicer and will fix loading of VMTK extension.

What works

It's currently possible to disable the splash screen by using the command line option --launcher-no-splash

The problem

On the other hand, the use case where the splash screen needs to be disabled from within the settings doesn't seem to work. Indeed, adding the option --launcher-no-splash as illustrated below fails since the option is passed to the called program.

[Application]
path=/usr/bin/python
arguments=--launcher-no-splash

Possible workaround:

• Add a setting entry additionalLauncherNoSplashArguments to the General group containing the list of command line option that shouldn't be associated with a splash screen.
• Associate a 1x1 pixel transparent png as a splash screen

Two following options could be introduced:
CTKAppLauncher_VERSION_IS_RELEASE and CTKAppLauncher_VERSION_RC

• If CTKAppLauncher_VERSION_IS_RELEASE is set to 0:
  • the git SHA1 will be appended to the current app launcher version.
• If CTKAppLauncher_VERSION_IS_RELEASE is set to 1:
  • Nothing will be appended to the version string. The version string would have the following form: X.Y.Z
  • If CTKAppLauncher_VERSION_RC is defined and set to an integer: -rc{CTKAppLauncher_VERSION_RC} will b e appended to the version string.