Hi!
May I use SDL with separate windows (under Win)?
Ipse
Hi!
May I use SDL with separate windows (under Win)?
Not in SDL 1.2. It may be possible in future versions of SDL.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Plz, make it in versions.
IpseOn Wed, Jan 31, 2001 at 10:10:16AM -0800, Sam Lantinga wrote:
Hi!
May I use SDL with separate windows (under Win)?
Not in SDL 1.2. It may be possible in future versions of SDL.
(Just reminding about some ideas that were discussed earlier on the
list, and adding some API thoughts for 1.3.)
How about something like a flag SDL_ROOTWINDOW for the
SDL_SetVideoMode() call, suggesting that the resulting surface should
actually describe the desktop?
If the target is the desktop of X, Windows, BeOS, Mac OS, X etc, the
width and height arguments would be ignored, and the surface would
get the same size as the desktop.
For fullscreen mode (fbdev, svgalib, game consoles w/o desktops etc)
and with the SDL_FULLSCREEN flag set, the SDL_ROOTWINDOW flag would
be ignored (for all practical matters), and the result would be a
display that’s capable of hosting “sub surfaces”, or windows. (Insert
hooks for window manager here. A WM would need to add a "border"
surface under/around the window client surface and some other stuff.)
In the normal case on a windowed target (Windows, X, …), a surface
created with SDL_ROOTWINDOW would not be accessible, but just act as
an interface to the desktop in relation to windows. Another flag
(SDL_ROOTDRAWABLE or something) would indicate that we want the
surface to map to the desktop background. This would apply to
windowed as well as fullscreen modes.
Uhm… Well, that’s about it for now. Thoughts?
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 01 February 2001 09:34, Alexander Chemeris wrote:
On Wed, Jan 31, 2001 at 10:10:16AM -0800, Sam Lantinga wrote:
Hi!
May I use SDL with separate windows (under Win)?Not in SDL 1.2. It may be possible in future versions of SDL.
Plz, make it in versions.
Uhm… Well, that’s about it for now. Thoughts?
Um, no.
If you’re interested in building a GUI toolkit based on the underlying
window system, do that, don’t use SDL as an intermediary. If you need
the root window, you can get it from the system specific hooks in SDL_syswm.h
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Hmm…
And may I use SDL in one window, and still create other (child) windows?
Or use SDL in the child window?
IpseOn Wed, Jan 31, 2001 at 10:10:16AM -0800, Sam Lantinga wrote:
Hi!
May I use SDL with separate windows (under Win)?Not in SDL 1.2. It may be possible in future versions of SDL.
Yes. Look at the scrap demo for an example of mixing native window
manager calls with external program support. The easiest thing to
do is to make the SDL graphics window the parent window and create
your windows as children, but you can also do it the other way around
by setting the SDL_WINDOWID environment variable. Note that if you
set the SDL_WINDOWID environment variable that SDL no longer does
input handling on the window, assuming you are managing it at that point.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software> On Wed, Jan 31, 2001 at 10:10:16AM -0800, Sam Lantinga wrote:
Hi!
May I use SDL with separate windows (under Win)?Not in SDL 1.2. It may be possible in future versions of SDL.
Hmm…
And may I use SDL in one window, and still create other (child) windows?
Or use SDL in the child window?
Yes, but I’m not interested in using the underlying window system, as it
would be useless in fullscreen modes. I’d have to rewrite all that code for
every target, as well as implement it for SDL in fullscreen mode. My idea was
to do the first thing once and for all in SDL.
The whole point with making SDL aware of windowing and a root window possibly
managed by someone else is to enable widowed applications to work in
fullscreen mode as well as on a normal desktop. In fullscreen mode, a
third-party window manager would be used, unless one is built specifically
for the application. The MDI style (which could be done with a window
manager/toolkit only aware of the SDL display surface) is not suitable for
all applications, and not even a recommended GUI design for some targets.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 01 February 2001 19:51, Sam Lantinga wrote:
Uhm… Well, that’s about it for now. Thoughts?
Um, no.
If you’re interested in building a GUI toolkit based on the underlying
window system, do that, don’t use SDL as an intermediary. If you need
the root window, you can get it from the system specific hooks in
SDL_syswm.h
The whole point with making SDL aware of windowing and a root window possibly
managed by someone else is to enable widowed applications to work in
fullscreen mode as well as on a normal desktop.
I don’t see how this follows. What does SDL knowing about the root window
have to do with window management working in fullscreen mode?
I must be missing something. 
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I have a question about shaped windows. Does windows support shaped
windows? I know X does, if it has the correct extensions (And all
current X versions do). Could someone point me to some resources on
shaped Windows windows?
The reason I ask is because I already have an SDL windowing system. I
have windows I can move around and it has it’s own “desktop”. I am
wondering if I can actually make a “shaped” window, where my root really
doesn’t exist. If I create an SDL window with no border the same size
as the screen, and set the shape to include only the areas where there
are child windows, would this work?
Humn… I guess when you click on any other window it will bring it to
the top of all SDL “windows”…shouldn’t be bad, actually.
I am just looking for a cross platform way to use the desktop for some
sorts of games without monoplizing it.
Jamie Best
The whole point with making SDL aware of windowing and a root window
possiblymanaged by someone else is to enable widowed applications to work in
fullscreen mode as well as on a normal desktop.I don’t see how this follows. What does SDL knowing about the root window
have to do with window management working in fullscreen mode?
As I get it, “fullscreen mode” in this case should mean svgalib, for
example.
An environment without a windowmanager, that is.
As for his idea, I think it would be really powerful to have multiple SDL
surfaces as windows handled by the specific windowmanager. Until now, every
GUI for SDL causes the application to look “misplaced”, since all the
windows would be in a single root window (unaware of anything outside). A
concept like the described one could fix this, and make the SDL windows seem
more integrated.
I have a question about shaped windows. Does windows support shaped
windows? I know X does, if it has the correct extensions (And all
current X versions do). Could someone point me to some resources on
shaped Windows windows?
It has to be possible, take a look at the Go!Zilla window, which is a shaped
one. Take a look at www.codeguru.com, if I remember right, there was an
article with a sample there. Should be still there, if they havn’t changed to
much…
Hope that helps,
Andreas Podgurski
It’s probably not as obvious as it seems in my mind.
One more thing that I missed in the original message is that you also need an
interface to explicitly create windows - perhaps an SDL_CreateWindow() call
that in fullscreen mode would just create a “fake” surface struct, describing
a rectangular area of the screen surface, while in windowed mode (Windows,
X,…) it would create a real window.
As to window management, the normal case with windowed targets would probably
be to let the system WM deal with it, and let SDL manage only the client
rectangles of the windows. On a fullscreen target, there is no WM, so SDL
would have to provide a basic WM, or the application SDL could install it’s
own custom WM. SDL would basically just ask the WM if it wants to do anything
special about an SDL_CreateWindow() call (like adding an extra surface for
the window border).
As an example, a simple application with two windows and a custom WM for
fullscreen modes:On Monday 05 February 2001 19:20, Sam Lantinga wrote:
The whole point with making SDL aware of windowing and a root window
possibly managed by someone else is to enable widowed applications to
work in fullscreen mode as well as on a normal desktop.I don’t see how this follows. What does SDL knowing about the root window
have to do with window management working in fullscreen mode?I must be missing something.
_______________________
|Root window |
| ________ |
| |Window 1| ________ |
| | | |Window 2| |
| |________| | | |
| |________| |
|_______________________|
On a windowed desktop, the Root window would be the desktop, and wouldn’t
normally be accessed by SDL or the application. It would be a fake
SDL_Surface that cannot be drawn on; it would be used only to provide an
interface to the desktop size and other info. Window 1 and Window 2 would be
SDL_Surfaces of the same kind as the screen surface of current SDL. (This
would probably require that the implicit connection between some calls and
the single screen surface is replaced with an explicit surface argument.
Global screen info has to be connected to surfaces to allow multiple
instances.)
Now, if we were running in a fullscreen mode, the Root window would
effectively be the screen surface of current SDL, while the windows would be
either off-screen surfaces, or “sub surfaces”. (The latter would require a
more sophisticated clipping system to work like it does on a windowed
target…) As for WM and borders, Window 1 and Window 2 could be placed on
top of slightly larger windows, so that the WM gets somewhere to draw it’s
border widgets without affecting the window surface that the application
sees. (If they were children of the WM windows, the application would hit the
wrong target when accessing mywindow->parent…)
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’
Yes, that’s exactly what I’m after.
As to the root window, it’s not really required that SDL knows about it on a
windowed target, but not setting up even a fake SDL_Surface or something for
it would make fullscreen modes more different from windowed mode than they
have to be. That may, however, be more of an issue for the WM than for the
application…
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Monday 05 February 2001 20:10, Pius II. wrote:
The whole point with making SDL aware of windowing and a root window
possibly
managed by someone else is to enable widowed applications to work in
fullscreen mode as well as on a normal desktop.I don’t see how this follows. What does SDL knowing about the root
window have to do with window management working in fullscreen mode?As I get it, “fullscreen mode” in this case should mean svgalib, for
example.
An environment without a windowmanager, that is.
As for his idea, I think it would be really powerful to have multiple SDL
surfaces as windows handled by the specific windowmanager. Until now, every
GUI for SDL causes the application to look “misplaced”, since all the
windows would be in a single root window (unaware of anything outside). A
concept like the described one could fix this, and make the SDL windows
seem more integrated.
As an example, a simple application with two windows and a custom WM for
fullscreen modes:
|Root window |
| ________ |
| |Window 1| ________ |
| | | |Window 2| |
| || | | |
| || |
|_______________________|
I see what you mean now. It sounds like a good project in it’s own right,
and it seems to me that the right way to do it would be to write up the
framework outside of SDL and see how it works out.
Right now SDL has a lot of special case code to optimize the single-window
case. It would be a lot less work to try the idea out in the field and then
apply the principles learned to the next generation of the SDL API.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
What kind of special case code? Or: Would it be possible to throw in a big
struct of “global” screen related variables and a screen surface argument as
a quick proof of concept hack?
If not, I could still hack some simple sub window/surface and WM hook
framework for fullscreen targets as a patch for current SDL, but it would be
limited to a single window and no root window access on windowed targets. I
don’t have time to do anything nice and solid as I’m still trying to get MAIA
into some kind of beta stage, but I think I can hack something quick’n’dirty
together to demonstrate the API ideas, if it sounds useful to anyone.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Monday 05 February 2001 22:08, Sam Lantinga wrote:
As an example, a simple application with two windows and a custom WM for
fullscreen modes:
_______________________|Root window | | ________ | | | |Window 1| ________ | | | | | | |Window 2| | | | | |________| | | | | | | |________| | | |_______________________|I see what you mean now. It sounds like a good project in it’s own right,
and it seems to me that the right way to do it would be to write up the
framework outside of SDL and see how it works out.Right now SDL has a lot of special case code to optimize the single-window
case. It would be a lot less work to try the idea out in the field and
then apply the principles learned to the next generation of the SDL API.
Why my app exit, when I close child window, containing SDL?
May I use SDL on native C++ Builder form?
IpseOn Fri, Feb 02, 2001 at 09:44:37AM -0800, Sam Lantinga wrote:
And may I use SDL in one window, and still create other (child) windows?
Or use SDL in the child window?Yes. Look at the scrap demo for an example of mixing native window
manager calls with external program support. The easiest thing to
do is to make the SDL graphics window the parent window and create
your windows as children, but you can also do it the other way around
by setting the SDL_WINDOWID environment variable. Note that if you
set the SDL_WINDOWID environment variable that SDL no longer does
input handling on the window, assuming you are managing it at that point.