Re: [AD] Windowing

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


"White, Ben" <ben.white@xxxxxxxxxx> writes:
> I'd like to see (read: prepared to cut code) support for windowing in
> Allegro

This is happening, both in Windows and X. In fact it already works in both 
places if you use the older standalone ports, and this support is currently 
in the middle of being merged into a single version.

> I guess this would involve receiving expose and resize events from the 
> window manager, and possibly focus/lost focus or activate/deactive 
> messages etc. 

I haven't thought about this in detail, but my gut reaction is that a 
windowed Allegro implementation should try to hide as much of that stuff as 
it possibly can. You should be able to use Allegro alongside your own 
windowing code if you want, but the default mode should be to pretend that 
the contents of the window work more like a fullscreen mode (fixed 
resolution, persistent surface memory, etc). This means that some level of 
double buffering is required, but that will usually end up being necessary 
in any case, and performance isn't really the issue here (it is the 
fullscreen modes where that is more crucial).

I would suggest that by default, set_gfx_mode() should just create a fixed 
size window and put the screen bitmap inside it. If you create video 
bitmaps, it opens up a new window for each one, but each window works pretty 
much as if it was a normal hardware screen in a non-windowed environment.

For the times when you want to work more closely with a native mode GUI, 
there can be hooks to attach the Allegro screen bitmap to an existing 
window, and to convert graphics between Allegro and native formats. The 
Windows version already has these things (see winalleg.h), and it would 
certainly be useful at some point to have similar platform specific routines 
that convert between bitmaps and X pixmap structures, but I think this is a 
special case type of operation, somewhat outside how the library normally 
behaves.

> Another thing I would like to work on is more direct support for X11 
> primitives.

Michael Bukin is actively working on the X code at the moment, so discuss 
the details with him. I suspect the best thing will probaby be just to wait 
until he has some runnable code, because it's difficult to have more than 
one person working on the same thing before there is anything solid to use 
as a basis for discussion, but that's really for Michael to say.

> Does anyone have any thoughts on this?  (even an API?) Or should I just 
> wait for 4.0 and work on that.

If you are interested in getting involved with the library development, you 
should follow along with the WIP releases and the discussions on this 
mailing list: that's where all the interesting things are happening. 4.0 is 
still a long way off, but we are gradually working towards it.



--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."



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