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>





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/