Kepler

Me and Jianwu have further investigated this bug, and have determined that the issue arises simply because the environment when you double-click Kepler.app is very different than when you invoke Kepler from the command-line. The issues with this bug go away if you open Kepler.app from the command line with the "open" command (since that would give you the same environment as if you open Kepler with kepler.sh from the command-line).

The only possible solution I can think of is for Kepler.app to invoke some sort of script which then opens a terminal session that then invokes Kepler. But it is uncertain whether this solution would work or whether it would be worth doing. In any case, if this is worth doing, it should be done in a future release.

I am re-targeting this bug for 2.3.0 so we can discuss it and decide how we want to proceed later.

another problem for kepler.app is that it may choose a different JVM different with terminal. One partner has both java 1.6 64bit and 32bit installed in his mac and 64bit is the first choice. When he doubles click kepler.app to start, kepler actually pick 32bit JVM. He has to go to terminal to start kepler with the correct JVM.

It should be better if we can show JVM in starting flash figure and configure it from Kepler menu.

One way work around is to set environment variables at ~/.MacOSX/environment.plist file. It works for Kepler 2.3. But if the file is edited, the user has to log out and log in to make it effective. Another drawback is that the file will be applicable to all *.app applications, not just kepler.app.

I tried to edit /Applications/Kepler-2.3/Kepler.app/Contents/Info.plist to add environment variables there. Ideally, it should work and is only applicable for kepler.app. But Kepler cannot get them via getenv function. Not sure why.

More information can be found at http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html.

It's not a critical bug for 2.4, so bump to 2.5.

I don't think this is really a Kepler bug.

The problem is that environment variables are poorly supported under Mac OS X.

To set environment variables for applications that are run by double clicking
on a icon, one must edit ~/.MacOSX/environment.plist
There is a property list editor, but it might only be available to
users who have installed XCode.
See
https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html

One possible enhancement would be to provide a properties file that can
be edited.
In Ptolemy II, ./configure reads lib/ptII.properties.in and creates
lib/ptII.properties

This file is read in by StringUtilities.mergePropertiesFile(). Properties listed in this file do not override preexisting properties.

The way to control which JVM is invoked is by using the Java Preferences app
under Utilities. Adding this sort of functionality to Kepler will increase
support costs.

Mac OS X is moving away from being a useful OS for developers and becoming
a locked-down garden for consumers. Fighting this is an uphill battle.

Our best bet it to have a good FAQ that points to recent Apple docs about
how to do these things (set environment variables, choose a JVM).

I'm marking this as an enhancement because the system works as it should.
I'm lowering the priority slightly as well.
Feel free to change these.

Jianwu,

One way work around is to set environment variables at

~/.MacOSX/environment.plist file. It works for Kepler 2.3.

...
I tried to edit /Applications/Kepler-2.3/Kepler.app/Contents/Info.plist to add

environment variables there. Ideally, it should work and is only applicable for
kepler.app. But Kepler cannot get them via getenv function. Not sure why.

Did you add the environment variables under the LSEnvironment key in Kepler's Info.plist? ~/.MacOSX/environment.plist assumes LSEnvironment, but you have to explicitly declare it for an application's Info.plist.

https://developer.apple.com/library/mac/#documentation/General/Reference/InfoPlistKeyReference/Articles/LaunchServicesKeys.html

If this works in ~/.MacOSX/environment.plist:

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>ENV_VAR</key>
<string>value</string>
<key>ENV_VAR2</key>
<string>value2</string>
</dict>
</plist>

then it should probably look like this in Kepler's Info.plist:

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>

... other keys

<key>LSEnvironment</key>
    <dict>
      <key>ENV_VAR</key>
      <string>value</string>
      <key>ENV_VAR2</key>
      <string>value2</string>
    </dict>
  </dict>
</plist>

Thanks for the info from Christopher and Hogan.

I agree it is not Kepler bug but Mac OS settings. A FAQ should be good enough.

Hogan, my tests are what exact what you said (additional LSEnvironment for Info.plist in Kepler.app). But it doesn't work for me.

Original Bugzilla ID was 5333