[josm-dev] JOSM and OSX - Big changes in the pipeline

Henry Loenwind henry at loenwind.info
Sun Sep 21 22:56:39 BST 2008


Dirk Stöcker wrote:
> On Sun, 21 Sep 2008, Henry Loenwind wrote:
> 
>> * Menu bar will be where it belongs (but: won't work with Metal and
>> CDE/motif LookAndFeels).
> 
> Won't work? This specific feature won't work or the whole look and feel 
> won't work? As I cannot test and probably Frederik also cannot - Is it 
> save to apply this, i.e. without side effects for others?

"Won't work" as in "there still will be 2 menu bars as there are now". 
(The OS can only combine the 2 menu bars if it knows Swing's menu bar as 
menu bar. Seems the other LAFs paint it as graphics, and the "native" 
LAF uses the native controls.)

The patch collection is safe for all other platforms (I put if()s around 
all new code, you might want to check that).

It should be safe on OS X, for multiple reasons:

(1) I put all dangerous code into try{} blocks. The global 
"withOSXIntegration" flag is set to TRUE as the last line of that try{} 
block. (see Main.setupOSX())

(2) I'm doing nothing fancy. I register our "main" object with the OS to 
receive callbacks using a standard Java interface. Also in a try{} 
block, so no chance of crashing JOSM here. Worst case of malfunctioning 
would be that Quit, About and Preferences would stop working. (see 
Main.invoke())

BTW: Is there any case when System.getProperty("os.name") would return 
null? Would give a NPE in the first line of Main.setupOSX(). Better move 
the if() into the try{} before submitting the change.

> Probably together with #1471?

I've had a look at that patch, it looks fine except for two details:

(1) The plist file contains static version numbers. They should be 
filled with the real data when building instead.

(2) I'm not sure if the "-Dsun.java2d.opengl=True" parameter really is 
wise. On my system, JOSM becomes somewhyt sluggish when compared to 
native drawing. I think the OS's native drawing (that also is using 3D 
hardware) is better optimized than Java's generic opengl drawing.

(3) I'd add a memory switch to up the maximum amount of mamory for the 
JVM. 512MB should be safe for all halfway current (last 5 years) Macs. 
Even on 0.5GB-RAM-Macs it should be safe---swapping is better than an 
out-of-memory exception, I'd say <g>

cu
Henry




More information about the josm-dev mailing list