hi,
is it possible to open more than one window within an application using the sdl?
cheers, timo
No, I don’t think the feature is planned yet either. Why would you want
multiple windows?On Thu, Jan 04, 2001 at 02:16:56AM -0800, Timo Peichl wrote:
hi,
is it possible to open more than one window within an application using the sdl?
–
Martin
Bother said Pooh as he reached for the reset button.
hi,
is it possible to open more than one window within an application using the sdl?
cheers, timo
No… Bare in mind that many SDL targets (like fbcon, alib,
and svgalib) don’t have a concept of a window, so “opening
multiple windows” doesn’t make any sense… Since the goal
is to have sdl work pretty-much the same on all targets,
the ability to open mutilple windows with the current API
wouldn’t be a good thing.
The ideal way to do this [imho] would be to expose this in
the API as a property of a target’s video-capibilities,
(does a target support non-fullscreen operation?) and have
the abaility to go fullscreen either depricated, or disabled
when multiple SDL windows are open:
THEN
Have a thin windowing library that sits on top of SDL (that
allows nesting of sdl surface windows inside of sdl surface
windows, and so forth like on any windowing system. This
thin library could then, on systems with non-fullscreen
capibility, provide an option to not own the root window,
(whereby drawing to the root window was either ignored
or emulated on the windowing system’s background) and
all top-level windows of the root would be their own
windowing-system windows.
THE RESULT:
You could write an application for the thin windowing
library, and on targets that didn’t have a windowing
system, it would work fullscreen, while on windowing
system each top-level window would have it’s own window
(at least as an option)… with almost no application code
aware of the difference. Meanwhile, existing SDL code
would continue to work supporting both full-screen, and
windowed operation.
THE CHALLENGE
Although “thin windowing libraries” like I discussed have
been written (thousands of times over all around the world)
writing one is still no small task, and without one,
multi-windowed SDL apps would have to bend over backward
to work on fullscreen-only targets.
just my $0.02…
Best regards,
-Loren
…
Great news! Get free KNXmail here!
http://www.knx1070.com
Timo Peichl wrote:
is it possible to open more than one window within an application using the sdl?
I don’t know if thath could help you, but I have saw some example under
X
with only one SDL window and a Tk window or Gtk Window.
http://www.libsdl.org/projects/gtk-demo/index.html
http://www.libsdl.org/projects/tcl-demo/index.html
I hope that can help you.
charles
Thu, 04 Jan 2001 Martin Donlon wrote:
No, I don’t think the feature is planned yet either. Why would you want
multiple windows?
I don’t know what Timo is doing, but I’d consider it a useful feature when
using SDL for other things than games. Multimedia players, applications with RT
visualization windows, game development tools etc…
//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 -’
Thu, 04 Jan 2001 sondheim at knxmail.com wrote:
hi,
is it possible to open more than one window within an application using the sdl?
cheers, timo
No… Bare in mind that many SDL targets (like fbcon, alib,
and svgalib) don’t have a concept of a window, so “opening
multiple windows” doesn’t make any sense… Since the goal
is to have sdl work pretty-much the same on all targets,
the ability to open mutilple windows with the current API
wouldn’t be a good thing.
Good point, but I think SDL is too useful in windowed, non full screen
applications to ignore this possibility.
The ideal way to do this [imho] would be to expose this in
the API as a property of a target’s video-capibilities,
(does a target support non-fullscreen operation?) and have
the abaility to go fullscreen either depricated, or disabled
when multiple SDL windows are open:
Yes. (The information would be useful in some other cases as well. For
example, you don’t need custom window decorations in full screen mode, do
you…?)
THEN
Have a thin windowing library that sits on top of SDL (that
allows nesting of sdl surface windows inside of sdl surface
windows, and so forth like on any windowing system. This
thin library could then, on systems with non-fullscreen
capibility, provide an option to not own the root window,
(whereby drawing to the root window was either ignored
or emulated on the windowing system’s background) and
all top-level windows of the root would be their own
windowing-system windows.
I like that. 
THE RESULT:
You could write an application for the thin windowing
library, and on targets that didn’t have a windowing
system, it would work fullscreen, while on windowing
system each top-level window would have it’s own window
(at least as an option)… with almost no application code
aware of the difference. Meanwhile, existing SDL code
would continue to work supporting both full-screen, and
windowed operation.THE CHALLENGE
Although “thin windowing libraries” like I discussed have
been written (thousands of times over all around the world)
writing one is still no small task, and without one,
multi-windowed SDL apps would have to bend over backward
to work on fullscreen-only targets.
The “Default SDL Window Manager”…
Should be themable in one way or another to be of much use for serious work,
especially when dealing with games and other entertainment software. The
easiest way is probably to base the toolkit on “logical” widgets (ie widgets
that don’t render anything visually), and then allow applications to hook in
their own rendering code.
Of course, the custom window decorations could work in windowed mode as well,
by using borderless windows, and still use the SDL window manager.
THE CHALLENGE
Although “thin windowing libraries” like I discussed have
been written (thousands of times over all around the world)
writing one is still no small task, and without one,
multi-windowed SDL apps would have to bend over backward
to work on fullscreen-only targets.
Yep…
Is there any common (and preferably very thin) layer of functionality that most
of these libraries could use? Integrating that into SDL could save lots of work
and provide a wider choice of window managers, as opposed to hacking a new
window manager right into SDL.
Basic management of windows (just surfaces that are actually rectangular areas
on top of the root surface) should do, I think. (A window with SDL/application
rendered decorations would simply be a surface with a smaller surface on top of
it, representing the full window size and the client area, respectively.)
//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 -’
“David Olofson” <david.olofson at reologica.se> wrote in message
news:01010418581902.00833 at cutangle.reologica.se…
Thu, 04 Jan 2001 sondheim at knxmail.com wrote:
No… Bare in mind that many SDL targets (like fbcon, alib,
and svgalib) don’t have a concept of a window, so “opening
multiple windows” doesn’t make any sense… Since the goal
is to have sdl work pretty-much the same on all targets,
the ability to open mutilple windows with the current API
wouldn’t be a good thing.Good point, but I think SDL is too useful in windowed, non full screen
applications to ignore this possibility.
Even in full-screen environments, there is the possibility of a
multi-monitor setup. :-)–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
“David Olofson” <david.olofson at reologica.se> wrote in message
news:01010418581902.00833 at cutangle.reologica.se…Thu, 04 Jan 2001 sondheim at knxmail.com wrote:
No… Bare in mind that many SDL targets (like fbcon, alib,
and svgalib) don’t have a concept of a window, so “opening
multiple windows” doesn’t make any sense… Since the goal
is to have sdl work pretty-much the same on all targets,
the ability to open mutilple windows with the current API
wouldn’t be a good thing.Good point, but I think SDL is too useful in windowed, non full screen
applications to ignore this possibility.
Even in full-screen environments, there is the possibility of a
multi-monitor setup.
Yup, something that will definitely be looked at for SDL 1.3.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
THE CHALLENGE
Although “thin windowing libraries” like I discussed have
been written (thousands of times over all around the world)
writing one is still no small task, and without one,
multi-windowed SDL apps would have to bend over backward
to work on fullscreen-only targets.The “Default SDL Window Manager”…
Should be themable in one way or another to be of much use for serious work,
especially when dealing with games and other entertainment software. The
easiest way is probably to base the toolkit on “logical” widgets (ie widgets
that don’t render anything visually), and then allow applications to hook in
their own rendering code.Of course, the custom window decorations could work in windowed mode as well,
by using borderless windows, and still use the SDL window manager.THE CHALLENGE
Although “thin windowing libraries” like I discussed have
been written (thousands of times over all around the world)
writing one is still no small task, and without one,
multi-windowed SDL apps would have to bend over backward
to work on fullscreen-only targets.Yep…
Is there any common (and preferably very thin) layer of functionality that most
of these libraries could use? Integrating that into SDL could save lots of work
and provide a wider choice of window managers, as opposed to hacking a new
window manager right into SDL.Basic management of windows (just surfaces that are actually rectangular areas
on top of the root surface) should do, I think. (A window with SDL/application
rendered decorations would simply be a surface with a smaller surface on top of
it, representing the full window size and the client area, respectively.)//David
Well, I did mention on the sdl list several months ago that
I started work on such a library… actually a collection
of libraries, although I only got started on the first one.
What I envisioned was similar to the following:
[SDL (that we all know and love)]
^
|
[SDL thin windowing Library (basic nesting and clipping functionality)]
^ ^
| |
| [ Sample SDL window manager (API plus sample implementation)]
| ^
| |
[ GDK/GTK+ port to SDL (non-trivial, but would essentially allow GTK without a windowing system)]
anyway, I’m willing to post what source I have (probably
under LGPL) although it’s very pre-skeletal at the moment…
mostly some code to do boolean operations on rectangles…
but if someone wants to put in the time it could work out
to be something good…
comments?
-Loren
…
Great news! Get free KNXmail here!
http://www.knx1070.com
Thu, 04 Jan 2001 Rainer Deyke wrote:
“David Olofson” <david.olofson at reologica.se> wrote in message
news:01010418581902.00833 at cutangle.reologica.se…Thu, 04 Jan 2001 sondheim at knxmail.com wrote:
No… Bare in mind that many SDL targets (like fbcon, alib,
and svgalib) don’t have a concept of a window, so “opening
multiple windows” doesn’t make any sense… Since the goal
is to have sdl work pretty-much the same on all targets,
the ability to open mutilple windows with the current API
wouldn’t be a good thing.Good point, but I think SDL is too useful in windowed, non full screen
applications to ignore this possibility.Even in full-screen environments, there is the possibility of a
multi-monitor setup.
Yes indeed! I didn’t even think of that when I wrote that…
BTW, how about stereo display devices? Any support for those, what’s available
etc…? (I haven’t been all that interested in 3D and VR during the PC era, so
I haven’t kept track of the developments.)
The last arcade VR systems I read about used dual video cards and one real LCD
monitor per eye. Such a solution would require true multihead support all the
way from the application to the hardware, as there are two RAMDACs, two GPUs
and so on; ie rendering for both cards has to be done “simultaneously”,
probably in two threads… (I was thinking about something based on the double
buffering idea, but that won’t do if there’s more than one GPU.)
//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 -’
Fri, 05 Jan 2001 sondheim at knxmail.com wrote:
[…]
Is there any common (and preferably very thin) layer of functionality that most
of these libraries could use? Integrating that into SDL could save lots of work
and provide a wider choice of window managers, as opposed to hacking a new
window manager right into SDL.Basic management of windows (just surfaces that are actually rectangular areas
on top of the root surface) should do, I think. (A window with SDL/application
rendered decorations would simply be a surface with a smaller surface on top of
it, representing the full window size and the client area, respectively.)//David
Well, I did mention on the sdl list several months ago that
I started work on such a library… actually a collection
of libraries, although I only got started on the first one.
I kind of started in the other end; I have a simple linear framebuffer
rasterizing lib and very basic toolkit. (Designed the right way, but the
implementation… well, let’s just say I needed to get some visualization tools
working in short time. :-))
It currently runs on GGI (SDL port in progress), but there are some minor bugs,
and the windowing (IIRC) and some parts of the widget alignment system are
broken.
I’m playing with it every now and then, although it has rather low priority ATM.
What I envisioned was similar to the following:
[SDL (that we all know and love)]
^
|
[SDL thin windowing Library (basic nesting and clipping functionality)]
^ ^
| |
| [ Sample SDL window manager (API plus sample implementation)]
| ^
| |
[ GDK/GTK+ port to SDL (non-trivial, but would essentially allow GTK without a windowing system)]anyway, I’m willing to post what source I have (probably
under LGPL) although it’s very pre-skeletal at the moment…
mostly some code to do boolean operations on rectangles…
but if someone wants to put in the time it could work out
to be something good…comments?
Well, I don’t know if our design styles are compatible, but it’s possible that
we could get something together with some cut’n’paste work. I have
-
Very simple drawing lib with basic clipping, windows and
very simple bitmap text rendering. (This is where the SDL
port will help a lot - most of this should be replaced
with existing SDL libs.) -
Some basic widgets. (Built-in default theme; Win95-ish look.)
-
Simple but nice color scheme system for widgets. (You can select
color schemes on a per widget basis.) -
A design where all widgets have the same basic interface
and functionality, and where complex widgets (including
window decorations) are built from simpler widgets. -
Support for events “falling through” to underlying widgets.
(For widgets with irregular shapes.) -
Container oriented relative alignment system. (Partly broken
currently, but word wrap style stacking works at least… -
Mouse click routing. (Handles overlapping widgets such as windows
and menues. [Which are widgets as well…]) -
Focus management.
-
All pure C code. (Hopefully not too horrible WRT portability.)
Some things that I don’t have, but that would probably be nice for something
like a windowing system for games and other multimedia:
-
Advanced clipping. (No masking of overlapping drawing contexts.)
-
Irregular clipping regions. (Circular windows and the like.)
-
Translucent drawing contexts.
-
Alpha and other blending of drawing primitives.
-
Antialiasing.
-
Rendering using optimized/accelerated drawing primitives of
GGI, SDL, svgalib or other library. (It’s all CPU on linear
framebuffer. Makes things easier to port, though. -
Rendering into OpenGL textures. (Popup windows in OpenGL games.)
-
Support for rasterization using OpenGL. (Entire GUIs using OpenGL.)
-
A window manager. (A basic WM for full screen would be trivial
to implement using my widget set, but we also need to
cooperate with X/Windoze/Mac WMs and other stuff.)
I’ll release the code under the LGPL once I get the basic SDL port running, if
it could be of any use.
//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 -’