> On 17-05-2016, at 1:32 PM, marcel.taeumel <Marcel.Taeumel at hpi.de> wrote:
> 
> Hi, there.
> 
> I just noticed that event filters include the whole event listener
> functionality. If filters always return false, they behave like listeners.
> Plus, any morph can have its own set of filters attached.

I was about to mention that. It would make reasonable sense to replace the listeners with filters, assuming a tolerable legacy api can be supported.

I’m not sure about having the filters work only on copies of events though. Seems to me that a significant part of the potential usefulness would be to have filters transform events either in the geometric sense of altering coordinates etc or in changing the other details (convert a Leap Motion input event coming in via socket into a mouse event, stuff like that) or even just dropping it entirely because it is a MouseEventForLockedDemo. Another use would be a fake event filter that reads lists of x/y/button and transforms into ‘real’ events as a way to handle recorded event stream for playback.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- His page was intentionally left blank.