I ran into this myself, but I didn’t want to modify SDL to fix it. I worked around it by copying the definition of SDL_Window into my code (at least everything up to and including the flags member) so that I could modify the window flags directly. My code looks something like this:
const void *magic;
int x, y;
int w, h;
int min_w, min_h;
int max_w, max_h;
typedef struct SDL_Window SDL_Window;
Then, in my video initialization code:
window = SDL_CreateWindowFrom((void *)xwindow);
window->flags |= SDL_WINDOW_OPENGL;
The last line turns out to be necessary to get OpenGL initialized properly.
It’s definitely an evil hack, but I couldn’t find any other way to make this work. I don’t want to use OpenGL directly as I’m trying to keep most of my code as platform-independent as possible, so I’d rather let SDL handle the rendering. The port using the hack above is guaranteed to use OpenGL though so I don’t feel too bad about it. :-/
With this setup, no window system events make it through to SDL (this makes sense because the toolkit wants to handle those itself). Timer events do, as do joystick/gamecontroller events. If you want the latter, you’ll need to set SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS to 1. Otherwise SDL will discard the events because it thinks the window doesn’t have keyboard focus, and there’s no API call to tell it that it actually does.
My code has handlers for the toolkit’s window, keyboard and mouse events. These handlers translate the events to the appropriate SDL_Event structures and push them into the SDL event queue with SDL_PushEvent(), and sometimes call SDL other API calls as necessary (such as SDL_SetWindowSize() when the embedded window changes size). This way the rest of my code only needs to worry about handling SDL events, and will work as-is if I build my code with the GUI disabled.
Keyboard events can also be a pain. Significant parts of the SDL keyboard state are not accessible (without nasty hacks anyway), and getting an accurate map between your toolkit’s key events and the corresponding SDL_Scancodes and SDL_Keycodes is not trivial. I decided to have my SDL key event handler only care about the keysym, key state and modifier state of the event and to track key press/release state internally instead of using SDL_GetKeyboardState(). This way the code that converts toolkit key events to SDL key events only needs to worry about a few fields instead of perfectly mapping the toolkit event to
an equivalent SDL event.