PInputEventFilter is Overly Complex

[GoogleCodeExporter]

PInputEventFilter has so much logic to jump through that I can't help but think 
that pulling out a 
Filter interface that returned true to acceptsEvent and allowed for developers 
to implement their own 
logic would help.

For example, if I need to implement a filter that allowed for both keyboard and 
mouse control, but not 
both, I'm not even sure where to start. Maybe if I were smart enough I could 
hack together something 
involving the or, and, not masks of PInputEventFilter, but it'd be harder to 
debug that a simple class 
that implemented a tiny bit of logic when acceptsEvent gets called.

Once that interface were in place you could subclass it to collect events and 
create a representation of 
the input state rather that being reactionary to individual events, it could 
just pass an PInputState 
object that could be queried for mouse states, and keyboard states.  Allowing 
for things like holding 
down both left and right to mean grab. (Issue 80)

Anyway, I realize that this probably breaks binary compatibility, but I think 
we can figure out a path 
in this direction.

Thoughts?

Original issue reported on code.google.com by allain.lalonde on 20 Jul 2009 at 9:29

[GoogleCodeExporter]

I also dislike PInputEventFilter.

Consider UnaryPredicate<K> and related from Apache Commons Functor

http://commons.apache.org/sandbox/functor/apidocs/index.html

and/or Predicate<T> and related from Google Collections/Guava

http://guava-libraries.googlecode.com/svn/trunk/javadoc/index.html

Original comment by heue...@gmail.com on 24 Aug 2010 at 2:57

[GoogleCodeExporter]

Original comment by heue...@gmail.com on 26 Nov 2013 at 9:11

• Added labels: Milestone-2.1
• Removed labels: Milestone-2.0