There seems to be a bug in the windows message handling for both
the dx5 and dib code. Basically, the HandleMessage function pointer in
wincommon/SDL_sysevents.c seems to get NULLed out at line 484, thus
disabling both HandleMessage functions in windx5/SDL_dx5events.c and
windib/SDL_dibevents.c. When I comment out line 484 in SDL_sysevents.c,
the keyboard starts working under WinNT4.0 ( it uses windib and it looks
like SDL_dibevents.c handles the keyboard messages ) and the F10
key is properly handled by SDL_dx5events.c ( since it catches all
WM_SYSCOMMAND messages ) under WinME.
However, I’m not sure that commenting it out is correct since the
comment before states:
/* Prevent us from doing special message handling */
but I want it to handle special messages! Otherwise the keyboard
does not work under WinNT4.0 and pressing F10 always loses
focus under WinME/98. BTW, using SDL_WM_GrapInput() doesn’t help -
focus is still lost - plus NO events are generated after the
initial F10 key press event. Am I missing something?
Adam
P.S. We generally test our code under Linux, WinNT40, Win98, WinMe, Win2k.
I’m hoping to add a Solaris and OS X test clients next month. So cross
compatability is very important to me
This part of the code (wincommon/SDL_sysevents.c) looks like a good place to
insert a hook to handle the case WM_COMMAND; this is what is recieved when a
standard Windows window (ie button, textbox) is interacted with. Since so
many people have expressed an interest in SDL and GUIs, maybe we should
consider supporting the native GUI (if there is one) of the OS? For
example, the Win32 gui would be just that, the Win32 API. The Linux version
might be GTK or some other specified lib. MacOS could use the standard Mac
API as well, I assume.
This would mean that an SDL app using the GUI would appear a little
different in Windows than under Linux (unless you use GTK for windows : ) ,
but it seems a lot more efficient than relying on another 3rd party library.
Besides, most people are probably more comfortable with their native GUI
than these others. Of course, part of the joy of gaming is new
experience…
This part of the code (wincommon/SDL_sysevents.c) looks like a good place to
insert a hook to handle the case WM_COMMAND; this is what is recieved when a
standard Windows window (ie button, textbox) is interacted with. Since so
many people have expressed an interest in SDL and GUIs,
I’m surprised by what you’re saying as some projects existe in such a
way… like ParaGUI, or SDL_Gui…
maybe we should> consider supporting the native GUI (if there is one) of the OS? For
example, the Win32 gui would be just that, the Win32 API. The Linux version
might be GTK or some other specified lib. MacOS could use the standard Mac
API as well, I assume.
This would mean that an SDL app using the GUI would appear a little
different in Windows than under Linux (unless you use GTK for windows : ) ,
but it seems a lot more efficient than relying on another 3rd party library.
Besides, most people are probably more comfortable with their native GUI
than these others. Of course, part of the joy of gaming is new
experience…
Since so
many people have expressed an interest in SDL and GUIs,
I’m surprised by what you’re saying as some projects existe in such a
way… like ParaGUI, or SDL_Gui…
Please read to the end of the message. The key of the proposal is to make a
wrapper for each native GUI, that is Win32 on Windows, GTK on Linux, and
MacOS Toolbox on Macs, so that the applications have the proper look on each
of these systems.
A very good idea, I think. It won’t be easy to accomplish, though.
But if anyone was to program something in the way, I’d be really grateful.
maybe we should
consider supporting the native GUI (if there is one) of the OS? For
example, the Win32 gui would be just that, the Win32 API. The Linux
version
might be GTK or some other specified lib. MacOS could use the standard
Mac> > API as well, I assume.
Please read to the end of the message. The key of the proposal is to make a
wrapper for each native GUI, that is Win32 on Windows, GTK on Linux, and
MacOS Toolbox on Macs, so that the applications have the proper look on each
of these systems.
A very good idea, I think. It won’t be easy to accomplish, though.
But if anyone was to program something in the way, I’d be really grateful.
if i were going to undertake anything of this proportion, i
certainly wouldn’t tie it sdl. of course, multiple backends
with sdl being one of them would be a nice start.
to get an idea of the size of project this is, take a look
at wxwindows, it is enormous. http://wxwindows.org/
try taking a look at how a package is written and put together.
think about how if you were to put that much code together, why
it would be a better project.
Since so
many people have expressed an interest in SDL and GUIs,
I’m surprised by what you’re saying as some projects existe in such a
way… like ParaGUI, or SDL_Gui…
Please read to the end of the message. The key of the proposal is to make a
wrapper for each native GUI, that is Win32 on Windows, GTK on Linux, and
MacOS Toolbox on Macs, so that the applications have the proper look on each
of these systems.
A very good idea, I think. It won’t be easy to accomplish, though.
But if anyone was to program something in the way, I’d be really grateful.
Oh, I’ll add to the flak on this one
windows : reasonable; but I dinna know how well win32 runs it’s atoms
under DirectX
apple : not a clue - same situation;
linux : no standard GUI. period. But you can make hooks into current
GUI when available… (under X; window manager optional)
fb -> both qt and gtk are now available g but not default;
(default == standard console)
svga -> no native;
I will say it’s a reasonable request - but if a project such as ParaGUI
were to act as a moderator between a program and the hosting GUI this
would make sense
AFAIK window handle’s available under directx, macos, and linux/X, so
providing a small set of helpers for these platforms would be possible.
They have almost -nothing- in common when it comes to interfacing with gui
other than rough appearance so a universal GUI interface would only add a
possibly unreasonable level of complexity.
G’day, eh?
- Winterlion, with unfounded opinions :)On Wed, 24 Jan 2001, Pius II. wrote:
–
Any fool could be a witch with a runic knife, but it took skill to be one
with an apple-corer.
- Terry Pratchet, Carpe Jugulum
Member in purple standing of the Mad Poet’s Society.
Trying to bring truth from beauty is Winterlion.
find at this winterlions’ page
Please read to the end of the message. The key of the proposal is to make a
wrapper for each native GUI, that is Win32 on Windows, GTK on Linux, and
MacOS Toolbox on Macs, so that the applications have the proper look on each
of these systems.
A very good idea, I think. It won’t be easy to accomplish, though.
But if anyone was to program something in the way, I’d be really grateful.
There’s a company in Oakland called D’loo. They’re doing just this.
They’re also including KDE and PalmOS along with Windows and GTK+…
There seems to be a bug in the windows message handling for both
the dx5 and dib code.
There are three things happening.
First, SDLmain.lib contains a WinMain() which calls SDL_RegisterApp(),
setting things up, and then the driver creation code fills in the handler.
Second, it sounds like you just uncovered a bug which I thought was
taking place in the NT DLL code. The handler should be set in the window
creation code, not the driver creation code. I’ll fix that now.
Third, you still need to call SDL_RegisterApp() from the main code and
not the DLL for DirectInput to initialize properly… I think…
P.S. We generally test our code under Linux, WinNT40, Win98, WinMe, Win2k.
I’m hoping to add a Solaris and OS X test clients next month. So cross
compatability is very important to me
Great! The more testing the better!
Thanks!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I’m just starting to use paragui, it seems to have a powerfull theme loader
so why don’t we write a routine able to convert the OS-GUI info in .xml for
paragui? I don’t know where to start from (i’m not an expert in win api, mac
OS and so on …). But I think that, at least, we will have a console really
similar with the one of the OS of the user.
I’m just starting to use paragui, it seems to have a powerfull theme loader
so why don’t we write a routine able to convert the OS-GUI info in .xml for
paragui? I don’t know where to start from (i’m not an expert in win api, mac
OS and so on …). But I think that, at least, we will have a console really
similar with the one of the OS of the user.
