I have a nib-less SDLmain-less Cocoa setup in SDL 1.3, and I’m implementing
keyboard support now. However, as soon as I take full control over the key
input, the window shortcuts in the menu will no longer work.
So my question is, should I put up a window menu for the default SDL app?
Should it respond to the keyboard shortcuts? Should it also pass those
keys to the application?
Discussion welcome! 
Thanks,
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Sam Lantinga wrote:
I have a nib-less SDLmain-less Cocoa setup in SDL 1.3, and I’m implementing
keyboard support now. However, as soon as I take full control over the key
input, the window shortcuts in the menu will no longer work.So my question is, should I put up a window menu for the default SDL app?
Seems like a good idea to me. It can be useful, most Mac OS X
applications have one, and even if it’s not used it doesn’t hurt. In
fact, SDL 1.2 has it too, and I’ve never heard anyone complain about it,
even though it’s not terribly useful in single-window apps.
Should it respond to the keyboard shortcuts? Should it also pass those
keys to the application?
That’s a more difficult question. It certainly shouldn’t eat away key
events before they reach the application. My preferred solution would be
that only events that the application decides not to handle would be
passed on to the OS for processing as menu shortcuts. Maybe an
SDL_PassEvent(event) function or something. I could also live with the
way things work in SDL 1.2, though, i.e. keyboard shortcuts don’t work
unless the application interprets them itself “by hand”.
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. However, I haven’t got very far with it yet,
and since I don’t have much spare time currently I’ll probably be late.
Can you provide an estimate of the timeframe in which you’d still be
willing to accept additions to the API currently defined in
SDL_keyboard.h/SDL_keysym.h? (If you’re willing to accept them at all,
that is, and of course the thing would have to go through public
scrutiny before being integrated.)
-Christian
Hello !
So my question is, should I put up a window menu for the default SDL app?
Would it be possible to dynamically
enable / disable this from the SDL app ?
Maybe dynamically from sdl2-config ?
Should it respond to the keyboard shortcuts? Should it also pass those
keys to the application?
Are the shortcuts used in the menu fixed
or can the user change them ?
If the user cannot change them and they are fixed
on every OS X than it is okay to deliver the events
to the SDL app as the user than can ignore them.
When i know okay APPLE xy is used in the menu,
then in my event loop i can ignore them.
It would be good to have a way to ignore system
keyboard shortcuts, as this makes coding of emulators
easier.
CU
Sam Lantinga wrote:
I have a nib-less SDLmain-less Cocoa setup in SDL 1.3, and I’m implementing
keyboard support now. However, as soon as I take full control over the key
input, the window shortcuts in the menu will no longer work.So my question is, should I put up a window menu for the default SDL app?
Seems like a good idea to me. It can be useful, most Mac OS X
applications have one, and even if it’s not used it doesn’t hurt. In
fact, SDL 1.2 has it too, and I’ve never heard anyone complain about it,
even though it’s not terribly useful in single-window apps.
Should it respond to the keyboard shortcuts? Should it also pass those
keys to the application?
That’s a more difficult question. It certainly shouldn’t eat away key
events before they reach the application. My preferred solution would be
that only events that the application decides not to handle would be
passed on to the OS for processing as menu shortcuts. Maybe an
SDL_PassEvent(event) function or something. I could also live with the
way things work in SDL 1.2, though, i.e. keyboard shortcuts don’t work
unless the application interprets them itself “by hand”.
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.
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). This allows the key layouts
presented to the user to make sense with with what they see on the keyboard.
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.
See ya,
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Sam Lantinga disse:
I have a nib-less SDLmain-less Cocoa setup in SDL 1.3, and I’m implementing
keyboard support now. However, as soon as I take full control over the key
input, the window shortcuts in the menu will no longer work.So my question is, should I put up a window menu for the default SDL app?
Should it respond to the keyboard shortcuts? Should it also pass those
keys to the application?Discussion welcome!
My vote goes to the osx version having a trivial/empty libSDLmain.
Any chance of the “SDL must own main” problem being resolved for 1.3?
Hello !
My vote goes to the osx version having a trivial/empty libSDLmain.
Any chance of the “SDL must own main” problem being resolved for 1.3?
Somewhere Sam wrote that SDLmain is not
needed on OS X with SDL 1.3 anymore.
CU
My vote goes to the osx version having a trivial/empty libSDLmain.
Any chance of the “SDL must own main” problem being resolved for 1.3?
Yes, SDLmain is completely gone on Mac OS X in SDL 1.3
-Sam Lantinga, Senior Software Engineer, Blizzard EntertainmentHello !
My vote goes to the osx version having a trivial/empty libSDLmain.
Any chance of the “SDL must own main” problem being resolved for 1.3?Yes, SDLmain is completely gone on Mac OS X in SDL 1.3
Why was it needed in 1.2 but not 1.3 ?
CU
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
I pretty much agree with everything Christian has said. Keeping a
Window menu shouldn’t hurt.
The most important thing about key presses is that the user-defined
behavior must override the the OS processing. If the user defines Cmd
as fire, and Q as jump, we don’t want to see the application quit
every time the player tries to simultaneously jump and fire. (I know
we’ll never hear the end of those bug reports, especially when these
projects are Windows or Linux centric and are porting over to OS X for
the first time.)
An SDL_PassEvent function as Christian describes might be interesting.
Though it might be hard to get people to use the function unless it is
useful to other windowing environments (Windows, Gnome, KDE, etc). I’m
not sure what that code looks like though in the cases where the OS
event keys don’t match per-platform. (For example, does it matter that
Windows uses Ctrl and Apple uses Cmd?)
Another idea would be to automatically determine if the event was
handled or not and there was an API option to allow unhandled events
to be passed on to the OS. But I think this would require a different
API approach to event handling.
Thanks,
-Eric
My vote goes to the osx version having a trivial/empty libSDLmain.
Any chance of the “SDL must own main” problem being resolved for 1.3?Yes, SDLmain is completely gone on Mac OS X in SDL 1.3
Legends! So which unfortunate platforms still rely on owning main?> From: Sam Lantinga
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)?
Sure!
There’s plenty of work left to be done on 1.3 before a preliminary release.
See ya,
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Why was it needed in 1.2 but not 1.3 ?
SDLmain was the natural place to start the NSApplication, especially
since it normally takes the argc/argv parameters. SDLmain also filtered
out Finder arguments, and translated file drop requests, none of which
is supported in the SDLmain-less 1.3.
However, I think I’ve set it up so that you can still use a nib, and your
own SDLmain with SDL 1.3, if you want to, it’s just no longer required.
See ya,
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
I pretty much agree with everything Christian has said. Keeping a
Window menu shouldn’t hurt.
The most important thing about key presses is that the user-defined
[…]
This is already resolved, check current source in subversion.
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment