Re: [AD] Why multiple windows might suck

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Peter Wang wrote:

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

Like Bob, I disagree. Last week I tried (for about the first time) to
write a non-game with allegro, and immediately found out I needed
multiple windows. I'll immediately admit that the first extra window I
needed is a gui window (so GTK will do fine, and I'll probably use
just that) but I also want to use multiple graphics windows, for which
I use allegro.

> Ok.  Some examples would be nice.

The program I'm writing is an ocean dataset viewer (like ncview, look
at http://meteora.ucsd.edu/~pierce/ncview_home_page.html). It can
visualize sections of a 3 or 4D dataset, for example an ocean
temperature field. It needs a gui window for controls, and one or more
view windows to show different 'slices' of the dataset.

Other example: in adventure games it's often practical to be able to
separate 'inventory' windows and the likes from the main 'view'
window, so you can minimize them and use other neat tricks.

And just think of all the games (transport tycoon and the likes) that
use an internal windowing system. All such things could be done using
the OS.

> As for the 3d code, I think it's addon material :-)

Agreed.

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

I think this may be a working alternative, but I would greatly prefer
the windowing being a part of allegro. The reason why: allegro has a
beautifully simple api, and provided it stays about as simple, it's
much easier than having to learn a different API as well, like GTK.
Also, it removes the need to install such windowing systems, and
enables allegro to stay fully cross-platform by itself. I don't think
GTK is cross-platform across everything allegro supports (I'm not
looking at DOS), is it? That leaves wxwindows and qt, both of which
are C++ and the latter either has a much more restrictive license than
allegro, or is non-free. Apart from the problems of calling C++ from
C, it would force users to write C++, which was something we were
trying to prevent.

> 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?

I guess i'd propose a polling key() function, as was suggested when
the 4.1 discussion started. I can't quite see what problems would
arise with that though. 

A second option (if that's possible) would be to somehow 'reroute' the
keyboard input of all windows to a single key array, effectively
leaving things as they are now, but forcing the user to check which
window has the input focus before reading a key. (assuming a windowing
system will never let you press a key in 2 windows at once this should
work)

A third option could be (again, if technically possible) to make a
key[] array for each window, and to update the appropriate array when
a key is pressed in a window, non-polling. I think this one would be
the best, if it can be built.

Hein Zelle

>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<
 Hein Zelle                     hein@xxxxxxxxxx
	                        http://www.icce.rug.nl/~hein
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/