Event subscriptions

Discussion regarding the development of CEGUI itself - as opposed to questions about CEGUI usage that should be in the help forums.

Moderators: CEGUI MVP, CEGUI Team

User avatar
vinnythetrue
Not too shy to talk
Not too shy to talk
Posts: 21
Joined: Wed Aug 10, 2005 10:29

Event subscriptions

Postby vinnythetrue » Wed Dec 21, 2005 12:43

Recently, I encountered a problem with event (un)subscriptions (see here for more details).

So I thought about doing some minor modifications to the event unsubscription in the cegui event management. So I'll try here to explain what I'm about to do, so you can give me some advice.

In current version, when you unsubscribe some it is directly removed from the list, same when you subscribe, directly added.

#Subscription
What I want to do is let the subscription as it is, but adding the new connection at the front of the list (so an event added within another event process will not be directly fired).


#Unsubscription
I plane to add another list, the "to be removed events". So when removing an event, thanks to some boolean field, we may know if we are processing events or not, if so, the connection will not be removed directly but added to the new list. And finally, at the end of processings, the "to be removed" ones are actually removed.


So, could this reasonably be added in complete osmosis with the rest of cegui ?

User avatar
vinnythetrue
Not too shy to talk
Not too shy to talk
Posts: 21
Joined: Wed Aug 10, 2005 10:29

Re: Event subscriptions

Postby vinnythetrue » Fri Jan 06, 2006 10:20

Nobody has anything to say about my proposition ? :oops:

User avatar
lindquist
CEGUI Team (Retired)
Posts: 770
Joined: Mon Jan 24, 2005 21:20
Location: Copenhagen, Denmark

Re: Event subscriptions

Postby lindquist » Mon Jan 09, 2006 01:15

This does seem like a reasonable workaround for this annoying problem. It think that you'd get in trouble if you add the subscribers directly... a "queue" for both subscribing/unsubscribing is probably better. (I'm thinking about iterators getting invalidated...)

The next CEGUI will probably see some changes to how this whole thing works, but for the 0.4 branch I think this would be nice. The workarounds to fix things, when this kind of thing is needed, are much much worse than a little queueing IMO.

So please go ahead and see if this is feasible (it seems to be :) )


Return to “CEGUI Library Development Discussion”

Who is online

Users browsing this forum: No registered users and 6 guests