[SDL] Cocoa window menus in 1.3

[Christian Walther]

Sam Lantinga wrote:
> So I left the menus there, but disabled keyboard shortcuts.  The SDL
> event loop eats key events so they don't cause beeps.  I've tried several
> different approaches to stop the beeping, but I haven't found anything
> that works yet.

Ah, right, didn't think of the beeping. I'm afraid I can't be of much 
help here, I'd have to read the documentation and try out things too.

>> By the way, speaking of keyboard support in SDL 1.3: I've long planned 
>> to write up a prototype implementation (for Cocoa and X11) of the 
>> "physical keycode" support I've been whining about for a while before 
>> the 1.3 API is finalized.
> 
> I'm not sure exactly what you mean by "physical keycode" support.  The
> intended behavior is that the SDL keysym reflects the unshifted keys
> printed on the keyboard (the key layout). 

Yes. I'm OK with that (as long as it's consistent across platforms). I 
don't find it optimal, but I've accepted that you and other people are 
of different opinion. So I don't intend to change that. The thing I have 
in mind would be an addition. Among other things, an additional field in 
the SDL_keysym structure. (Which is why the 1.2/1.3 transition would be 
a natural place to introduce it.)

> This allows the key layouts
> presented to the user to make sense with with what they see on the keyboard.

(Which my solution would allow too.)

> If you always want the same physical key layout, regardless of the type of
> keyboard, you should use the hardware dependent scancodes directly, which
> is why they're available.

Yes. That's what the people who need it (emulator authors, mainly - and 
I'm not even one of them) do today. But wouldn't it be more convenient 
if those scancodes *weren't* hardware dependent? Isn't the whole point 
of SDL to abstract away platform dependencies?

It's mainly because I was tired of these discussions that I decided to 
try to provide a prototype implementation, so that people could see for 
themselves whether they find it useful or not, instead of me failing to 
explain it over and over again. And, of course, to see if what I have in 
mind works at all, before I'm too much of a loudmouth about it. 
Unfortunately, that thing was quite low on my priority list for a long 
time, and the question now is: if I hurry up now, is there any chance to 
get this into SDL 1.3 (provided that people, and ultimately you, agree 
once they see it)?

  -Christian