Re: [AD] Why multiple windows might suck

["Matthew Smith" <matt@xxxxxxxxxx>]

Me too I disagree.  I am writing non-games using entirely Allegro GUI.
I don't want to use external libraries like Gtk because they are not
available for DOS etc. and are GPL
I would like to be able to move toolbars, document windows, dialogs etc. out
of the main program window like many Windows programs can.  As this is not
possible on full-screen systems, the drawing code is all on Allegro bitmaps.
I do not want to rewrite this to use Gtk and/or WinAPI if I can help it.  I
would rather add extra windows and drive them through BITMAPS.   I will
attempt to do this myself eventually, starting with WinAPI as I know more
about that than any Linux system.  I can not make a consistent
cross-platform API for this by myself, unfortunately.

> 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.
>
Any MDI program, like PSP

>
> 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.
>
Yep GUI games have a place as much as full-screen ones


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

but this ties your code and resources into the external toolkit.

>
> 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.
>
This is easy enough. If you want to use multiple windows, then polling
discipline must be maintained.


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

In Windows at least, the main window (the first one opened) can trap all
keys so that others don't
receive them.  The main window can continue to do this even when one of it's
children has the focus.

> 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.
>
I wouldn't bother, given the above. A single key[] array will do.

Matt