[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