[SDL] Re: Multiple SDL Windows again...

David Olofson david.olofson at reologica.se
Mon Apr 30 01:46:23 PDT 2001

On Monday 30 April 2001 01:59, Ryan C. Gordon wrote:
> > 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.


.- 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 -'

More information about the SDL mailing list