Re: [AD] Adding a d_subdialog_proc |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] Adding a d_subdialog_proc
- From: Elias Pschernig <allefant@xxxxxxxxxx>
- Date: Sun, 17 Oct 2004 18:43:20 +0200
- Domainkey-signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=lnfXcBgdBGyBXaAYZKh1lDvUyCTPOVw4xA0jTy5GhsyIbsUYfz1x3D0G7CIdRE2Ys+08X7EHOpT9Yzgez00bGmgsQ6MQPlqvE1NdWVBchsDqOCuaCOlLbfPUJH9bcOD3IIBVu30jLcJ+aCT69qfNasfnn5ZP8D4JBv8EUUSRE9M
Hm, I already sent this yesterday, but doesn't seem to have come thorugh
---------- Forwarded message ----------
From: Elias Pschernig <allefant@xxxxxxxxxx>
Date: Sat, 16 Oct 2004 21:18:32 +0200
Subject: Re: [AD] Adding a d_subdialog_proc
To: alleg-developers@xxxxxxxxxx
> I don't know what the general feeling towards the Allegro GUI is right now,
> but I'd like to propose a d_subdialog_proc addition to it. This would
> basically allow users to add one to their DIALOGs, with the dp pointer
> pointing to a DIALOG* (in otherwords, dp is a DIALOG**, not a DIALOG*, but
> either way would work)
>
Well, the general problem with the GUI is.. on one side, it is very
limited, and somehow it feels like it shouldn't be part of the core
lib. And especially, no more new dialog types should be added which
can live in addons (and there are like 10-20 Allegro-GUI addons
available, e.g. the ones at
http://awiki.tomasu.com/bin/view/Main/AllegroGUI)
On the other hand, sub dialogs would be really useful, and the GUI
code certainly is not dead, it was very well maintained and a lot of
work was put into it over all the time. So personally, I'd not be
against this addition.
> The function would start a dialog player and distribute messages to its
> children. A message could be sent when the dp pointer changes.
That will be difficult, since there is no internal space where to
store the old dp pointer. We could either just leave
cleaning/initialization of the sub dialog to the user, or maybe use
two messages - MSG_END_SUBDIALOG, which would cleanly shut down the
sub dialog, and set dp to NULL, and MSG_START_SUBDIALOG, which would
newly start the dialog found in .dp.
E.g.:
my_change_tab ()
{
object_message (&my_dialog[SUB_D], MSG_END_SUBDIALOG, 0);
my_dialog[SUB_D].dp = my_sub_dialog;
object_message (&my_dialog[SUB_D], MSG_START_SUBDIALOG, 0);
}
> The idea behind this proc is to allow easily changed areas of a DIALOG. My
> application, for instance, Will have an array of buttons during the game, but
> some informational text and a Start Game button before the game.
>
Yes, I can see this. E.g. "tabs" would be easy to do, or just an area
where various sub-dialogs pop up (with the rest of the GUI always
running, unlike popup_dialog). Even the grabber could benefit, maybe
have a sub-dialog which changes depending on the type of the current
selection.
> What do you think of this suggestion?
Well, if it is easy to implement (which I think it is) - it would be a
big improvement to the GUI. If it's hard to do (e.g. when just passing
on messages to another dialog player when over the d_sub_dialog
doesn't work easily) - it's probably not worth it, given we have
addons like masking or nasgui which I think already can do this.