Merge lp://qastaging/~samuel-thibault/compiz/shortcuts into lp://qastaging/compiz/0.9.13

Proposed by Samuel thibault
Status: Needs review
Proposed branch: lp://qastaging/~samuel-thibault/compiz/shortcuts
Merge into: lp://qastaging/compiz/0.9.13
Diff against target: 830 lines (+434/-47)
13 files modified
include/core/action.h (+8/-0)
include/core/screen.h (+4/-0)
include/core/window.h (+1/-0)
plugins/colorfilter/src/colorfilter.cpp (+6/-0)
plugins/ezoom/src/ezoom.cpp (+6/-0)
plugins/neg/src/neg.cpp (+5/-0)
plugins/showmouse/src/showmouse.cpp (+6/-0)
src/action.cpp (+37/-21)
src/event.cpp (+56/-11)
src/privateaction.h (+2/-0)
src/privatescreen.h (+14/-0)
src/screen.cpp (+279/-7)
src/window.cpp (+10/-8)
To merge this branch: bzr merge lp://qastaging/~samuel-thibault/compiz/shortcuts
Reviewer Review Type Date Requested Status
Marco Trevisan (Treviño) Pending
Review via email: mp+333330@code.qastaging.launchpad.net

Description of the change

This is a rework of the previous work of Colomban Wendling (https://code.launchpad.net/~banw/compiz/compiz.a11y-shotcuts). This version uses normal XI2 events, which poses much less problems and still allows to ignore grabs. In the end I changed the approach into converting XI2 events right from the xevent loop before handing them to the rest of compiz.

This depends on my branch https://code.launchpad.net/~samuel-thibault/compiz/motion-dup-fix

To post a comment you must log in.
4137. By Samuel thibault

Fix getting events for our own grabs

If a grab was taken by one of our own plugins, we have to ignore the X grab.

4138. By Samuel thibault

screen: Fix uninitialized variable

Revision history for this message
Marco Trevisan (Treviño) (3v1n0) wrote :

Thanks for your work, it's really appreciated and something I really had in mind since long time...

However, a part few cleanups (and a bit more of C++11 features usage), we've to think as this will deal with Unity, since there we're using XI2 already for some input monitor operations (mostly for edge events and for monitoring the mouse position when menus are opened, plus few other things), and the fact is that we disable such events when we don't need them.

Now, in theory we could move all that to compiz, introducing new actions types, but the problem now is that we can't really deal with all this work now that we're focused in GNOME

Another possibility is just to make unity to save the state on load with XIGetSelectedEvents and resume that state when we disable it, but in general I'd prefer the events not to be selected unless there's anything else that need them.

Another possibility is just make unity to keep them always enabled, and never toggle them.

In any case, it would be cool if you could test it with your changes, and in case propose a fix for it too. As without that change we can't land compiz in ubuntu (and thus upstream) easily as it could be prone to regressions.

4139. By Samuel thibault

screen: factorize XI2 to core event translation

4140. By Samuel thibault

Factorize XI2 SelectEvents code into privatescreen

Revision history for this message
Samuel thibault (samuel-thibault) wrote :

Hello,

I agree that selecting XI2 events only when needed would be ideally ideal, but
the obtained optimization (avoiding to trivially convert from XI2 events to core
events) does not seem to me worth the complexity cost.

Assuming that we avoid that complexity and just make compiz use XI2 whenever
available (Unity requires it anyway), things would be much simpler:

- Unity can use XIGetSelectedEvents() to determine what Compiz configured, and
merge it before XISelectEvents() and resume it, as you suggested.

- Compiz only disables XI2 temporarily within PrivateWindow::reparent(), so it
can also use XIGetSelectedEvents() to restore it as it was, either the original
compiz set or the set as merged by Unity.

That way, both sides are easily careful about what was set by the other side.

What do you think?

Samuel

Revision history for this message
Marco Trevisan (Treviño) (3v1n0) wrote :

Ok, that would look reasonable.

Could you possibly do that unity side of work too?
As otherwise this MP might stuck until I've time for that (and it might take a while).

Cheers

Revision history for this message
Samuel thibault (samuel-thibault) wrote :

Sure, I'll do the unity side :)
(probably on Tuesday)

4141. By Samuel thibault

xi2: save/restore masks instead of disabling/enabling compiz mask

Unity also uses xi2, so we need to restore its mask, and not the mask that
Compiz uses. This changeset completely replaces xi2SelectNoInput with
xi2DisableInput, which returns the mask which was active, so that xi2EnableInput
can reenable that same mask.

Revision history for this message
Samuel thibault (samuel-thibault) wrote :

Sorry I got preempted by other issues. I have pushed the compiz side, and will work on the unity side.

Revision history for this message
Samuel thibault (samuel-thibault) wrote :

Hello,

I have pushed the unity side on https://code.launchpad.net/~samuel-thibault/unity/shortcuts

Samuel

4142. By Samuel thibault

Enable grab ignore on colorfilter plugin too

4143. By Samuel thibault

Fix ButtonRelease/XI_ButtonRelease KeyRelease/XI_KeyRelease confusion

4144. By Samuel thibault

fix memleak

Unmerged revisions

4144. By Samuel thibault

fix memleak

4143. By Samuel thibault

Fix ButtonRelease/XI_ButtonRelease KeyRelease/XI_KeyRelease confusion

4142. By Samuel thibault

Enable grab ignore on colorfilter plugin too

4141. By Samuel thibault

xi2: save/restore masks instead of disabling/enabling compiz mask

Unity also uses xi2, so we need to restore its mask, and not the mask that
Compiz uses. This changeset completely replaces xi2SelectNoInput with
xi2DisableInput, which returns the mask which was active, so that xi2EnableInput
can reenable that same mask.

4140. By Samuel thibault

Factorize XI2 SelectEvents code into privatescreen

4139. By Samuel thibault

screen: factorize XI2 to core event translation

4138. By Samuel thibault

screen: Fix uninitialized variable

4137. By Samuel thibault

Fix getting events for our own grabs

If a grab was taken by one of our own plugins, we have to ignore the X grab.

4136. By Samuel thibault

Allow plugins to ignore keyboard grabs

by using XInput2 events when available, converting them into core events before handing them to plugins.

Based on the work of Colomban Wendling

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches