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