Am 02.04.2010 10:52, schrieb Florian Echtler: >>>>> Just specifying what gestures a specific window would be interested in >>>>> wouldn't usually be "live", would it? That's something defined at >>>>> creation time and maybe changed occasionally over the lifetime, but not >>>>> constantly. >>>> Which is why a declarative approach is OK for that. It's the dynamics >>>> that make it harder. More specificially, the dynamic part of your >>>> formalism likely needs tailored requests. >>> The reason for this being that the special client won't be notified of >>> property changes on other client windows, correct? >> Not quite, the sgc could probably register for prop changes. By >> 'dynamics' I was referring to cancelling a gesture or other gesture >> state feedback a client may want to send. Props aren't good for that, >> but requests are. >> In requests, you're free to define semantics, whereas props are limited >> and quite racy. > OK, I see. I'll probably stay with properties for the first attempt (the > protocol used in my userspace lib doesn't require any such realtime callbacks > right now). I'll probably blatantly ignore _any_ performance-related > issues in the prototype, just to get a general feel for the problem. Not needing callbacks even in-process (where they're cheap) sounds like an excellent precondition for such an implementation. Though I'd guess it won't stay like that forever.
>> To me it seems sane. >> This replication of all input is one of the reasons for the 'special' in >> 'special gesture client'. Whatever it shall be it should probably be a >> part of Xi2. What leads you to think the above is flawed ? > The main reason why this code isn't yet sufficient IMHO is that I > haven't yet found out how to get some additional data from the received > events, particularly > a) which client window the event is actually targeted at and > b) what the position in window-relative coordinates is. I think this is intentional. You only get 'your events'. It's possible you need to explicitly knock up a sort-of input cc mechanism to divert the flow as appropriate. In that case, I guess the solution would need to be minimally intrusive to be acceptable. CC'ing input may have security implications as well. But as always, Peter may know something better ;) Cheers, Simon _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel