Added "axis" attribute.

[Penguin-Guru]

This allows users to specify an axis in their gesture definitions, so different gestures can be defined for different axes. I wanted it for pinch gestures, but it might also be useful for others (e.g. one gesture definition for swipe left or right). There may be a cleaner way of implementing this functionality and it may be possible to improve the calibration somewhat, so I'm just posting it as a draft. Do you think something like this would be useful?

I still intend to make the axis attribute optional somehow.

[JoseExposito]

Hi!

Thanks for opening a pull request.

I haven't looked into the code in detail, but first, what's your use case for this feature? And also, what's the difference between axis and just setting the same action for left/right and up/down directions?

A few general things to consider:

This'll need substantial changes in https://github.com/JoseExposito/touche. I can't merge PRs if the UI changes are not done as well.

The client side of Touchégg is not the only client available. A couple of examples of clients are https://github.com/JoseExposito/gnome-shell-extension-x11gestures and https://github.com/elementary/gala.
Therefore, when modifying the D-Bus protocol, it is a must to keep backwards compatibility. Otherwise, we'd break existing clients.

[Penguin-Guru]

Hm. I'm not very familiar with D-Bus but it seems like the server could handle both formats for backward compatibility.

My current use case is to map separate gestures for horizontal and vertical axes of pinch events. Without this, pinch events use "IN" or "OUT" as the direction, so the axis data is not preserved. More specifically, I want four gestures:

1. IN & HORIZONTAL = shrink window horizontally
2. OUT & HORIZONTAL = expand window horizontally
3. IN & VERTICAL = shrink window vertically
4. OUT & VERTICAL = expand window vertically

The reason I want the axis data is so I can map actions for expanding AND shrinking windows EITHER horizontally OR vertically. They need to be separate gestures, because I want the axis locked throughout the gesture. I couldn't see a way to do this with the existing protocol, so I just built it out to see how it works.

[Penguin-Guru]

I used a simple approach to make the "axis" attribute optional, but I think it might be nice to change the map key from string type to a custom class. That would allow for more flexible comparisons and I think it would also be a little more efficient. It seems out of scope for this pull request, so I won't be doing that here. I'm curious what you think of the idea.

I wanted to keep the GestureAxis similar to GestureDirection but it feels a little unintuitive to use "UNKNOWN" to mean something like "ANY" or "ALL". A part of me wanted to add one of those to the enum, just for use in the config file. Another option I considered was using something like "NA" for non-applicable. That could mean unknown or any/all, but I don't know if it's actually more clear than "UNKNOWN". I'll just leave it the way it is unless you want me to change any of that.

[JoseExposito]

The reason I want the axis data is so I can map actions for expanding AND shrinking windows EITHER horizontally OR vertically.

Ok, so you'd like to implement a "resize window" action, is that correct?

Have in mind that every action so far is compatible with all gesture types: swipe, pinch and tap. While with swipe gestures this action could work by resizing vertically and horizontally the window, I wonder how it'd work with tap gestures. Before implementing it, it'd be a good idea to figure it out.

Also notice that IN/OUT are only the initial direction of the gesture. For example, if you start a pinch-in gesture and, in the middle of the gesture, you pinch out, the "percentage" of the gesture will increase.
For this example, the gesture could start shrinking the window but, once the direction of the gesture changes, the window will be expanded.

I'd suggest to split this work in 2 PRs:

• A first PR adding the RESIZE_WINDOW action and its animation. The behavior could be shrinking/expanding the window in all directions by the same amount. Updating the UI would be required as well.

• If we decide that the action is not good enough, we could add an "angle" field to pinch gestures to control how the window shrinks/expands. For example, a pinch-out with angle 90º will expand the window horizontally.

I'm not fully convinced about the need of adding an angle, as I don't think that any of the existing actions would benefit from it, but we can discuss it later.

[Penguin-Guru]

No, I didn't add any actions. I just added this property, "axis", which does track the initial axis of pinch gestures. I didn't need the initial direction because I could use SEND_KEYS to reverse the direction. This isn't perfect but it seems to work, so you can give it a try when you have time. The relevant part of my config looks like this:

<gesture type="PINCH" fingers="2" direction="OUT" axis="HORIZONTAL">
    <action type="SEND_KEYS">
        <repeat>true</repeat>
        <modifiers>Super_L+Control+L+Shift_L</modifiers>
        <keys>semicolon</keys>
        <decreaseKeys>j</decreaseKeys>
    </action>
</gesture>
<gesture type="PINCH" fingers="2" direction="OUT" axis="VERTICAL">...</gesture>
<gesture type="PINCH" fingers="2" direction="IN" axis="HORIZONTAL">...</gesture>
<gesture type="PINCH" fingers="2" direction="IN" axis="VERTICAL">...</gesture>

I use i3 as my window manager and I've mapped Super_L+Control+L+Shift_L+j to reduce the window's width and Super_L+Control+L+Shift_L+semicolon to increase the window's width:

bindsym $mod+Control+Shift+j resize shrink width 3 px or 3 ppt
bindsym $mod+Control+Shift+semicolon resize grow width 3 px or 3 ppt

The only problem I'm aware of is what you pointed out about the D-Bus protocol compatibility. I haven't figured out what to do about that yet.

Adding an action might be useful if it could communicate that angle value to the window manager, perhaps by adjusting the ratio of horizontal and vertical. The action would still need to be able to reverse the angle though, and some users might not want their actions to be locked into the initial angle. This isn't necessary for my case though and I'm not sure how to implement it. If you think that's the best approach, I can investigate a bit.

[Penguin-Guru]

I did what I could with the D-Bus protocol, but I'm not at all confident in that part. I still don't understand D-Bus well enough. The changes I made seem to provide backward compatibility but I think there are still a couple runtime warnings when clients disconnect. Please take your time and review that part carefully. The references I mentioned on the commit suggest including a version number field in the protocol-- I didn't do that because I wanted to avoid making more changes than necessary.