Patrick said: >> Ah ok, I didn't know that was considered bad practice, sorry.
I didn't know either, until finding that diagram Kent linked to. Clean layer separation takes away some convenience, but lets us fit modules in our heads while working. Plus it makes Dijkstra smile. >> In my mind it made sense to tackle it at the source; "why send a trackpad >> event if you're not gonna use it anyway" kind of thought. You're right, that makes perfect sense! GHOST does lots of things "just in case"; it doesn't know how (or whether) events are going to be used. Every time I grab 20 pen events with position, pressure, tilt, I know that all but one will probably be converted to an INBETWEEN_MOUSEMOVE, and discarded because the person holding the pen just wants to tap a button. >> Then the else if where I get stuck: I can do a check to see if the event was >> GHOST_kTrackpadEventScroll, but then how do I treat it? >> Setting the event type to MOUSEZOOM won't work because of the UI amonst >> other things, and I can't just set it to WHEELUPMOUSE or WHEELDOWNMOUSE >> either, since it received a GHOST_EventTrackpad. >> What would the correct approach be in this case? Kent replied: > Part of the problem is ghost is a bit old and track pad stuff was tacked on > later. It may need a redesign to > get things to work properly. For this trackpad gesture case, all we need is a function to set a (new) flag in GHOST from some higher-level code. Nothing disruptive or crazy, no new coupling. I would also like to have something similar for turning on/off MOUSEMOVE coalescing. Will a GHOST expert please weigh in on this? Mike Erwin musician, naturalist, pixel pusher, hacker extraordinaire _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
