[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