> You have some nasties - your input is going to have trouble due to zooming. > the > standard x input will be 1:1 where the windows are relative to the root window > etc. :)
Working around this is actually one of the main tasks my WM handles, and why it uses XI_RawMotion/QueryPointer - to be able to continuously reposition the current application window under the overlay so that the right pixel is under the mouse pointer, given the current zoom level. This works for all windows, except override redirect ones, which are therefore not zoomable, but drawn 1-to-1 atop everything else (which is fine, as that's mostly menus anyway). > but it is how you get to be efficient with less hiccups :) > > You could also try running python within the compositor - use python as a > binding engine then the compositor calls the python code. you can stuff it > into > a thread of its own and "ipc" between compositor loop and python thread. you > then have a tight binding with the ability to share data in memory (assuming > you put locks around accessing it) etc. :) > That is an interesting solution, a bit ugly IMHO, but might be a good compromise... Hm.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
