Hello Simon, > > Now, in an Xorg context, I'd very much like to hear your opinions on > > these concepts. Would it make sense to build this into an X helper > > library? > I'm a bit worried that discussion is inclined towards a library, as > opposed to a composite-inspired special client. The concepts themselves > sound fine. Just for my understanding: when talking about a special client, you think of something like a (compositing) window manager?
> A library can be done 'right now', since apps are free to do so. It has > the advantage of a close connection to the consuming app, but also the > associated disadvantages. > In particular, how to cope with global gestures, e.g. switching an app > or backgrounding it? Apparently, such things should be consistent. I > imagine a desktop environment might want to put up such a special > client, like they have preference for their WM. Quite correct; this is a problem my standalone library also has right now. It's currently only supporting fullscreen clients properly. > § A new 'gesture' event gets created, like: [...] > A prosaic example would be an app learning that there's a > "DIRECTED_DRAGGING gesture going on, starting at (200, 100)@70 degrees, > now being at (300, 100)@95 deg" and use this information to navigate > within a 3D-view. Also note the omission of (x,y) from the general > gesture event, since I'd deem it specific. Other gestures may not have a > primary x,y. I agree, this is quite similar to the way I have implemented it right now. This applies, e.g., to a relative motion gesture which only delivers a vector. > § A special gesture client (composite-like) > This client might receive events as discussed - but all of them - by > virtue of registering with the server. It analyzes the stream, and > whenever it thinks something important happened, it tells the server. > The server then dispatches a corresponding gesture event, according to > its state and some constraints given by the special client (e.g. > Florian's event regions, gesture-specific delivery constraints, ...) > which may not be part of the event as delivered. What kind of events are you considering here? Could a client generate new XI events? > The important point here is that gesture events are asynchronous, so > there's no need to wait inside the event loop. Gestures correlate to, > but don't strictly depend on other input events. Their timestamps may > not be in order for this reason. Could you elaborate on that a bit more? I fear I'm missing some background information here. > I never fully worked this out, so I can't offer a fancy paper, but it > seems sensible to me. And since anyone's free to do a library, when it > comes down to something X.org-endorsed, a special client infrastructure > might be a preferable choice. I'm very interested in putting a quick hack together to try this out. However, my knowledge about X internals is somewhat limited. Are things like custom events possible, and how would a (special) client go about sending them? Many thanks for your thoughts, Florian -- 0666 - Filemode of the Beast _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
