Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make EventHandler a component #140

Open
tlmquintino opened this issue Oct 22, 2011 · 2 comments
Open

make EventHandler a component #140

tlmquintino opened this issue Oct 22, 2011 · 2 comments
Assignees

Comments

@tlmquintino
Copy link
Member

I would make the current EventHandler a component, therefore allowing different event handlers to coexist, for different purposes.

I would then create a global instance inside Core - I think this will be possible, while avoiding the infinite loop that Bart mentioned.

@tlmquintino
Copy link
Member Author

Besides the global event handler (inside Core), EventHandlers could be then used in other places for alternative purposes.
Examples:

  • Place an event handler within each Workspace (group of processors working on the same physics within a multi physics simulation - yes, I know we still don't support it).
  • Place an event handler within each (C)Model

These are just ideas, opening up for discussion.

@barche
Copy link
Member

barche commented Oct 23, 2011

Yes, I would like to have EventHandler be a component as well, but I also like the fact that we can have all components react to an event, by registering in the constructor. I would propose the following solution to have both:

  • Make the EventHandler constructor public again, and rename the current static instance method to "global_event_handler"
  • Add a class EventHandlerComponent (better name suggestions welcome) that by default uses the global event handler, but also can be told to create a new event handler and use that one for registration and event raising purposes.

The advantage is that we can now control event handlers through the component interface (the EventHandlerComponent would expose a signal to raise an event, for example) and we can still use the EventHandler singleton for very special purposes, such as the need to register at component construction time. I believe it's safe to leave the global_event_handler singleton method, since the event handler doesn't really have any dependencies other than boost::signal.

An alternative to making the EventHandler constructor public could be to make EventHandlerComponent a friend class of EventHandler.

@ghost ghost assigned tlmquintino Nov 25, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants