| Re: [AD] user-defined events |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2008-09-26, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> On 26 Sep 2008, at 20:58, Peter Wang wrote:
> > Here is a proposal for allowing user-defined events.
>
> Looks ok to me.
>
> > Do we need an ALLEGRO_USER_EVENT_SOURCE?
>
> I don't know. What would be the benefit? Maybe it'd just be a
> cosmetic thing?
Yeah. Won't bother with it without good reason.
> > Aside: I'm considering simplifying some of the internals (again) by
> > allocating events inside event *queues* instead of event sources.
> > So an
> > event source registered with two queues would create two copies of
> > each
> > event, one in each queue. The upside is that we get rid of some ugly
> > reference counting, which is only needed for such a rare situation.
>
> I actually do that in the program I'm working on: when exiting it
> pops up a window asking whether you want to quit or not. That window
> uses its own event queue. I think I only did that because I was
> playing around anyway, I could have just reused the original queue.
> If it makes the code simpler, go for it!
Yeah, it might make sense to use a new queue for a popup. Although,
you'll get events delivered to the old queue as well. You have to be
careful that you don't lose any "important" events (resizes?) in the old
queue because it got filled up while you neglected it.
> > You wouldn't need al_allocate_user_event() then. Instead, you'd
> > allocate
> > an event on the stack and fill it in. It would be copied into each
> > event queue when you call al_emit_user_event().
>
> I think that makes sense, actually. However, it does sound like it
> might require a lot of (fairly simple) changes throughout the library?
Yes.
> > +/* XXX Currently we have no formal way to allocate event type
> > numbers. */
> > +#define MY_EVENT_TYPE 1025
>
> True, and we probably want one. Even if we define
> ALLEGRO_EVENT_ABOVE_HERE_FREE_FOR_USERS (or something like that),
> it's possible addons will want to use a range of event types as well.
Yup. kcm_audio already has a "stream needs refilling" event,
and internally it could use another event type as well.
> How about the following: we make a function where a user can request
> the free "base number" for a range of events (say, 10), eg,
> int my_first_event = al_get_event_range(10);
> The user can then freely use numbers in the range my_first_event+0
> through my_first_event+9. The only downside is that users can't use a
> switch statement to identify their events.
>
> > +typedef struct ALLEGRO_USER_EVENT
> > +{
> > + _AL_EVENT_HEADER(struct ALLEGRO_EVENT_SOURCE);
> > + void *data1;
> > + void *data2;
> > + void *data3;
> > + void *data4;
> > +} ALLEGRO_USER_EVENT;
>
> I know I said providing the user with one pointer would be fine, so I
> can't reasonably complain when you give them 4, but I do think the
> common case might be that you want one or two integers to pass
> informmation along. Maybe we can have two of those as well?
Sure. There's plenty more space actually, as ALLEGRO_MOUSE_EVENT is
pretty big.
Peter