MapTool 1.3 Development Build 48

[Craig]

I'm going to start a tangent that is related to Build 48. I don't believe it: a thread re-rail!

I've been looking through the MT code and there are a few places where the code has an explicit getKeyStroke("control C") when it should have a reference to the Actions in AppActions. I've updated those in my code so everything now pulls from a single location.

My question deals with the Mac convention of using "meta C" instead of "control C" for COPY (same with CUT and PASTE). I have edited the i18n.properties in my development version of MT so that I can use the Mac keys, but what is the right way to handle that change?

The best approach seems to be to check for the platform early on in the startup process and build a "Platform" object that sits in front of the LAF (and possibly other objects). The Platform object would provide factories for the LAF and anything else that may come up down the road. The LAF factory would create the TinyLAF and then change the keystrokes on the Mac; on other platforms it would be a pass-thru.
Is that the right way to handle it?

For this (and several other UI platform differences) AWT is your friend. In this case, specifically
java.awt.Toolkit.getDefaultToolkit().getMenuShortcutKeyMask() This is sun (and apple for that matter) recommend way of doing things.

I am not sure if building a Platform abstraction is of much value unless you have other things that you want to put in there that don't already exist, and I hazard a guess that most of the things you would want to put in there already have abstractions that live in well documented and standard classes (even if they are darn hard to find some times).

Edit: for clarity

[Azhrei]

Thanks for the pointer. It looks like this thread has some code samples that others have used on various platforms with good results. (This thread also appears to have some good Windows/Mac coding notes.)

I think it's a bit annoying to call it a Menu Shortcut mask, but whatever.

But I'm still not sure what the correct way is to code it. Are you saying that the Actions should be coded so that they are created using both the VK_* key and the return value from getMenuShortcutKey()? How is that properly represented in the properties file, then, which is where MT stores accelerator information?

[Craig]

Thanks for the pointer. It looks like this thread has some code samples that others have used on various platforms with good results. (This thread also appears to have some good Windows/Mac coding notes.)

I think it's a bit annoying to call it a Menu Shortcut mask, but whatever.

But I'm still not sure what the correct way is to code it. Are you saying that the Actions should be coded so that they are created using both the VK_* key and the return value from getMenuShortcutKey()? How is that properly represented in the properties file, then, which is where MT stores accelerator information?

Ok I am not sure if this answers your question (I blame Christmas spirit for my current state of "brain no worky")

Take this line from PointerTool.java (832)

Code: Select all

actionMap.put(KeyStroke.getKeyStroke("control C"), AppActions.COPY_TOKENS);

and say you had

Code: Select all

AppAction.getCopyKeyCharacter()

Which returns the characer 'c' (and only the character)

You could change the line in PointerTool.java to read

Code: Select all

actionMap.put(KeyStroke.getKeyStroke(AppAction.getCopyKeyCharacter(),    
                               Toolkit.getDefaultToolkit().getMenuShortcutKeyMask()), 
                               AppActions.COPY_TOKENS);

Or you could have your method to return the correct KeyStroke already built with getKeyStroke, but that would mean I have to type a larger example

You wouldn't store the meta or control in your properties file as people usually want that to work the way their OS is working for other apps anyway.

Hope this helps.

[Azhrei]

Yeah, I think I'll put the result of getMenuShortcutKey() into a private static final so that the code is shorter and cleaner.

That does mean that the properties file needs to document that even though it contains on a letter "c", the application will be adding the menu modifier key to it automatically. That keeps the properties file portable at the risk of someone adding the modifier there when they shouldn't...

[trevor]

Code submissions happily accepted

[Azhrei]

Yep, will do. I've got a game on Tuesday night, so I might work on it before then but the patches will be to you by the end of the week.

Did you get the patch for the load/save map functionality? (I don't know if I should ping you on patches until I get a confirmation or just let it slide?)

[trevor]

I did get it, haven't checked it out yet, but will

[trevor]

Performance Question:

I have a campaign loaded and I'm seeing very slow performance on two operations in particular. I have a set of 16 tokens on one map (just practice tokens for messing with). If I drag-select them, it takes about 10 seconds from the moment I've described the selection box with the mouse to the moment they appear to be selected. If I then hit the Delete key, it takes about 10 seconds from the moment I do so until the tokens are actually deleted.

Thank you for the campaign it was very helpful.

Turns out that selecting a group of tokens causes the selection macro panel to update .... a lot. And it's expensive to update it.

I've updated the code to delay the selected macro panel update until all of the tokens are selected. Goes much quicker now.

[Rumble]

Thank you for the campaign it was very helpful.

Turns out that selecting a group of tokens causes the selection macro panel to update .... a lot. And it's expensive to update it.

I've updated the code to delay the selected macro panel update until all of the tokens are selected. Goes much quicker now.

No problem! Glad I could help.