Merge lp://qastaging/~ksamak/compiz/ezoom_focus_tracking into lp://qastaging/compiz/0.9.13

Can you please link a bug to the MP?

Ok this is the first part of the review. I'll continue later.

Thanks for all the hard work in implementing this. There's a fair bit of work to be done before this can be integrated. In particular, this cannot be merged whilst it opens a separate display connection - that is a recipe for deadlocks.

Relevant prior art, if interested: https://code.launchpad.net/~gloob/compiz/texttracking

well, this plugin would indeed have been helpful.

Sam Spilsbury (smspillaz) wrote 18 hours ago:
I like the fact that this is a separate library, but this absolutely doesn't belong in the mousepoll plugin. The mouse poll plugin is supposed to do one thing and one thing only - update the position of the mouse every N milliseconds. Move all this into either a separate plugin or library.

I originally made a copy of the mousePoll plugin (called focusPoll), but for some unknown reason it... deadlocked, or froze at runtime. I couldn't find why, and no one had time to look at it, so I merged both logics in mousepoll, cause then, with sensibly the same methods, it didn't freeze.

I agree an additional plugin would serve better, so I'd appreciate some input on that problem.
there's a readyish branch on http://git.hypra.fr/hypra/compiz.git named focuspoll. Maybe you would have some insights as to what is blocking here. It might be, as you pointed, the call to open the display.
question: how would you circumvent the problem of the call to XOpenDisplay, if the whole a11ywatcher was a library? Is there a better way to get the screen info? that is without causing all those problems.

I will meditate on these ideas, and weight the pros and cons of the different solutions, and i'll then continue the work.
thank you for all the advice and corrections, including those pending below. I am available to discuss these matters further, or if you have more insight.

> Maybe you would have some insights as to what is blocking here. It
> might be, as you pointed, the call to open the display.
> question: how would you circumvent the problem of the call to XOpenDisplay, if
> the whole a11ywatcher was a library? Is there a better way to get the screen
> info? that is without causing all those problems.

Yes, there's a global variable called 'screen' and you can access the current connection from there (screen->dpy()). If your library needs a reference to it, I'd suggest having the caller pass it in.

I've answered some of the following, and will superseed the merge request with the new version from the branch.
i thank you for your time, advice, and corrections.