[SDL] Re: Multiple SDL Windows?

[David Olofson]

On Friday 23 March 2001 05:16, Olivier Dagenais wrote:
> > To me, it's not just about DirectMedia. It's about using a nice, simple
> > and
> > portable API, and still having the choice to go full screen, use direct
> > video
> > APIs, OpenGL, not be restricted to a target with a windowing system etc,
> > while still having the choice of running like a "normal" application
> > under X,
> > Win32 GUI, Mac OS or whatever - preferably without rewriting my low level
> > libs a few times!
>
> The idea of multiple windows is mutually exclusive with the idea of running
> fullscreen.

So, it's motivated to interface your application with two different APIs to 
switch between fullscreen and windowed mode, even if both modes are based on 
the same higher level code, using the same graphics etc?

Some (well behaved) X and Windows applications support both panel/docking 
based operation as well as windowed operation, and I don't see why that 
wouldn't apply no games, game development tools and multimedia applications.


> The only way to make them work together is if when you go
> fullscreen you implement your own window manager and that's going out of
> scope of a library designed to port games.

Why should SDL implement the window manager? The required hooks are very 
simple and low level, and together with the advanced clipping mentioned by  
Mattias Engdegård some times would even make it behave like a real windowing 
system from the application POV.

The same API, as I picture it, would also be usable as a more structured 
alternative to changing the screen clip rect all the time when rendering into 
multiple views in games. The views would be almost totally independent, even 
if they are on the same physical surface in a full screen mode - and they 
could even overlap.


In short, it's about *using* features that are generally useful and are 
(probably, AFAIK) going in anyway, rather than adding new, totally unrelated 
features, as seems to be the way the "multiwindow opposers" like to think of 
it.


> I would recommend adding some 2D acceleration features to GUI libraries
> such as wxWindows, instead.

*heh* We're not talking about trivial hacks there. Besides, it would not work 
in fullscreen, not provide an SDL compatible API (without a great deal of 
work at least), would not port to all platforms supported by SDL etc...

I'd actually prefer working on one of the existing SDL based toolkits, or 
perhaps helping with the port of GTK+ (GDK, that is) to SDL. If that's done 
properly, we have a toolkit that's more or less guaranteed to work wherever 
SDL works, and that integrates nicely with SDL, whether we're doing 
fullscreen or multiwindow desktop based stuff.


> Besides, SDL is open-source so there's nothing
> stopping anybody from forking SDL and adding the features they want.

Well, yeah, but forking is not a good idea for such a small feature. (Which 
it is, unless something strange about SDL makes it virtually impossible to 
manage more than one screen surface by design...)

I think the below API should pretty much cover what we'd need in the main SDL 
tree to deal with all of this, including allowing third-party fullscreen mode 
window managers to be plugged in at run time:

---------------------------------------------------------------------------
SDL_Surface *SDL_CreateWindow(SDL_Surface *parent, SDL_Rect pos_size,
					int bpp, Uint32 flags);
	where "parent" is the parent surface, which may be any SDL surface
	including the screen/root surface, which is referred to as surface
	NULL. (The screen/root surface [NULL] is equivalent to the full
	screen on fullscreen only targets, and when the SDL_FULLSCREEN flag
	is set.) The "bpp" and "flags" arguments work similarly to those of
	SDL_SetVideoMode().


SDL_MoveWindow(SDL_Surface *window, SDL_Rect pos_size);
	Move and/or resize a window; be it a "real" window or a child window
	of any SDL surface.

SDL_FreeWindow(SDL_Surface *window);

SDL_InstallWM(SDL_Surface *root, SDL_WMHook *wmhook);
	where "root" is the surface that the installed WM is supposed to
	manage child windows for, and "wmhook" is a structure containing
	callback pointers (window creation hook, event hook, window
	freeing hook,...) and other info.

SDL_RemoveWM(SDL_WMHook *wmhook);
	Find and disconnect any instances of "wmhook" from the SDL core,
	so that the WM code can safely be unloaded. (Well, this may not
	make much sense unless there's going to be a generic library/DLL
	(un)loading system in 1.3+.)
---------------------------------------------------------------------------

(Well, I've probably missed a few details, but it's not like this is supposed 
to be a serious API proposal; I'll at least hack a prototype on to of current 
SDL before trying that. Not that I have time to do that... but I didn't 
really have time to play with the scrolling examples either. ;-)


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