Open campagnola opened 4 years ago
Why is signal/slot not a good choice?
Embedded in an application that already uses Qt, signal/slot is a great choice. But if we're going for a library that can be shared by many different projects, then we should probably not have Qt as a low-level dependency. My current feeling is that basic callbacks should be sufficient at the level of the individual device classes, and that we could also have an add-on event driven layer that makes use of Qt or similar.
OK, thanks!
How should we handle event-driven behaviors in the common API? In acq4, I used Qt's signal/slots for this, but I don't think that would be a good choice for this project. In vispy, we created a simple event/callback system (https://github.com/vispy/vispy/blob/master/vispy/util/event.py). There are also other (more common) event frameworks that we could draw from.