This message is about how to add multiple window support to SDL. It is
not about how to do multiple windows using the current version of SDL.
Last fall I spent a lot of time working on adding multiple window
support to SDL. I got as far as having a version of SDL that can create
multiple top level windows under X. (I work on Linux so X was it.) I
stopped working on it at Christmas time and and have been mostly not
working on it since.
The main reason for not working on it is that I don’t like the solution
I have come up with for a problem I ran into when I started looking at
adding multiple window support for devices that don’t have a window
manager. SDL works just fine on any device that has a dumb frame buffer.
It just takes over the screen and lets you blit to it and do what you
want.
One of the reasons that SDL applications are so portable, and why SDL is
so portable, is that it treats a window as just another dumb frame
buffer. To SDL everything is just a collection of pixels. (Sure, I’m
ignoring OpenGL right now, so don’t worry about it.) The key is that SDL
only gives you one visible surface and it treats every visible surface
as a frame buffer that might change size once in a while. This feature
of SDL is a glorious thing.
So, when I started adding multiple windows to SDL I just extended that
concept. I added APIs to let you create more than one window and added a
window ID to events. This worked great. And, it looks like it can be
extended to support sub-windows within top level windows.
The problem comes when you start to add multiple window support for
things like the frame buffer driver or the DGA driver. A window on X or
MS Windows is embedded in a desktop. Each SDL window is just another
window on the desktop. It may, or may not, have a border and window
decorations. But, the key is that every top level SDL window is actually
a sub-window of the desktop’s root window. The trouble with implementing
multiple windows on the frame buffer or DGA driver (and I expect the new
ipod driver) is that there is now root window. There is only the frame
buffer and SDL takes over the whole thing.
So, in that situation what do you do when someone asks to create a new
top level window after they have already created a top level window
(which is the whole screen)? I’m stuck in a box here and I need someone
to open a window for me so I can get out of the box. 
I see several different ways to go in solving this problem:
1)Treat the whole frame buffer as the top level window and create SDL
windows that are embedded in it. That is, duplicate many of the
functions of a window manager in side SDL. This approach would allow SDL
applications to be portable across operating systems and devices. I’m
not sure how much code would be needed because I’m not sure how many new
functions would have to be added.
On the down side, this approach requires that the new API include
functions for manipulating the root window (functions that may not work
on windowing systems) or requires that we select a fixed background for
the root window. It also requires that we provide an SDL standard window
border and decorations for windows. I get really nervous about our
ability to make a decision about the look and feel of an SDL “window
manager”. But, I get even more nervous about the API and code bloat
involved in making all this stuff customizable by the application.
Perhaps we should only support borderless windows and make the
applications draw the border and window decorations allowing that part
of the problem to be pushed off onto a library rather than forcing the
code to reside in SDL.
-
Only allow a single top level window no matter what the underlying
system but support sub-windows on all systems. This approach can be
implemented on all devices and on devices with window managers it is
almost as flexible as having multiple top level windows. But, again, we
get into the problem of having to supply something like a window manager
inside of SDL with all the potential problems that that entails. -
Treat the multiple window API the same way we currently treat OpenGL.
If you aren’t on a system that supports OpenGL, you don’t get to use it.
So, we could limit the multiple window API to only work on systems with
a windowing system. -
I have also considered that on a frame buffer devices each top level
window could be a full screen window so that only one window and its
sub-windows visible at a time. This would be very much like option #2.
I would love to hear any suggestions, comments, or alternate approaches.
I am not particularly happy with any of these solutions. Solution #3 is
the easiest to implement. The other solutions all have pretty much the
same level of difficulty.
Bob Pendleton--
±-------------------------------------+
- Bob Pendleton: writer and programmer +
- email: Bob at Pendleton.com +
- web: www.GameProgrammer.com +
- www.Wise2Food.com +
- nutrient info on 6,000+ common foods +
±-------------------------------------+
