A mixin is used to inject code in the EventDispatcher/EventQueue inheritance hierarchy to extend the functionalities. In this document we will use EventDispatcher as the example, the usage for EventQueue is exactly the same.
The original inheritance hierarchy of EventDispatcher looks like,
```
EventDispatcher <-EventDispatcherBase
```
`EventDispatcher` is an empty class. It inherits all functions and data from `EventDispatcherBase`.
After two mixin A and B are injected, the hierarchy looks like,
The mixins can use all public and protected members (types, functions and data) in EventDispatcherBase. All public members in the mixins are visible and usable by the user.
A mixin can have special named functions that are called at certain point. The special functions must be public.
Currently there is only one special function,
```c++
template <typename...Args>
bool mixinBeforeDispatch(Args && ...args) const;
```
`mixinBeforeDispatch` is called before any event is dispatched in both EventDispatcher and EventQueue. It receives the arguments passed to EventDispatcher::dispatch, except that all arguments are passed as lvalue reference, no matter whether they are reference in the callback prototype (of course we can't modify a reference to const). So the function can modify the arguments, then the listeners will see the modified values.
The function returns `true` to continue the dispatch, `false` will stop any further dispatching.
For multiple mixins, this function is called in the order of they appearing in MixinList in the policies class.
`MixinFilter::appendFilter(filter)` adds an event filter to the dispatcher. The `filter` receives the arguments which types are the callback prototype with lvalue reference.
The event filters are invoked for all events, and invoked before any listeners are invoked.
The event filters can modify the arguments since the arguments are passed as lvalue reference, no matter whether they are reference in the callback prototype (of course we can't modify a reference to const).
Below table shows the cases of how event filters receive the arguments.
|Argument type in callback prototype |Argument type received by filter |Can filter modify the argument? | Comment |
|-----|-----|:-----:|-----|
|int, const int |int &, int & |Yes |The constness of the value is discarded|
|const int &, const int *|const int &, const int *& |No |The constness of the reference/pointer must be respected|
Event filter is a powerful and useful technology, below is some sample use cases, though the real world use cases are unlimited.
1, Capture and block all interested events. For example, in a GUI window system, all windows can receive mouse events. However, when a window is under mouse dragging, only the window under dragging should receive the mouse events even when the mouse is moving on other window. So when the dragging starts, the window can add a filter. The filter redirects all mouse events to the window and prevent other listeners from the mouse events, and bypass all other events.
2, Setup catch-all event listener. For example, in a phone book system, the system sends events based on the actions, such as adding a phone number, remove a phone number, look up a phone number, etc. A module may be only interested in special area code of a phone number, not the actions. One approach is the module can listen to all possible events (add, remove, look up), but this is very fragile -- how about a new action event is added and the module forgets to listen on it? The better approach is the module add a filter and check the area code in the filter.
`FilterHandle`: the handle type returned by appendFilter. A filter handle can be used to remove a filter. To check if a `FilterHandle` is empty, convert it to boolean, *false* is empty. `FilterHandle` is copyable.
