Re: [AD] event source casts |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Tue, 2009-08-04 at 11:07 +1000, Peter Wang wrote:
> On 2009-08-03, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> > On Tue, 2009-08-04 at 00:20 +1000, Peter Wang wrote:
> > >
> > > A couple of comments.
> > >
> > > 1. al_register_event_source(queue,
> > > al_get_keyboard_event_source(al_get_keyboard()));
> > >
> > > is a bit silly since al_get_keyboard() has no other use any more.
> > > Same with al_get_mouse().
> >
> > As before with the cast.
>
> I was thinking we'd have:
>
> ALLEGRO_EVENT_SOURCE *al_get_keyboard_event_source(void);
> ALLEGRO_EVENT_SOURCE *al_get_mouse_event_source(void);
Makes sense. (Support for multiple mice could be a reason to re-publish
ALLEGRO_MOUSE at some point I guess.)
> and delete al_get_keyboard/al_get_mouse until such time that we need
> them, if ever.
>
> > > 2. This change introduces some confusion about the `source' fields in
> > > ALLEGRO_EVENTs. If I have a display event will the event source field
> > > point to the ALLEGRO_DISPLAY object, or the
> > > al_get_display_event_source(display)?
> > >
> >
> > True. What are the use-cases of the source field? In your specific
> > example I think ALLEGRO_DISPLAY_EVENT itself needs another field
> > "ALLEGRO_DISPLAY *display" which tells from which display the event
> > originated.
>
> Internally, the `source' field is now only used to delete events which
> reside in queues when the event source is unregistered from the queue
> (more commonly, destroyed).
>
> The user also wants to know which who generated an event, and that would
> be more convenient using the specific type of the event source (i.e.
> ALLEGRO_DISPLAY, etc). We can do as you say and add extra fields but I
> think that is confusing. At least we need to come up with new terms
> for the two different kinds of "event sources".
ALLEGRO_EVENT_SOURCE *source;
ALLEGRO_DISPLAY *display;
I don't think it would be confusing, as the event source is just an
opaque pointer - users wouldn't know about the C trick giving both the
same value for everything except user events.
>
> So I still would like to guarantee that
>
> display == al_get_display_event_source(display);
>
> and so on, as we had before ALLEGRO_STREAM and user event sources came
> along.
>
> The idea that I had during one of the Hack Days was, I believe, to make
> ALLEGRO_EVENT_SOURCE a structure with a publically known size but
> private fields. Then users can derive their own event sources in the
> same way as the core library without the extra indirection.
>
> struct MY_THING {
> ALLEGRO_EVENT_SOURCE es;
> int my_field;
> ...
> };
>
> I came across some minor problem when implementing it at that time, but
> really I think there should be no problem so I'll give it another go.
>
Sounds good. In my case, it will look like this though:
struct MY_THING {
MY_OBJECT super;
ALLEGRO_EVENT_SOURCE es;
}
So the assumption about the pointer values being the same still would
not hold - it shouldn't matter at all though, but we simply can't
enforce it for addons or even suggest to them that it's a good idea.
--
Elias Pschernig <elias@xxxxxxxxxx>