Re: [AD] Menus and Callbacks

[Chris <chris.kcat@xxxxxxxxxx>]

On Tue, 09 Nov 2004 14:05:55 +0100, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> On Tue, 2004-11-09 at 00:05 -0800, Chris wrote:
> 
> 
> 
> > Well.. personally, what I would like to see in the new API is
> > something where you could load the DLL/.so durring runtime and still
> > have the same functionality as if you staticlinked or used a
> > dependancy DLL/.so (that's loaded at loadtime). I would also hope that
> > one could support both things with one DLL. AFAIK, the former is
> > possible as long as there's no global variables, though that obviously
> > means that we'd have to put the backwards compat stuff in a seperate
> > DLL or static lib.
> >
> 
> I like that idea. It wouldn't be that much different from libaldat for
> the static case. And the dynamic case could be just e.g. the GUI module
> or compatibility module in unix. Actually, if we change the Makefile a
> bit, the current modules could be linked into static libraries when they
> are not dynamic, instead of being linked into liballeg.a. So this could
> simply done with the existing modules mechanism.

What I mean is, making the core Allegro DLL (once the new API is
complete enough) able to be loaded durring program runtime, while the
old stuff is put into a seperate DLL (which can't be loaded at
runtime) or only staticlinkable. The user can get the address of the
new API functions as needed and them as normal, except he'd be using
self-supplied function pointers instead of the default funcstions as
Allegro has them.

So the user could decide to use a DLL dependancy or static lib and do:

#include <allegro.h>

main()
{
   al_init();
   ...
}

or as an optional DLL:

#include <allegrofunctypes.h>

AL_INIT_FUNC my_al_init;
...

main()
{
   loadlib("alleg");
   my_al_init = (AL_INIT_FUNC)get_function("al_init");
   ...

   my_al_init();
   ...
}

> > So I still think if we're going to redesign the API for it at all, we
> > should attempt to do so in a way that will match the rest of the new
> > API. This would mean no global variables (only functions), proper al_
> > prefixing, and a cleaned up/properly documented design. Adding extra
> > _ex members or functions is something I'd like to avoid where
> > possible.
> >
> 
> I agree. I meant the above for the current API - the only way to fix
> this two shortcomings in the menu code would be _ex functions.

But isn't that the point of the new API? To get over the shortcomings
over the current one? We have to stop trying to patchwork the current
API, nail-down the new one, and work on it. The new API won't complete
itself while we try to fix the current one. Especially if you guys
want 4.2 out in a month and a half, we can't be adding new things like
that.

> Let's
> hope we will design the new API well enough so we will never need _ex
> functions there :)

Not for a long while, anyway. :)

> Yes. Every MSG_DRAW could just trigger a user-provided callback, called
> right after the dialog proc returns from handling MSG_DRAW. The GUI
> procs currently never modify graphics outside their dialog rectangel, so
> this would work quite well. Things like scare_mouse_area even rely on
> this fact already.. so there should be no problems.

Sounds great. :)

> > In my mind what I see is... someone running the GUI in a secondary
> > thread, which draws to an off-screen buffer and has a callback
> > installed to blit to the game screen (which could be off-screen as
> > well) for the main program. The main program would take care of
> > re-blitting the parts of the GUI buffer whenever the game/app updates
> > the main screen so the output stays in sync. This would allow
> > asyncronous GUI usage along with the main program (which means the
> > GUI's frame rate would be completely independant from the game's, and
> > vice versa). If both the main buffer and the GUI buffer are video
> > bitmaps, and masked video blits are supported, you could get some
> > really wicked (as in cool) things going on, speed wise.
> >
> 
> I think the MSG_DRAW callback would work. The Allegro GUI keeps doings
> its logic of intermixed input processing and graphics updating, but
> every graphics update returns the dialog rectangle that was modified.. I
> like this a lot, I'll put experimenting with its on my TODO :)

Running the callback in object_message seems to be the best place as
it looks like all the dialog functions use that to send messages to
the individual dialog procedures.

> The user callback could just be, in the case you described above:
> 
> void my_draw_callback(DIALOG *d)
> {
>     blit (off_screen_buffer, game_buffer, d->x, d->y, d->x, d->y, d->w, d->h);
> }

More or less, yeah.

> > I'd probably go for a more basic Windows-like one. Nothing too flashy,
> > which fits in well with most other OS themes. Though I can't say I've
> > seen any AGUP themes myself.. any links?
> 
> Well, it has a windows-like one, which we could just use. I would
> actually have used the Photon one, since it looks best (IMHO). Or the
> GTK one, which is more OS-neutral than the windows one.

Hmm.. I do suppose the Photon one looks nice, but that'd be a real
bitch to get with Allegro's current scheme. The problem is that a
dialog procedure can only have two colors.. a foregound (text) and
background color. When you have gradients like that it becomes a bit
tricky.. especially if you'd want to use multiple gradiants. I think
the best ones to use would either be WIn95 or GTK, as those seem
simple enough to pull off with only two defineable colors.

> but the standard GUI theme really is ugly in any case.

Yes, which is probably one of the bigger reasons why it's so looked down upon.