[josm-dev] Crtl-O used twice

Henry Loenwind henry at loenwind.info
Mon Sep 22 01:33:54 BST 2008


Frederik Ramm wrote:

>> PS: Ideas for the shortcut manager (additions welcome):
> 
> Do check if there's something out there already that we could use. I 
> have a hunch that we are not the only ones with a problem here.

Sure, but first we need to collect the requirements...

>> * classification of shortcuts (painting command (a/s/d), system 
>> commands (open, save, help), menu commands (download, export), 
>> function shortcuts (toggle history/layers/properties))
> 
> I don't think this is a classification that comes naturally to programmers.

Not that hard, I'd say. Most existing shortcuts are already classified 
properly---by using the appropriate modifier key.

>> * automatic conflict handling (second painting command to request "O" 
>> will get "Shift-O" instead)
> 
> This has a lot of potential for trouble. We'll at least have to 
> investigate the order in which plugins are loaded to avoid two almost 
> identical configurations using different shortcuts because one loads 
> plugin A first and the other, B.

Is the order the plugins are loaded not consistent? May be worth to sort 
the pluginlist by stage and name instead stage only. However, that won't 
fix the difference when an early plugin is loaded or not, and a late 
plugin wants the same key.

Workaround: All encountered shortcuts are saved (regardless whether the 
user has changed them or not). When a conflict is encountered, a warning 
popup is displayed. The changed shortcut is of course also saved, so 
there won't be multiple warnings about the same shortcut. Also this will 
force the warning to be about a new plugin's shortcuts always, even it 
that's a early plugin that conflicts with an older late plugin.

>> * manual override (a.k.a. configurable shortcuts)
> 
> I'd love to have manual configuration for the modifier keys in drawing 
> mode as well.

So I'll save the information if a shortcut's modifier has been changed 
by the user and add modifier selections for the groups. So a user can 
change a shortcut and then change the shortcut group's modifier without 
effecting the manually shortcuts but effecting all unchanged and all 
conflict-auto-changed shortcuts.

>> * proper shortcut to text rendering for all keys on all platforms 
>> (LiveGPS:Auto-Center is rendered as "$" currently, correct would be 
>> "Home" (en) or "Pos1" (de) on Windows or Cmd-Symbol + Home-Symbol on 
>> OS X. Oops? Is it home or ctrl-home on Win???)
> 
> Please, no platform-specific code if it can be avoided. Maybe we're 
> lucky and can find a library that does it for us. (Then again, 

No it cannot be avoided. What should I print for KeyEvent.VK_DELETE by 
default? There is no platform-independent text for it. On some platforms 
there isn't even a language-independent text for it. However, it seems 
there must be a table already be implemented somewhere in Swing, because 
the tooltips of Metal and/or CDE/motif (can't remember exactly) already 
contain the same text we put in there. However, if that's not accessible 
for us, there will be a class with a big stringtable (or one for each 
platform). Also, there is no platform independent default---the same key 
is named Meta on Linux, Windows on Windows and Command on OS X...

> Java/Swing was supposed to make everyone feel at home, and it seems it 
> didn't work.)

No. Awt was that one. Swing is the one that is supposed to make everyone 
alienated, because it always looks the same and does not fit in 
anywhere. <g>

BTW: The common workaround for the broken Swing JFileChooser on OSX is 
to use the awk file dialog. I was halfway through researching how to do 
that when I finally found the Quaqua LAF.


However, I plan to put all platform and LAF dependent data into a 
separate class. So we can ship with Win/OSX/*nix and allow plugin 
authors to provide the non-common ones like Beos or OS/2.

So the only thing that must reside mixed in will be startup handling. We 
won't be able to refactor this out unless we use conditional compiling. 
The only thing we could to is to put it into different classes (JOSM 
extends MainLinux extends MainWindows extends MainOSX extends 
MainApplication extends Main extends main). I don't really think I'd 
like that ;)

cu
Henry





More information about the josm-dev mailing list