CC'd the list On Thu, Jan 22, 2009 at 9:23 AM, Sam Spilsbury <[email protected]> wrote: > On Thu, Jan 22, 2009 at 3:58 AM, Bipin George Mathew <[email protected]> > wrote: >> Thanks Joel. This mostly clear things. btw, where did is this comment found? >> I grep'ed through the compiz 0.7.8 code >> (http://packages.ubuntu.com/source/intrepid/compiz) and could not find such >> a comment. Beryl's code perhaps? >> >> Chris, >> >> You mentioned that the XServer needs rework - do you know what the nature of >> the rework is and why it is needed? >> >> Thanks! >> -Bipin > > I really don't know where this discussion is going, but I think you > guys are confusing ezoom's fake input handling with real input > redirection. (That comment is in the plugins-main package by the way). > > For ezoom's fake cursor drawing, we need proper handling of hiding and > replacing animated X cursors. It's really wishy-washy, I remember > Kristian told me one that instead of the contrary, the animated > cursors disappeared when zoomed in and re-appeared when zoomed out. > Someone really needs to have a look at the code. > > As for input redirection, not too many changes in the server were > actually required there, it was mostly a change to XComposite to add a > triangular mesh co-ordinate space conversion system and then a hook in > tryClientEvents (or whatever it was) where is a window was clicked on > and had a mesh, that input would be transformed according to the mesh > and then sent to the client. > > It's still not as good as I'd like it to be to be honest, there are > numerous glitches that occur when a mesh is set, even if it is the > same as the normal input mesh: > * Menus appear in the wrong place > * The way I draw the mesh, because of triangle underlap and overlap, > some input can just be 'missed' and fall through to the next window. > * XDnd doesn't work (anymore) > * It's really complicated to figure out a correct input mesh. You > have to handle situations where both plugins set different meshes. > What I've ended up doing is just creating a mesh out of the > CompTransform passed around in paintWindow, but that is a sub-optimal > solution. As soon as someone gives me some documentation on how > drawWindowGeometry works (which, I believe is the function responsible > for setting all the verticies of a window as a polygon then passing to > drawWindowTexture), I'll use the data in that. >> >> On Tue, Jan 20, 2009 at 8:01 PM, Joel Bosveld <[email protected]> >> wrote: >>> >>> On Wed, Jan 21, 2009 at 11:57 AM, Bipin George Mathew <[email protected]> >>> wrote: >>>> >>>> Given that the upstream compiz does not use David's APIs, how is the >>>> zoom plugin able to translate the co-ordinates for ButtonPress? >>>> >>>> While looking at the compiz code, I did find XGrabButton was called on >>>> each window created to intercept the events; but I was expecting an >>>> XSendEvent with the ButtonPressMask to be called with the transformed >>>> co-ordinates- which I not find. Also, I read on the mailinglist that >>>> clients can ignore synth events of XSendEvent. >>>> Any pointers on how this translation is done? >>> >>> >>> From the comments at the top of the code: >>> >>> Note on input >>> >>> We can not redirect input yet, but this plug-in offers two fundamentally >>> different approaches to achieve input enabled zoom: >>> >>> 1. Always have the zoomed area be in sync with the mouse cursor. This >>> binds the zoom area to the mouse position at any given time. It allows using >>> the original mouse cursor drawn by X, and is technically very safe. First >>> used in Beryl's inputzoom. >>> >>> 2. Hide the real cursor and draw our own where it would be when zoomed in. >>> This allows us to navigate with the mouse without constantly moving the zoom >>> area. This is fairly close to what we want in the end when input redirection >>> is available. >>> >>> This second method has one huge issue, which is bugged XFixes. After >>> hiding the cursor once with XFixes, some mouse cursors will simply be >>> invisible. The Firefox loading cursor being one of them. An other minor >>> annoyance is that mouse sensitivity seems to increase as >>> you zoom in, since the mouse isn't really zoomed at all. >>> >>> >> >> >> _______________________________________________ >> xorg mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/xorg >> > > > Cheers, > > Sam > > > -- > Sam Spilsbury >
-- Sam Spilsbury _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
