I want my SDL application to have a full Cocoa UI. I’ve read various old threads
on Cocoa & SDL and so far am using setenv to set a non-zero value for
SDL_ENABLEAPPEVENTS and have added a sendEvent handler to my implementation of
SDLApplication that checks if incoming events are keyboard related, and if so
throws them away if command is not pressed. With a bit of nib magic from
Interface Builder that gives me a fully interactive Cocoa UI with the one
obvious defect ? it isn’t responding to keypresses that don’t have command
pressed. As a result things like “File->Save” are almost impossible to use. Of
course if I don’t filter keyboard input like this then every time the user
presses a key I get an error beep as Cocoa thinks the user has pressed a key
that doesn’t do anything.
My slightly hacky solution so far is to keep an internal flag of any time I
launch a dialogue that would want proper keyboard input and not to filter it
out until that dialogue has finished. I’m wondering if there is a better
solution that can be implemented while still separating my Cocoa code from the
main body of my ordinary cross-platform code. Perhaps some sort of invisible
window that accepts ordinary keypresses while my app is active but does
nothing with them?
I’d be curious to hear what others have done to get around this problem.
P.s. this is the only forum I’ve ever posted to that has made me hand-edit my
post so that it has no lines longer than 80 characters. Can that really not
be done automatically?
i am not an expert, but would suggest leaving platform specific code out
of some thing portable. i was at one point messing with qt, it worked
well on osx and linux. i didnt try my sdl app in the qt gui yet as my
game core is not done yet. also, the core is all in C, and the UI which
was qt was in c++. just an idea…
matt
Thomas Harte wrote:> I want my SDL application to have a full Cocoa UI. I’ve read various old threads
on Cocoa & SDL and so far am using setenv to set a non-zero value for
SDL_ENABLEAPPEVENTS and have added a sendEvent handler to my implementation of
SDLApplication that checks if incoming events are keyboard related, and if so
throws them away if command is not pressed. With a bit of nib magic from
Interface Builder that gives me a fully interactive Cocoa UI with the one
obvious defect ? it isn’t responding to keypresses that don’t have command
pressed. As a result things like “File->Save” are almost impossible to use. Of
course if I don’t filter keyboard input like this then every time the user
presses a key I get an error beep as Cocoa thinks the user has pressed a key
that doesn’t do anything.
My slightly hacky solution so far is to keep an internal flag of any time I
launch a dialogue that would want proper keyboard input and not to filter it
out until that dialogue has finished. I’m wondering if there is a better
solution that can be implemented while still separating my Cocoa code from the
main body of my ordinary cross-platform code. Perhaps some sort of invisible
window that accepts ordinary keypresses while my app is active but does
nothing with them?
I’d be curious to hear what others have done to get around this problem.
P.s. this is the only forum I’ve ever posted to that has made me hand-edit my
post so that it has no lines longer than 80 characters. Can that really not
be done automatically?
Have you looked at the Xcode template project called “SDL Custom Cocoa
Application”? I think it demonstrates a lot of what you are talking
about.
-Eric> From: Thomas Harte <thomas.harte at gmail.com>
I want my SDL application to have a full Cocoa UI. I’ve read various old
threads
on Cocoa & SDL and so far am using setenv to set a non-zero value for
SDL_ENABLEAPPEVENTS and have added a sendEvent handler to my implementation
of
SDLApplication that checks if incoming events are keyboard related, and if
so
throws them away if command is not pressed. With a bit of nib magic from
Interface Builder that gives me a fully interactive Cocoa UI with the one
obvious defect ? it isn’t responding to keypresses that don’t have command
pressed. As a result things like “File->Save” are almost impossible to use.
Of
course if I don’t filter keyboard input like this then every time the user
presses a key I get an error beep as Cocoa thinks the user has pressed a key
that doesn’t do anything.
My slightly hacky solution so far is to keep an internal flag of any time I
launch a dialogue that would want proper keyboard input and not to filter it
out until that dialogue has finished. I’m wondering if there is a better
solution that can be implemented while still separating my Cocoa code from
the
main body of my ordinary cross-platform code. Perhaps some sort of invisible
window that accepts ordinary keypresses while my app is active but does
nothing with them?
I’d be curious to hear what others have done to get around this problem.
P.s. this is the only forum I’ve ever posted to that has made me hand-edit my
post so that it has no lines longer than 80 characters. Can that really not
be done automatically?
As this is a mailinglist your mail
or news-client should do this.
As this is a mailinglist your mail
or news-client should do this.
I think he posted through gmane.org, which is a web gateway for mailing
lists. I don’t think it has a problem with word wrapping, though…but
you can always use a real mail client by subscribing here:
Most major functionality is done. Some work on keyboard input, and Linux 2D
backends still need to be done, but it’s definitely in the experimental use
stage.
See ya,
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Ok, at the rate I release Tux Paint (once every year), it may be at a point
where I can safely play with the new APIs. >:^)
Thx Sam!On Thu, Nov 30, 2006 at 08:34:12PM -0800, Sam Lantinga wrote:
Perhaps time to throw Tux Paint at it. >:^)
Any ETA on SDL 1.3?
Most major functionality is done. Some work on keyboard input, and Linux 2D
backends still need to be done, but it’s definitely in the experimental use
stage.
