Add support for secondary direction layout split

[akiross]

Hello,
I've been very happy to know that someone is going on with the development of diffuse! I've been using the "sourceforge" version for years and found out about this fork only recently.

Now, back to my issue: I was wondering if it would be possible add an "secondary direction split" option, meaning that instead of A|B|C|D:

+----------+----------+----------+----------+
|    A     |    B     |    C     |    D     |
+----------+----------+----------+----------+

things could look like this (A|C|D)/B

+----------+----------+----------+
|    A     |    C     |    D     |
+----------+----------+----------+
|               B                |
+--------------------------------+

or like this B/(A|C|D)

+--------------------------------+
|               B                |
+----------+----------+----------+
|    A     |    C     |    D     |
+----------+----------+----------+

which can be convenient when doing merges with 4 files (old, parent, merged, new).

I am not sure how the UX of this could be, some ideas:

1. have a flag to specify whether to enable this, and by default one specific panel (e.g. the first, the last) will be moved down or up
2. have a flag to specify when to enable this: if the number of files is 4, move the X panel down or up
3. use floating windows: each file is a panel that can be arranged arbitrarily; this might allow for fancy layouts like A / (B | C) / D and it's the most flexible one
4. allow to specify a layout string, such as A|B|C|D, (A|B)/(C|D), A|(B|C|D) and split the screen according to that; fail if the number of files is not matching the string (I like this option best).

What do you think?

[joyously]

What is supposed to happen with the wider file? Is it part of the diff? Does it still scroll with the others? What's the goal?

Aside: the Windows editor Textpad does a split (for multiple views of one file) at any time by dragging a handle at the top of the scrollbar. I think it has a setting for whether the parts scroll together or not. It also has subwindow controls for each file so if you click fullscreen on any of them, they all fill the editor window (and you can switch between from other navigation), or toggle fullscreen off and they all are small windows in the editor window which can be arranged however you prefer.

[akiross]

Yes, the wider file is part of the diff and I think it should scroll with the others.

The goal is to provide a more intuitive understanding of the role of the files given their spatial position. To be honest, I don't think there might be many for regular code merging. For example, it follows the intuition to have 3 horizontal splits in which the left and the right sides get merged in the central one. What happens if a "common base" file is added? Spatially, it makes sense to have the "common base" on the top, or the "merged one" on the bottom.

This is somewhat similar to what vimdiff does when it is used as a merge tool for git: https://git-scm.com/docs/vimdiff/en