Re: [AD] Why multiple windows might suck |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2002-02-24, Bob <ohannessian@xxxxxxxxxx> wrote:
>
> Playing the devil's advocate...
>
> Peter Wang wrote:
> [snip]
> > 1. Multiple windows showing only Allegro BITMAPs are relatively
> > useless, compared to attaching Allegro to GUI toolkits (GTK and the
> > like). I don't think many people will have a use for multiple
> > plain BITMAP windows.
>
> I disagree. The same can be said about just every feature in Allegro, appart
> from possibly blit(), which is used by the majority of users. Not many
> people use the 3D code. Not many people use the audio streams. And so on.
> Just because *you* don't use it doesn't make it less useful :)
Ok. Some examples would be nice.
Audiostreams are exactly what I would call a meta-mechanism --- people
build many different addons on top of them, things that we don't have
to put in the core library. I'd like to see more features like it.
As for the 3d code, I think it's addon material :-)
> Having Allegro BITMAPs attached to toolkits is a nice feature, and I can see
> it being useful; If we support that, then I don't see how much of a stretch
> it is to support multiple monitors or windows. Or am I missing something?
Attaching BITMAPs to toolkits is not hard at all. All they have to do
is share image data with the toolkit's widget, which requires only one
additional function call. It's already possible to do it in 4.0, if
you don't mind poking into undocumented territory.
(N.B. I did this with the Netscape plugin test, except that I made an
XImage share data with an Allegro BITMAP instead of the other way
around.)
> > 2. I think it would complicate the input system a lot. I can't see
> > asynchronously updated globals working well with multiple windows.
> > (See Eric's rationale for not polling.) It would probably also
> > complicate other things (e.g. the GUI system, if it remains).
>
> Just tag a BITMAP pointer along with the input. I did propose using a more
> light-wight "display" system, but Shawn disagreed.
If you mean things like int al_read_key(BITMAP **ret_input_source), I
don't like it because you have to filter everything at one point.
If you mean int al_read_key(BITMAP *input_source), then you're right,
but I'm talking about non-polling, such as the key[] array. What
would you propose for that in a multiple window environment?