# Multiple SDL Windows again

**URL:** <https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331>\
**Category:** SDL Development\
**Created:** [April 26, 2001, 8:45am UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331 "2001-04-26T08:45:07Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![ANOQ\_of\_the\_Sun](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/a/ecccb3/32.png) [@ANOQ\_of\_the\_Sun](https://discourse.libsdl.org/u/ANOQ_of_the_Sun)\
**Post date:** [April 26, 2001, 8:45am UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/1 "2001-04-26T08:45:07Z")

</div>

Hello!

Earlier I heard rumors that SDL with support for multiple  
windows was to be done no earlier than SDL 1.3.  
And also:

Sam wrote:

> based on what we’ve learned over the past four years.  
> The architecture design is partially done, and we’ll start prototyping  
> the design soon. As soon as there’s a working framework, we’ll make it  
> publicly available for comment and contributions. This new framework  
> has about a year or a year and a half before we anticipate it being  
> ready for stable release. We anticipate this framework being the next  
> generation SDL 2.0 API.

But I would really really like to use multiple windows with SDL -  
so, if I implement it - will I just get flamed or will it end up  
in the current-generation public releases of SDL? 🙂

If I’m going to implement this I would go for the quick and  
dirty way:

\*) Allow SDL\_SetVideoMode to be called multiple times  
\*) Add a SDL\_CloseScreen function for an SDL\_Surface  
returned from SetVideoMode.  
\*) Only support it for non-fullscreen windows (i.e. desktop windows)  
\*) Possibly add / modify the necessary windowmanager functions.  
\*) Probably only implement it for Windows for now  
(and someone else currently have my X11-book too)

If there are any hints on where I should look  
in the code - I would love to know 🙂

## Cheers\> A: SDL 1.3 will be a near full rewrite of the SDL functionality,

> **[Hardcore Processing - Realize Your Wild Software Ideas Affordably](http://www.hardcoreprocessing.com)**

---

<div class="post-metadata">

**Author:** ![Mattias\_Engdegard](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/49beb7/32.png) [@Mattias\_Engdegard](https://discourse.libsdl.org/u/Mattias_Engdegard)\
**Post date:** [April 26, 2001, 9:10am UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/2 "2001-04-26T09:10:57Z")

</div>

> But I would really really like to use multiple windows with SDL -  
> so, if I implement it - will I just get flamed or will it end up  
> in the current-generation public releases of SDL? 🙂

it’s not a question of implementation, anyone can do that. it’s a question  
of design

It sounds like you really don’t want to use SDL, since SDL is an  
abstraction layer for a framebuffer. A windowing user-interface toolkit  
like gtk or qt would probably serve you much better. You can also use a  
separate process for each window

---

<div class="post-metadata">

**Author:** ![Xavier\_Le\_Pasteur](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/x/eada6e/32.png) [@Xavier\_Le\_Pasteur](https://discourse.libsdl.org/u/Xavier_Le_Pasteur)\
**Post date:** [April 26, 2001, 10:31am UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/3 "2001-04-26T10:31:03Z")

</div>

However, will you support multiple SDL windows in SDL 1.3 as  
rumored or not ?

Personnaly I prefer that you kept the concept of the framebuffer  
and kept SDL with a single window through the further SDL versions…–

Xavier Le Pasteur  
@Xavier_Le_Pasteur

> > But I would really really like to use multiple windows with SDL -  
> > so, if I implement it - will I just get flamed or will it end up  
> > in the current-generation public releases of SDL? 🙂
> 
> it’s not a question of implementation, anyone can do that. it’s a question  
> of design
> 
> It sounds like you really don’t want to use SDL, since SDL is an  
> abstraction layer for a framebuffer. A windowing user-interface toolkit  
> like gtk or qt would probably serve you much better. You can also use a  
> separate process for each window

---

<div class="post-metadata">

**Author:** ![Sam\_Hart](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/d26b3c/32.png) [@Sam\_Hart](https://discourse.libsdl.org/u/Sam_Hart)\
**Post date:** [April 26, 2001, 4:02pm UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/4 "2001-04-26T16:02:44Z")

</div>

> Earlier I heard rumors that SDL with support for multiple  
> windows was to be done no earlier than SDL 1.3.  
>   
> If I’m going to implement this I would go for the quick and  
> dirty way:
> 
> \*) Allow SDL\_SetVideoMode to be called multiple times  
> \*) Add a SDL\_CloseScreen function for an SDL\_Surface  
> returned from SetVideoMode.  
> \*) Only support it for non-fullscreen windows (i.e. desktop windows)  
> \*) Possibly add / modify the necessary windowmanager functions.  
> \*) Probably only implement it for Windows for now  
> (and someone else currently have my X11-book too)

You can already do multiple non-fullscreen (desktop) windows using SDL using  
simple IPC. I wrote an example of this a bit ago, and I know it works in POSIX  
environments (I’m sure, with tweaking, you should be able to do the same in  
non-POSIX environments).

My example can be found on my demo page (it’s the first SDL example listed):  
[http://www.geekcomix.com/snh/files/demos/](http://www.geekcomix.com/snh/files/demos/)

Now being able to do multiple /fullscreen/ windows (i.e., some sort of multiple  
window ports within a single surface, without worrying having to impliment  
yourself using multiple surfaces) would be very useful IMHO, especially in  
non-windowmanagement environments (such as the linux framebuffer ;-)On Thu, 26 Apr 2001, you wrote:

–  
Sam “Criswell” Hart \<@Sam\_Hart\> AIM, Yahoo!:   
Homepage: \< [http://www.geekcomix.com/snh/](http://www.geekcomix.com/snh/) \>  
PGP Info: \< [http://www.geekcomix.com/snh/contact/](http://www.geekcomix.com/snh/contact/) \>  
Advogato: \< [http://advogato.org/person/criswell/](http://advogato.org/person/criswell/) \>

---

<div class="post-metadata">

**Author:** ![slouken](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/ec9cab/32.png) [@slouken](https://discourse.libsdl.org/u/slouken)\
**Post date:** [April 26, 2001, 4:16pm UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/5 "2001-04-26T16:16:53Z")

</div>

> However, will you support multiple SDL windows in SDL 1.3 as  
> rumored or not ?

> Personnaly I prefer that you kept the concept of the framebuffer  
> and kept SDL with a single window through the further SDL versions…

SDL 1.3 will support multiple windows as a natural extension of  
multi-head support.

See ya,  
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

---

<div class="post-metadata">

**Author:** ![icculus](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/icculus/32/81_2.png) [@icculus](https://discourse.libsdl.org/u/icculus)\
**Post date:** [April 26, 2001, 8:47pm UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/6 "2001-04-26T20:47:24Z")

</div>

> If I’m going to implement this I would go for the quick and  
> dirty way:
> 
> \*) Allow SDL\_SetVideoMode to be called multiple times

This breaks a LOT of programs that use SDL\_SetVideoMode() multiple times  
to switch video modes/resolutions/window sizes, and assume the old window  
is going away to make way for the new.

–ryan.

---

<div class="post-metadata">

**Author:** ![Lloyd\_Dupont](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/l/f4b2a3/32.png) [@Lloyd\_Dupont](https://discourse.libsdl.org/u/Lloyd_Dupont)\
**Post date:** [April 26, 2001, 7:01pm UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/7 "2001-04-26T19:01:50Z")

</div>

may be they want multiple windows in WindowServer meaning !!!  
wich can be nested…  
and have OpenGL inside a a non-OpenGL window…

---

<div class="post-metadata">

**Author:** ![ANOQ\_of\_the\_Sun](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/a/ecccb3/32.png) [@ANOQ\_of\_the\_Sun](https://discourse.libsdl.org/u/ANOQ_of_the_Sun)\
**Post date:** [April 27, 2001, 4:37pm UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/8 "2001-04-27T16:37:29Z")

</div>

Mattias Engdeg?rd wrote:

> it’s not a question of implementation, anyone can do that. it’s a question  
> of design
> 
> It sounds like you really don’t want to use SDL, since SDL is an  
> abstraction layer for a framebuffer. A windowing user-interface toolkit  
> like gtk or qt would probably serve you much better. You can also use a  
> separate process for each window

Xavier Le Pasteur wrote:

> Personnaly I prefer that you kept the concept of the framebuffer  
> and kept SDL with a single window through the further SDL versions…

Samuel Hart wrote:

> You can already do multiple non-fullscreen (desktop) windows using SDL using  
> simple IPC. I wrote an example of this a bit ago, and I know it works in POSIX  
> environments (I’m sure, with tweaking, you should be able to do the same in  
> non-POSIX environments).

Well - I didn’t mean to bring up the old discussion again, but…

\*) Yes I do want to use SDL - so that I can have graphics in a  
crossplatform way.  
\*) No I don’t want to use a UI-toolkit - I want to write one…  
\*) Using IPC for every single popup menu, tooltip etc. is not a good  
option.

“Ryan C. Gordon” wrote:

> This breaks a LOT of programs that use SDL\_SetVideoMode() multiple times  
> to switch video modes/resolutions/window sizes, and assume the old window  
> is going away to make way for the new.

\*) OK - so I will just have to add a flag - like  
SDL\_EXTRASCREEN or something.

But it seems that I’m getting flamed for this already…  
but I would really really like to have this feature ASAP 🙂

Cheers–  
[http://www.HardcoreProcessing.com](http://www.HardcoreProcessing.com)

---

<div class="post-metadata">

**Author:** ![David\_Hedbor](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_hedbor/32/2440_2.png) [@David\_Hedbor](https://discourse.libsdl.org/u/David_Hedbor)\
**Post date:** [April 27, 2001, 5:16pm UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/9 "2001-04-27T17:16:08Z")

</div>

Anoq of the Sun writes:

> \*) No I don’t want to use a UI-toolkit - I want to write one…  
> \*) Using IPC for every single popup menu, tooltip etc. is not a good  
> option.

Why on earth would you have a single SDL screen for each popup menu  
and what not? Windows etc would be surfaces, but not screens. Just  
create a surface for each thing you need and blit it upon the actual screen.–  
[Below is a random fortune, which is unrelated to the above message.]  
Don’t get even – get odd!

---

<div class="post-metadata">

**Author:** ![ANOQ\_of\_the\_Sun](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/a/ecccb3/32.png) [@ANOQ\_of\_the\_Sun](https://discourse.libsdl.org/u/ANOQ_of_the_Sun)\
**Post date:** [April 28, 2001, 3:23pm UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/10 "2001-04-28T15:23:03Z")

</div>

David Hedbor wrote:

> Why on earth would you have a single SDL screen for each popup menu  
> and what not? Windows etc would be surfaces, but not screens. Just  
> create a surface for each thing you need and blit it upon the actual screen.

Well, in many cases this would be OK - but only until the  
popup menus get sufficiently big so that they have to  
extend beyond the borders of the window - or if, say,  
the window is at the bottom of the screen and you  
need to popup the menu upwards instead of downwards  
to be able to see it. So the only solution which is  
general enough is a new window for each popup-menu…

and then comes all the problems with save-unders  
for efficiency etc. - so maybe some day I will need  
to add flags for that to SDL too… but I think this  
would also be a good thing to have control over in SDL  
anyway.

“Ryan C. Gordon” wrote:

> I’m not flaming you…I just wanted you to be aware of what existing  
> programs do. If you implement it, that’d be cool.

OK - maybe I sounded too harsh - sorry - I didn’t mean to.  
And I know that your point was very relevant 🙂  
But I hope the SDL\_EXTRASCREEN flag would be adequate  
for solving the problem.

But is the solution I’m talking about “accepted”  
as something worthy to be put into the official  
releases? Sam?

Cheers–  
[http://www.HardcoreProcessing.com](http://www.HardcoreProcessing.com)

---

<div class="post-metadata">

**Author:** ![slouken](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/ec9cab/32.png) [@slouken](https://discourse.libsdl.org/u/slouken)\
**Post date:** [April 28, 2001, 3:42pm UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/11 "2001-04-28T15:42:09Z")

</div>

> But is the solution I’m talking about “accepted”  
> as something worthy to be put into the official  
> releases? Sam?

SDL will never be designed to function as a UI toolkit. The multiple  
window support will be designed for the general multi-head case.  
However, SDL does and will integrate with other GUI toolkits, like  
GTk and Qt, which provide the kind of functionality you desire.

You are welcome to hack the support you want into SDL and distribute  
the modified version with your program. If it works well, I’ll look  
at it when implementing multi-window support in SDL 1.3.

See ya,  
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

---

<div class="post-metadata">

**Author:** ![David\_Snopek](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/d/b782af/32.png) [@David\_Snopek](https://discourse.libsdl.org/u/David_Snopek)\
**Post date:** [April 28, 2001, 4:32pm UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/12 "2001-04-28T16:32:42Z")

</div>

Anoq of the Sun wrote:

> David Hedbor wrote:
> 
> > Why on earth would you have a single SDL screen for each popup menu  
> > and what not? Windows etc would be surfaces, but not screens. Just  
> > create a surface for each thing you need and blit it upon the actual screen.
> 
> Well, in many cases this would be OK - but only until the  
> popup menus get sufficiently big so that they have to  
> extend beyond the borders of the window - or if, say,  
> the window is at the bottom of the screen and you  
> need to popup the menu upwards instead of downwards  
> to be able to see it. So the only solution which is  
> general enough is a new window for each popup-menu…

This can’t be how real GUI’s do it!?! That just sounds so wasteful to  
me. Maybe it would be better to hack in support for drawing to the root  
window so you can draw past the window borders??

```
-- David Snopek

```

/-- libksd –  
| The C++ Cross-Platform Game Framework  
| Only want to write it once??  
| [http://libksd.sourceforge.net](http://libksd.sourceforge.net)  
------------

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [April 29, 2001, 6:14am UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/13 "2001-04-29T06:14:43Z")

</div>

> Anoq of the Sun wrote:
> 
> > David Hedbor wrote:
> > 
> > > Why on earth would you have a single SDL screen for each popup menu  
> > > and what not? Windows etc would be surfaces, but not screens. Just  
> > > create a surface for each thing you need and blit it upon the actual  
> > > screen.
> > 
> > Well, in many cases this would be OK - but only until the  
> > popup menus get sufficiently big so that they have to  
> > extend beyond the borders of the window - or if, say,  
> > the window is at the bottom of the screen and you  
> > need to popup the menu upwards instead of downwards  
> > to be able to see it. So the only solution which is  
> > general enough is a new window for each popup-menu…
> 
> This can’t be how real GUI’s do it!?! That just sounds so wasteful to  
> me.

Wasteful or not; that _is_ how most toolkits do it, as there is no other way  
of rendering outside a window… And it’s not really that bad, if implemented  
properly. Have a look at SDL’s clipping, add some window management  
functionality to keep track of dirty areas, and you get the idea.

> Maybe it would be better to hack in support for drawing to the root  
> window so you can draw past the window borders??

Well, yeah, you _can_ do that on some targets (like X and Windows), but

```
1) You still cannot render on top of other windows on some
   targets; only on the background/root window - which is *not*
   the same thing as the Win32 HDC 0 "window".

2) Who are you going to ask to restore the previous
   background afterwards?

3) You can't save the background yourself either, as that may
   break anything that's going on in the background.

4) You can't prevent other applications from overdrawing your
   menu without you knowing about it.

```

Of course, all that can be fixed with proper support from the rendering  
target. That support exists, and is provided in the form of an abstraction  
called a “window”. 😉

//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](http://linuxdj.com) -'On Saturday 28 April 2001 18:32, David Snopek wrote:

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [April 29, 2001, 6:24am UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/14 "2001-04-29T06:24:21Z")

</div>

That method forces you to use the dreaded MDI style design - an annoying GUI  
design style that was invented in the dark (pre-multitasking) ages, and for  
some reason is still utilized on some platforms, probably because it can make  
the screen layout slightly less confusing to absolute beginners… 🙂

As to menues, it makes the larger ones useless, unless you’re effectivey  
running the application in full screen size, which makes the use of windowed  
somewhat pointless in the first place.

//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](http://linuxdj.com) -'On Friday 27 April 2001 19:16, David Hedbor wrote:

> Anoq of the Sun writes:
> 
> > \*) No I don’t want to use a UI-toolkit - I want to write one…  
> > \*) Using IPC for every single popup menu, tooltip etc. is not a good  
> > option.
> 
> Why on earth would you have a single SDL screen for each popup menu  
> and what not? Windows etc would be surfaces, but not screens. Just  
> create a surface for each thing you need and blit it upon the actual  
> screen.

---

<div class="post-metadata">

**Author:** ![icculus](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/icculus/32/81_2.png) [@icculus](https://discourse.libsdl.org/u/icculus)\
**Post date:** [April 29, 2001, 11:47pm UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/15 "2001-04-29T23:47:56Z")

</div>

> > This can’t be how real GUI’s do it!?! That just sounds so wasteful to  
> > me.
> 
> Wasteful or not; that _is_ how most toolkits do it, as there is no other way  
> of rendering outside a window… And it’s not really that bad, if implemented  
> properly. Have a look at SDL’s clipping, add some window management  
> functionality to keep track of dirty areas, and you get the idea.

This isn’t really how most GUIs do it.

(Generally speaking) At the windowing system level, there is an abstract  
concept of a “window”, which isn’t nearly as resource intensive as, say,  
an Xterm or Netscape’s “window,” which are comprised of several  
windowing system windows.

Different systems call these different things: controls, components,  
widgets. They are, individually, designed for piling next to and on top of  
each other in large quantities. They each get individual events  
(mouseovers, etc), and their rendering doesn’t overwrite the graphical  
contents of any other overlapping widgets.

An SDL window is much, much heavier than one of these, as it is already a  
collection of widgets (titlebar, maximize button, surface, etc). Each SDL  
window gets it’s own events and handles it’s own redraw, but in terms of a  
UI toolkit, this is accidental.

Just wanted to make that distinction. See my next post about using SDL for  
a ui toolkit.

–ryan.

---

<div class="post-metadata">

**Author:** ![icculus](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/icculus/32/81_2.png) [@icculus](https://discourse.libsdl.org/u/icculus)\
**Post date:** [April 29, 2001, 11:59pm UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/16 "2001-04-29T23:59:05Z")

</div>

> Well, in many cases this would be OK - but only until the  
> popup menus get sufficiently big so that they have to  
> extend beyond the borders of the window - or if, say,  
> the window is at the bottom of the screen and you  
> need to popup the menu upwards instead of downwards  
> to be able to see it. So the only solution which is  
> general enough is a new window for each popup-menu…

Assuming that the EXTRAWINDOW flag is a viable approach to extending SDL  
(I’ll leave that to Sam to comment upon), then what you would want to do  
is something like how Java’s Swing class does it.

You have a few HEAVYWEIGHT windows: top level, framed windows, popups and  
pulldown menus, etc. Each of these is a SDL surface created with this  
hypothetical EXTRAWINDOW flag.

Every thing else is a LIGHTWEIGHT window. They can be offscreen surfaces,  
or whatever, but their only physical representation is when it is rendered  
inside a heavyweight window. This means you need to manage rendering  
overlap of lightweights, and catch mouse/keyboard/etc events on the  
heavyweight and see that they make it to the correct lightweight  
component.

This IS doable. With something like EXTRAWINDOW, it could even be done  
with SDL.

The question though, is what would be the worth? There are UI kits for SDL  
(although they don’t allow popups past the edge of the screen surface,  
etc) if you just want some basic UI functionality. There are portable  
solutions (gtk, Qt, wxWindows, Swing) if you want that.

If you just want to tinker, the heavyweight/lightweight approach would be  
fun to code, but would be a lot of work for (again) something of less  
pratical value than it should be worth.

(_shrug_)

–ryan.

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [April 30, 2001, 8:28am UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/17 "2001-04-30T08:28:31Z")

</div>

> > > This can’t be how real GUI’s do it!?! That just sounds so wasteful to  
> > > me.
> > 
> > Wasteful or not; that _is_ how most toolkits do it, as there is no other  
> > way of rendering outside a window… And it’s not really that bad, if  
> > implemented properly. Have a look at SDL’s clipping, add some window  
> > management functionality to keep track of dirty areas, and you get the  
> > idea.
> 
> This isn’t really how most GUIs do it.
> 
> (Generally speaking) At the windowing system level, there is an abstract  
> concept of a “window”, which isn’t nearly as resource intensive as, say,  
> an Xterm or Netscape’s “window,” which are comprised of several  
> windowing system windows.

I was thinking in rendering terms, and I was taking for granted that no one  
was talking of “real” windows. (With title bar, borders etc.)

> Different systems call these different things: controls, components,  
> widgets. They are, individually, designed for piling next to and on top of  
> each other in large quantities. They each get individual events  
> (mouseovers, etc), and their rendering doesn’t overwrite the graphical  
> contents of any other overlapping widgets.
> 
> An SDL window is much, much heavier than one of these, as it is already a  
> collection of widgets (titlebar, maximize button, surface, etc). Each SDL  
> window gets it’s own events and handles it’s own redraw, but in terms of a  
> UI toolkit, this is accidental.

Right; as SDL looks now, the closest you can get is a borderless window.  
However, whether or not that’s heavier than a “low level window” (or drawing  
context, or whatever targets call it) depends on the implementation… The  
SDL\_Surface abstraction would be very similar for “real” windows and the low  
level ones.

//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](http://linuxdj.com) -'On Monday 30 April 2001 01:47, Ryan C. Gordon wrote:

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [April 30, 2001, 8:46am UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/18 "2001-04-30T08:46:23Z")

</div>

> > Well, in many cases this would be OK - but only until the  
> > popup menus get sufficiently big so that they have to  
> > extend beyond the borders of the window - or if, say,  
> > the window is at the bottom of the screen and you  
> > need to popup the menu upwards instead of downwards  
> > to be able to see it. So the only solution which is  
> > general enough is a new window for each popup-menu…
> 
> Assuming that the EXTRAWINDOW flag is a viable approach to extending SDL  
> (I’ll leave that to Sam to comment upon), then what you would want to do  
> is something like how Java’s Swing class does it.
> 
> You have a few HEAVYWEIGHT windows: top level, framed windows, popups and  
> pulldown menus, etc. Each of these is a SDL surface created with this  
> hypothetical EXTRAWINDOW flag.
> 
> Every thing else is a LIGHTWEIGHT window. They can be offscreen surfaces,  
> or whatever, but their only physical representation is when it is rendered  
> inside a heavyweight window. This means you need to manage rendering  
> overlap of lightweights, and catch mouse/keyboard/etc events on the  
> heavyweight and see that they make it to the correct lightweight  
> component.
> 
> This IS doable. With something like EXTRAWINDOW, it could even be done  
> with SDL.

This is exactly the approach I was talking about some time ago, although with  
different terminology.

> The question though, is what would be the worth? There are UI kits for SDL  
> (although they don’t allow popups past the edge of the screen surface,  
> etc) if you just want some basic UI functionality. There are portable  
> solutions (gtk, Qt, wxWindows, Swing) if you want that.

If you want to use widgets integrated with the SDL display when in fullscreen  
mode, and in separate windows when in windowed mode, you have to use at least  
two toolkits on most platforms - and probably more if you want to support  
more than one platform. At that point, it can almost be viable to hack a  
custom toolkit, if it solves that problem… _heh_

> If you just want to tinker, the heavyweight/lightweight approach would be  
> fun to code, but would be a lot of work for (again) something of less  
> pratical value than it should be worth.

OTOH, if SDL 2.0 is going to have “advanced clipping”, the lightweight  
windows are almost there already, except for the event dispatching part.  
(IMHO, that part should be managed by the toolkit for maximum flexibility.  
Hardcoding it into the SDL event system doesn’t make much sense, as it’s the  
toolkit that should decide how mouse capture, keyboard focus etc is handled.)

Lightweight windows could be presented as a structured alternative to  
changing the cliprect, also handling overlapping correctly. It might even be  
possible to implement that as an optional low level window manager library,  
that just uses the advanced clipping features in a more structured way than  
just building raw clipping regions directly.

As to the heavyweight part; I don’t know what the SDL 2.0 API will look like,  
but it seems reasonable that supporting multiple windows on windowed targets  
would be an almost free bonus as soon as the fullscreen multihead, stereo,…  
stuff is in place.

//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](http://linuxdj.com) -'On Monday 30 April 2001 01:59, Ryan C. Gordon wrote:

---

<div class="post-metadata">

**Author:** ![ANOQ\_of\_the\_Sun](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/a/ecccb3/32.png) [@ANOQ\_of\_the\_Sun](https://discourse.libsdl.org/u/ANOQ_of_the_Sun)\
**Post date:** [May 11, 2001, 6:28pm UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/19 "2001-05-11T18:28:14Z")

</div>

“Ryan C. Gordon” wrote:

> Assuming that the EXTRAWINDOW flag is a viable approach to extending SDL  
> (I’ll leave that to Sam to comment upon), then what you would want to do  
> is something like how Java’s Swing class does it.
> 
> You have a few HEAVYWEIGHT windows: top level, framed windows, popups and  
> pulldown menus, etc. Each of these is a SDL surface created with this  
> hypothetical EXTRAWINDOW flag.
> 
> Every thing else is a LIGHTWEIGHT window. They can be offscreen surfaces,  
> or whatever, …

This heavyweight versus lightweight thing sounds pretty  
nice - but as I see it right now, an SDL\_Surface is  
a “lightweight” window (it can also be offscreen etc.  
if you use SDL\_AllocSurface etc.). If however the  
surface was created with SDL\_SetVideoMode, then  
it will be a physical window too - like a “heavyweight”  
one…

But regarding the multiple window support in SDL -  
the current design of the eventsystem in SDL doesn’t  
support events to be dispatched to different windows -  
I’m thinking especially of mouseevents here.  
How would you know in which window a mouse move  
(or whatever) event actually occurred?

So, I’m thinking of another approach of doing this…

Add some functions to SDL that allows it to work  
with / co-exist with the native backend of the  
OS. I know it’s ugly and platformdependent etc. -  
but it would really be useful in many cases.

(also, see the post of  
“Raw Nerves” ,  
subject: “win32 API for an SDL window application.”).

And it means that you have access to anything  
that you would otherwise have in the native  
OS that you’re using! Esentially making sure  
that there are no “limitations” to using SDL…  
In a sense, it would make SDL more “open”.

I would, however, only be insterested in ( = have time  
for) implementing a win32 version of this feature -  
at least for now.

You would probably only need a few functions  
to “assign” an SDL\_Surface to a native window -  
and vice versa. Of couse it must be convenient  
to do this so that you retain framebuffer formats  
etc.

With something like this (assuming that somebody  
eventually writes something similar for all supported  
OS’es) - people could make extra separate libraries  
for SDL with as many weird OS-specific features as  
desired and with support for as many platforms as  
time / possibilities permit.

I don’t know when / if I’ll have time to hack  
something like this up - but at some point I might  
just do it and call it a “suggestion for new features” 🙂  
Any comments are most welcome though 🙂

Cheers–  
[http://www.HardcoreProcessing.com](http://www.HardcoreProcessing.com)

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [May 11, 2001, 10:09pm UTC](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331/20 "2001-05-11T22:09:22Z")

</div>

[…]

> But regarding the multiple window support in SDL -  
> the current design of the eventsystem in SDL doesn’t  
> support events to be dispatched to different windows -  
> I’m thinking especially of mouseevents here.  
> How would you know in which window a mouse move  
> (or whatever) event actually occurred?

Yeah… However, it’s not as simple as “send all events to the window under  
the mouse pointer…”

The usual solution seems to be to add the concepts “focused window”, “mouse  
capture” and a few other, rather simple “filters”, and then provide an API  
for that, for toolkits and to some extent, applications, to use. Every window  
would have some kind of “event port”.

Idea: If a window isn’t equipped with an event port, the events can fall  
through to it’s parent, or something… Would make it possible to use the  
same window abstraction like a more lightweight overlapping + clipping  
rendering control primitive; an advanced cliprect object.

> So, I’m thinking of another approach of doing this…
> 
> Add some functions to SDL that allows it to work  
> with / co-exist with the native backend of the  
> OS. I know it’s ugly and platformdependent etc. -  
> but it would really be useful in many cases.
> 
> (also, see the post of  
> “Raw Nerves” ,  
> subject: “win32 API for an SDL window application.”).
> 
> And it means that you have access to anything  
> that you would otherwise have in the native  
> OS that you’re using! Esentially making sure  
> that there are no “limitations” to using SDL…  
> In a sense, it would make SDL more “open”.
> 
> I would, however, only be insterested in ( = have time  
> for) implementing a win32 version of this feature -  
> at least for now.
> 
> You would probably only need a few functions  
> to “assign” an SDL\_Surface to a native window -  
> and vice versa. Of couse it must be convenient  
> to do this so that you retain framebuffer formats  
> etc.

I don’t see how this could be done using a portable API…

> With something like this (assuming that somebody  
> eventually writes something similar for all supported  
> OS’es) - people could make extra separate libraries  
> for SDL with as many weird OS-specific features as  
> desired and with support for as many platforms as  
> time / possibilities permit.

…then again, that might not be the point? It does make some sense to build  
some low level hooks into SDL, but I’m not sure it makes much sense to this  
low a level.

Considering that there already are things like flags for borderless windows,  
fullscreen mode etc, it sounds like supporting multiple screen surfaces is  
just another step - which could be extended with some way of snapping in  
window managers for fullscreen modes and that kind of stuff. (In that case,  
the fullscreen window manager would do the event dispatching, pretty much  
like the target’s WM does with “normal” windows. No difference for SDL  
applications.)

It would be logical that these fullscreen window managers would show up  
behind the existing window manager API, of course. In fact, the current SDL  
WM code could probably use the same “plugin” API as the fullscreen window  
managers.

It might be a good idea to make sure that “WM inside WM” is possible, though.  
Most importantly, that would allow a custom WM to be used inside a normal  
window on windowed target.

> I don’t know when / if I’ll have time to hack  
> something like this up - but at some point I might  
> just do it and call it a “suggestion for new features” 🙂  
> Any comments are most welcome though 🙂

Well, you got some above. 🙂

BTW, note that I’m thinking in terms of what may make sense for SDL 1.3, but  
might be messy to hack into 1.2. Without multiple screen surface support and  
complex region clipping, only half of the features can be done right… And  
why mess with it if it’s going to be done right anyway? 🙂

It’s probably possible to come up with some shortcut, but I’m failing to see  
one that both provides something truly useful, and is still clean and  
portable…

//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](http://linuxdj.com) -'On Friday 11 May 2001 20:28, Anoq of the Sun wrote:

[Next page](https://discourse.libsdl.org/t/multiple-sdl-windows-again/4331.md?page=2)