I don't see the utility of EventQueue as thing stand currently. I think a msh::Surface only needs an EventSink (i.e. an event handler). If we need an EventQueue in the future, it should be derived from EventSink. The surface doesn't need to know anything about the details of how its events are handled.
Also, I would argue that since the id and the event handler are not really optional for the correct functioning of mir, nor there is any need to reset them, they should be taken at construction time:
908 + // A dynamic cast is not ideal. But the alternatives all seem to require
909 + // non-trivial architectural changes. Another day...
I think these changes should be discussed in this MP, or alternatively we can split out the communications part to a different MP, leaving this with only the implementation of the internal event propagation and handling mechanisms on the server and client side.
I don't see the utility of EventQueue as thing stand currently. I think a msh::Surface only needs an EventSink (i.e. an event handler). If we need an EventQueue in the future, it should be derived from EventSink. The surface doesn't need to know anything about the details of how its events are handled.
Also, I would argue that since the id and the event handler are not really optional for the correct functioning of mir, nor there is any need to reset them, they should be taken at construction time:
msh::Surface(..., id, event_sink, ...)
msh::SurfaceFac tory::create_ surface( params, id/id_generator, EventSink)
908 + // A dynamic cast is not ideal. But the alternatives all seem to require
909 + // non-trivial architectural changes. Another day...
I think these changes should be discussed in this MP, or alternatively we can split out the communications part to a different MP, leaving this with only the implementation of the internal event propagation and handling mechanisms on the server and client side.
Marking "Needs Information" => "Needs discussion"