[PATCH] A Halfway Decent OS X Integration

[Henry Loenwind]

In response to #1471, I wondered how hard it would be to integrate JOSM better with OS X. That was a couple of hours ago, and now I know that it wouldn't be, ummm, WAS not hard. :-)

Here is the patch. All changes will only activate when JOSM is running under OS X and the communication with the native GUI classes succeeded:

(1) Application title will no longer read "org.openstreetmap.josm.gui.MainApplication" but "JOSM"

(2) Closing JOSM using the OS's methods (red button on window, menu option and keyboard shortcut) will trigger the "Unsaved changes" dialog.

(3) Selecting "About" in the system menu will display JOSM's about dialog.

(4) Selecting "Preferences" in the system menu will display JOSM's preferences dialog.

(5) Duplicate menu options for Quit, About and Preferences will be suppressed. (This will also remove their keyboard shortcuts, but as Ctrl-Q would have been mapped to Cmd-Q, and Cmd-Q is the OS's default, and F12 is invalid on most Macs, that is no issue.)

(6) JOSM's menu bar will be merged with the system menu bar. (So there will be one, not two menu bars for JOSM.)

(7) All keyboard shortcuts involving Ctrl will be changed to Cmd. Shortcuts using META will be mapped to Ctrl, so there won't be any conflicts. Note: This only works for shortcuts registered via the JosmAction constructor.

Included files:

AboutAction.diff - added a note to the about dialog announcing the successful integration

build.diff - changed main class to JOSM (see next item)

JOSM.java - empty subclass of MainApplication, so OS X will see a "fake" main class---it takes that name as an application title

JosmAction.diff - map Ctrl to Cmd

Main.diff - register the Quit, About and Preferences callbacks; new static property to report on working integration

MainApplication.diff - allow subclassing for JOSM.java; Request merging of the menu bars (must be called early)

MainMenu.diff - skip Quit, About and Preferences on OS X

Note again, that all changes are protected with an "if(withOSXIntegration)", and that is only set when OS X is detected AND the communication with the OS worked. All communication is protected with try{} blocks. So no ill effects are to be expected on other platforms.

[Henry Loenwind]

PS: I overlooked a detail:

(8) Menu option tool tip texts will contain no unparsed html.

(9) Menu option tool tip texts will contain text for "Del" and correct text for "+"

JosmAction2.diff - new version, use this one instead

ShortCutLabel.diff - added META, Del and PLUS

[Henry Loenwind]

Ok, I've got one more.

(10) Add the Quaqua LookAndFeel into the LookAndFeel list if it is installed

This depends on the rest of the patches, but not the other way around.

Note: QuaQua is a Third-Party (LGPL, btw) LookAndFeel for Swing. It must be installed separately and will provide a usable file open/save dialog (in contrast to the default, that cannot even change to the parent directory). It could provide more, but I was just interested in the file dialog, and it pulls in just that on my system (although I don't know why), so I'm happy.

Note 2: It is just added to the list, the user has to select it manually just like any other LookAndFeel to use it. No Quaqua code has been included with JOSM, all used interfaces are Swing.

---

PS: While testing this one I found out that (6 - merging the 2 menus) only works with the OS X and Quaqua LookAndFeels, not with Metal or CDE/Motif. I'd guess that's so by design, so not-a-bug.

[Henry Loenwind]

Ok, this one is 100% beautification: I added the correct symbol for the Del key on OS X into the menu item tool tip.

[Henry Loenwind]

Ooops, I've just noticed there is the tr() missing around "Del". Instead there were tr()s around the symbols. So, there's a third version...

[Henry Loenwind]

Update: I started on the ShortCutManager and decided to collect all the platform specific code into plugable classes while I'm at it. (public static Main.platform)

So there's no need to check in these patches for now.

[Henry Loenwind]

Update: I don't know if someone is listening, but nevertheless:

I created the shortcutmanager main class. It already manages shortcuts, that is stores them, hands them out to any who wants one, avoids dupes etc.

I created the os-despendent classes and the plugable structure for them. All OS-dependent things I did, I put there. I also moved some more there - I needed something to test and my own things weren't visible yet <g>

I changed the way JosmAction (base class for the things that are triggered by a shortcut or menu, or button) handles shortcuts and tooltips. Shortcuts are delegated to the manager, tooltips to the OS-classes. Works fine, however, I need to change all core actions to use the new interface, becasue the old needs to guess to much about which modifiers to map to which group. That's fine for legacy plugins, but there are too many things that just don't fit 100% in the core.

BTW: I found a good solution for the shortcuts that are to be mapped to a specific value per OS (and only on some OSes. e.g. Preferences must be mapped to Cmd-, (actually to nothing, because that shortcut is provided by the system menu), but not to anything specific on the other OSes): I just registter them very early from the OS-dependent class, and when the action tries to register them later, they will be handed pre-registered shortcut from the cache. Neat. An (independed) flag on the shortcut then tells the menu class (todo, actually), when an item should be skipped when building the menu. Seems weird that that flag is on the shortcut, but actually its meaning is "this shortcut is provided by the OS already, no need to put it up in addition", so I can live with it. BTW: on Windows "Alt+F4" is in that group, so it's not an OSX-specific thing.

Next to do: Changes to the menu builder. And then the GUI to actually configure the shortcuts manually. Also I should move more stuff from the core to the OS-dependent classes...

[Henry Loenwind]

OMG, I wasn't aware that I had to block that many shortcuts on OSX!

Um, maybe I'll unblock some of them later. I don't think it'd be evil to re-use the hotkey for "bold" for something else in an application that doesn't format text. However, the hotkey for "minimize window" should be blocked, even though we don't implement it...

BTW: I think, I don't want to do the blocking for Windows and Linux. Any volunteers?

PS: For the statistics: We have 60 shortcuts that are reserved for the OS (e.g. logoff, change keyboard layout, invert screen colors...) and 50 shortcuts that are reserved for pre-defined meanings (e.g. open, save, bold, undo...) on OSX. And 2 of each group I couldn't bind in Java, 2 on the EJECT key, one on "?" and one on "|". Arg, the last one should open the help window (==F1 on Windows)...

[Henry Loenwind]

Another status update:

Now the main menu is build the new way. Works like a charm, and shortened the code considerably, too. However, I still need to update all the Actions to use the new API. Not that they won't work, but it'd look much better in the Shortcut Preferences.

And that brings me to the biggest part of my work today. I built the Shortcut Preferences pane. To make it short: I hate GUI building. But it works. Ok, it works for displaying shortcuts. Changing is for tomorrow.

[Henry Loenwind]

I just wanted to start on adapting the actions when I noticed the time. Ok, i I'd start that now, I'd get no sleep at all, bad idea. I I wanted so much to get finished today...

So here's the daily status update: I am finished, with 2 exceptions: (1) adapting the existing actions and (2) moving more stuff into the OS-specific classes.

I've also seen that there was no change in the svn since I started. I'd be really great if that could stay that way for another day. <begging mode="Puss in Boots" reference="Shrek 2">Please...</begging>

[Henry Loenwind]

I have created a new ticket #1622 for the new patch. Closing this one.

[traut]

Did this become part of the current releases?

(6) and (7) do not work as described.