Re: [AD] Menus and Callbacks

[Chris <chris.kcat@xxxxxxxxxx>]

On Tue, 09 Nov 2004 07:54:27 +0100, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> > In all honesty, I kind of like Allegro's GUI. The only problem is that
> 
> Me too. Except some small things on it, like the mentioned active_menu
> global. Another problem with the menus is, in gui_menu_draw_menu_item,
> you can't find out the parent menu (which makes proper theming
> impossible). I wonder if a menu->proc_ex and a
> gui_menu_draw_menu_item_ex would make sense.

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.

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.

> > it takes direct access to the screen (it doesn't allow for easy use of
> > double buffering or page flipping) and the default widget look is very
> 
> Hm, yes - could simply have a gui_screen, or a function
> show_gui(target_bitmap). (Completely synchronous access, splitting
> update_dialog into process_dialog and render_dialog, probably wouldn't
> work.)

Hmm.. I don't mind the idea of a target bitmap. So you could render
the GUI to a seperate bitmap that has the mask color for the
background and just masked_blit that as needed to the screen or
another buffer. Though we should probably add callback methods so the
user can know when something was updated and which part, so they're
not continuously masked_blit'ing the whole buffer every frame.

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.

> > bland. We could actually change how the default procedures look,
> > though.. AFAIK there's nothing stating what they look like.. as long
> > as they behave right.
> 
> Could use one of the basic AGUP themes.

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?