3) 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 think this is acceptable, so I vote for this one. We could always
add more complexity at a later date - if it’s proven to be required.
And that way we are not taking SDL in a direction that might not be
[Ryan C. Gordon]
Sometimes a framebuffer is just a framebuffer, and frankly, anyone
needing multiple windows is assuming you’re going to run it on
something with a real window manager.
Agreed. I think it’s certainly a good starting premise for an elegant solution.
Well, what I’m wondering is where multihead support fits into this?
(Though I’ve moved from a dual head setup to a single, huge display
myself, but anyway…)
I don’t know. I haven’t even thought about it. I don’t have any way to
work on it. So, for now, I am going to ignore it.
For what it’s worth, I think it’s important. It will also make
developing games with multi-monitor support much easier - through the
use of SDL.
However, I think the full-screen multi-monitor and multi-window
support API could easily be the same one.
How are you going to emulate a multi-monitor setup on a single-monitor
system then? No, SDL will need to support multiple windows on a single
monitor when running in windowed mode. As a backup. For running
multi-monitor programs on single-monitor computers.
I think this is a good idea.