TWin: access to quick tiling via DCOP #436

This allows to tile windows via DCOP. Possibly useful for scripts.

Useful script for getting window IDs for testing (getwid):

#!/bin/bash
printf "%d\n" $(xwininfo | grep "Window id:" | cut -d' ' -f 4)

Run it without arguments and click on a window to get the window ID. It is automatically converted from hex to decimal.

You can test like this:

w1=$(getwid)
w2=$(getwid)
dcop twin default tileHorizontally $w1 $w2

I think this implementation is somehow restricting, because it forces the user to specify 2 or 4 windows at the same time.

With the mouse, we can tile an individual window to a border/corner. IMO, we should have a DCOP call that mirrors that behavior, tiling one window to a specific place (left, right, top, bottom or one of the 4 corners). This allows to tile an individual window. Multiple windows could be tiled using repeated calls to the same method.
Maybe for convenience, we can still provide methods to tile 2 or 4 windows as in this PR, but under the hood they would use the above call.

With the new call we could for example tile one window to the left and two more windows to the right-top and right-bottom corner, which is not possible with the current proposed implementation.

What do you think?

I think this implementation is somehow restricting, because it forces the user to specify 2 or 4 windows at the same time. With the mouse, we can tile an individual window to a border/corner. IMO, we should have a DCOP call that mirrors that behavior, tiling one window to a specific place.

In my original use-case tiling single windows would not make sense, but I can see how tiling a single window could be useful in scripts.

DCOP call that mirrors that behavior, tiling one window to a specific place (left, right, top, bottom or one of the 4 corners).

Would we specify the place as a value of enum ActiveBorder?

enum ActiveBorder
    {
    ActiveNone   = 0,

    ActiveLeft   = 1,
    ActiveRight  = 2,
    ActiveTop    = 4,
    ActiveBottom = 8,

    ActiveTopLeft     = ActiveTop | ActiveLeft,
    ActiveTopRight    = ActiveTop | ActiveRight,
    ActiveBottomLeft  = ActiveBottom | ActiveLeft,
    ActiveBottomRight = ActiveBottom | ActiveRight,

    ACTIVE_BORDER_COUNT
    };

Maybe for convenience, we can still provide methods to tile 2 or 4 windows as in this PR, but under the hood they would use the above call.

That is a good idea.

Would we specify the place as a value of enum ActiveBorder?

As a programmer I would say yes.
As a user I would say a value between 1 and 8, like a compass rose (1 = top, 2 = top-right corner and so on).
Either way, the user needs to know the values allowed. Option 1 is easier to implement, option 2 is easier to guess for a user.

@SlavekB what do you suggest?

EDIT: on second thought, it is probably wiser to choose option 1 (the programmer's way). Reason being that if in future we add some other functionality or layout (like a 3x3 grid for example), the values will always be consistent with the code.

As a user I would say a value between 1 and 8, like a compass rose (1 = top, 2 = top-right corner and so on).

Once PR #464 gets merged, we can use the values 0-7, which corresponds to the enum values for the 4 borders and corners.

I added a commit to this PR which does the following:

introduce a tileWindowToBorder() DCOP call, which allows to tile a window to one of the 8 possible tile position. This is equivalent to grab the window with the mouse and move it to the border. The location parameter should be between 0 and 7 and follows the corresponding values of the ActiveBorder enum.
rename the three tileXXX() DCOP calls introduced in the first commit to make the name more meaningfull
rename the internally used tile() method to tileToBorder(), again to make the name more meaningfull.

@blu.256 please test or let me know if you are happy with it, then we can merge. I would like to have this included into R14.1.2.

@MicheleC Don't know when I'll be able to test but the changes look good. You can merge this at your will.

I'm thinking of a way to expose this functionality in the GUI. The way I see it, the Kicker taskbar, and especially a task button's context menu is a good candidate. We could have something like a "Tile..." submenu, I can see that work for layouts with 2 windows (but no idea how would that work for more than 2 windows yet). I plan to experiment with the idea in my Skout project once the PR is merged and if I'm satisfied with the result, I'll create a PR for a similar feature in Kicker.

We could have something like a "Tile..." submenu

I have the exact same idea. Add a "Tile..." submenu to the RMB popup menu on taskbar/window titlebar. There the user could:

tite a window to a specific location. This action affect individual windows
select a window for left or 'righttiling. Then select another window and have an additional entry that saysTile Vertically`. This implies tiling the previously marked window and the current window side-by-side
same for Tile Horizontally
same for Grid tiling, obviously it will be necessary to select four windows for that and the position of each, so the menu may be a bit more complex.

Anyway this should be done after R14.1.2 is out, since we are too close to the freeze date.

I didn't do tests, but it seems good to me.

TWin: access to quick tiling via DCOP #436

Reviewers