Discussion moved from Bundle o' starkits

NEM - I get an error on startup on Mac OS X:

 bad event type or keysym "grave"
   while executing
 "event add <<ShowAllAtCurrent>> <Control-grave>"
   ....
  (procedure "mapKeysToEvents" line 5)
   ....

This may well be a Mac OS X/Wishkit specific bug.

LV Interesting - well, that appears to be a tkoutline bug in the outlinewidget code. It should be simple enough to add a new switch case for MacOS X. What other keys are missing on the MacOS keyboards?

Brian Theado - Thanks for the report. As a quick fix I just removed that key binding entirely--it is mostly irrelevant to this application. Please redownload and try again. I guess noone on MacOS X has tried using tkoutline for the past year :(. Or just not telling me about the problems they encounter.

I've had trouble with this one before. Originally I was binding to <Control-`>, but that only worked on windows and I added a conditional to use <Control-grave> if not on Windows. I guess I'll rethink this binding for the next release. I don't think I'm using any other exotic bindings that will cause problems.

PWQ 21 Jan 05, LV, while the application may be causing the error I would not class this an bug. This is yet another example of people destroying the platform independence feature of tcl by adding in native components. the grave key should be implemented on all platforms and just ignored (or remapped) on ones that don't support it.

There is an increasing tendency to make applications not work on anything other than windows because of these features.

jcw - Nah. Maybe when on Windows, people 1) simply forgot the other 5%, 2) know too little about *nix, 3) just postpone it, or 4) leave it to those 5% to deal with it...

MG It seems to me that having it do nothing or remapping it would cause more problems than it raising an error. At least that way it's clear what the problem is, and it can be worked around in a way that makes sense for the app using it, whereas whichever key it would be automatically mapped to could already be in use for something else. IMHO it's just something that needs to be clearly documented, so people who want to code cross-platform know to avoid it or work around it for non-Windows platforms.

Lars H: I'd say this "grave" problem goes beyond platform differences. On for example a Swedish keyboard (to my knowledge regardless of platform) the grave accent is <Shift-acute>. Furthermore this is a dead-key, which means key-presses do not register until one presses another key (e.g. <Shift-acute><a> would normally yield \u00E0 -- latin small letter a with grave). It doesn't make much sense for Tk to error out just because some key is missing; the number of possible keys far exceed the number of keys on common keyboards, so you'll have to assume that the normal state of affairs is that lots of keys are missing. I suspect however that this area of Tk isn't all that heavily documented ...

LV I just posted a question about this to the TCT. I myself would prefer to see bind be able to be coded with the actual characters and let platform specific code translate that into the keysym needed. I also asked if anyone knew what other keysyms were potential problems. I'd guess that besides `, # is possibly a problem.

Benny Riefenstahl wrote in the tcl-core mailing list:

Short general answer: The actual keysym table for non-X11 platforms is in tk/generic/ks_names.h AFAICS. The current portable keysym name for "`" is actually "quoteleft".

It is a bug in itself that this deprecated name is the only name in that table for this particular key, but I guess it should continue to be supported by all platforms, even when that table is fixed to include the standard name "grave".

As the system is designed right now the standard keysyms are the only symbols that are guaranteed to work. For some characters the keysym is the same as the string/character. But keysyms are basically C macros, so "`" can not be a standard keysym. It is a platform-specific extension. I"m not sure why anybody thought it was a good idea to allow this on Windows.

> And what other keysyms are not platform independent?

The standard keysyms for ASCII and Latin-1 characters as well as the usual special keys (Return, cursor keys, etc) should be the same on Windows and Mac and they should work on X11. If that is not the case, that is simply a bug and should be reported on SF so that it can be fixed.

Sadly there is no support for characters outside of ASCII and Latin-1 on Windows and Mac, because keysyms outside of that range are not Unicode codepoints (they pre-date Unicode).

---