Partial solution to Gtk Linux split pane handle too large (#3020)

[daviewales]

I want to share my partial progress to solving issue #3020, and seek advice or alternatives to completely solve it.

My current WIP branch is here:
https://github.com/daviewales/ghostty/tree/gtk-paned-wide-handle

My WIP solution is the following patch:

diff --git a/src/apprt/gtk/Split.zig b/src/apprt/gtk/Split.zig
index 8f19974e..8812627b 100644
--- a/src/apprt/gtk/Split.zig
+++ b/src/apprt/gtk/Split.zig
@@ -114,6 +114,12 @@ pub fn init(
     // Keep a long-lived reference, which we unref in destroy.
     paned.ref();

+    // Ensure that the drag handle for split panes never overlaps
+    // pane content. (#3020)
+    // See recommendation in upstream Gtk issue:
+    // https://gitlab.gnome.org/GNOME/gtk/-/issues/4484#note_2362002
+    paned.setWideHandle(@intFromBool(true));
+
     // Update all of our containers to point to the right place.
     // The split has to point to where the sibling pointed to because
     // we're inheriting its parent. The sibling points to its location
diff --git a/src/apprt/gtk/style.css b/src/apprt/gtk/style.css
index 75d020a0..2dc2ef77 100644
--- a/src/apprt/gtk/style.css
+++ b/src/apprt/gtk/style.css
@@ -63,3 +63,38 @@ window.ssd.no-border-radius {
   margin: 0;
   padding: 0;
 }
+
+/* By default, a GtkPaned wide handle has a 1px border at the left
+* and right of the 5px wide pane resize handle. This border is created
+* with `box-shadow`. Instead, we want a single 1px line exactly in the
+* center of the pane resize handle.
+*
+* To achieve this, we reset box-shadow to `none`, and create a 1px
+* wide linear-gradient of the appropriate color in the center of
+* the pane resize handle.
+*
+* Attribution: https://stackoverflow.com/a/53551089
+*
+* We need to do this separately for vertical and horizontal panes.
+*/
+.terminal-window .notebook paned.vertical > separator {
+  box-shadow: none;
+  background-image: linear-gradient(
+    rgba(255, 255, 255, 0.15),
+    rgba(255, 255, 255, 0.15)
+  );
+  background-size: 100% 1px;
+  background-repeat: no-repeat;
+  background-position: center;
+}
+
+.terminal-window .notebook paned.horizontal > separator {
+  box-shadow: none;
+  background-image: linear-gradient(
+    rgba(255, 255, 255, 0.15),
+    rgba(255, 255, 255, 0.15)
+  );
+  background-size: 1px 100%;
+  background-repeat: no-repeat;
+  background-position: center;
+}

This fixes a few issues, but also creates a few more:
Enabling GtkPaned wide handle ensures that the resize handle no longer covers content in the split panes.
However, by default this appears as a rectangle with 1px borders on each side.
Ideally, it would appear as a single centred 1px line.

The CSS changes above approximate this, but with some remaining issue:

• The background colour of the separator itself does not inherit the background colour of the Ghostty theme.
  • This should be fixable. If you manually add background-color: <theme-background-color> to the paned > separator CSS in src/apprt/gtk/style.css, it works. So this needs to be hooked into the code that sets up the background colours somewhere.
• If you have both horizontal and vertical splits, the pane separator in the sub-panes doesn't quite meet the perpendicular pane separator of the parent pane.
  • I'm not really sure how easy this might be to fix. Because the separators are really 5px wide, they don't want to overlap the true (invisible) boundaries.

How it looks if I manually add the theme background color:

.terminal-window .notebook paned > separator {
  background-color: #282c34;
}

[00-kat]

+* Attribution: https://stackoverflow.com/a/53551089

IANAL and I'm not too sure if this is problematic, but it is worth noting that everything on StackOverflow is under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license, which may not be compatible with MIT (again, I don't know if it is or not, I'm just noting this).

[daviewales]

Thanks. That's a fair call. I suspect in this case it might fall under fair use, as I'm not sure if there is another way to do this. But the question may be moot, as I'm thinking that the only way to eliminate the gap between perpendicular separators will be to switch back to default narrow separators, and get fancy with CSS padding on the pane children.

[daviewales]

Update: I've got a new branch which change only CSS, and adds padding to pane children on any side which borders a pane separator. You can test it with any version of Ghostty built from a recent copy of main (last few days) with the GTK interactive inspector. Run Ghostty with this environment variable set:

GTK_DEBUG=interactive ghostty

Then paste the CSS into the CSS tab of the inspector, and ensure the 'pause' button is unselected.

CSS

/* Add 6px padding to any pane side which touches a pane separator.
 * This ensures that the pane resize handle and the pane content do
 * not overlap.
 *
 * There are four universal rules for any given pane:
 *
 * 1.  If any ancestor is the first child of a vertical split, add
 *     bottom padding.
 * 2.  If any ancestor is the second child of a vertical split, add
 *     top padding.
 * 3.  If any ancestor is the first child of a horizontal split, add
 *     right padding.
 * 4.  If any ancestor is the second child of a horizontal split,
 *     add left padding.
 *
 * However, because the children of split panes may be _either_
 * 'overlay' or another 'pane', these four rules become eight, to
 * account for these two possibilities in CSS.
 *
 * Note that we must apply padding _only_ to the overlay element, not
 * to a pane element, as this ensures that the separators will
 * intersect. If padding is added to a pane element, it will create
 * a gap between perpendicular separators.
 */

/* An overlay which descends from the first-child of a horizontal
 * pane 
 */
.terminal-window .notebook paned.horizontal > :first-child overlay {
  padding-right: 6px;
}

/* An overlay which _is_ the first-child of a horizontal pane. */
.terminal-window .notebook paned.horizontal > overlay:first-child {
  padding-right: 6px;
}

/* An overlay which descends from the last-child of a horizontal
 * pane
 */
.terminal-window .notebook paned.horizontal > :last-child overlay {
  padding-left: 6px;
}

/* An overlay which _is_ the last-child of a horizontal pane */
.terminal-window .notebook paned.horizontal > overlay:last-child {
  padding-left: 6px;
}

/* An overlay which descends from the first-child of a vertical pane
 */
.terminal-window .notebook paned.vertical > :first-child overlay {
  padding-bottom: 6px;
}

/* An overlay which _is_ the first-child of a vertical pane */
.terminal-window .notebook paned.vertical > overlay:first-child {
  padding-bottom: 6px;
}

/* An overlay which descends from the last-child of a vertical pane
 */
.terminal-window .notebook paned.vertical > :last-child overlay {
  padding-top: 6px;
}

/* An overlay which _is_ the last-child of a vertical pane */
.terminal-window .notebook paned.vertical > overlay:last-child {
  padding-top: 6px;
}

Open this image in a new tab, and zoom fully to inspect.

There are two remaining issues:

1. Because we are not using wide separators, we still have the Gtk bug which causes the pane resize handle to jump left a few pixels when you first start dragging it. (There is an open PR upstream to fix this.) (Note, this issue is present in the current release of Ghostty, and all Gtk4 apps which use the default separators and is not a regression.)
2. The background colour of the padding doesn't match the theme. (More digging required.) (But helpful for the screenshot so you can see the change!)

6px on each side seems like a lot. But I think this is the minimum required to avoid the drag handle. Strangely, it seems that the 'wide' handle has a smaller drag handle region.

[jcollie]

That looks pretty decent, definitely better than my attempts. The background can be fixed up in loadRuntimeCss easily enough. We also need to check that we've got everything working if background opacity is enabled. I do wonder if the extra "dead" space is going to cause more complaints than it solves though.

[daviewales]

I'm not happy about the 6px on each side, especially when compared with the wide handle, which was only 2-3px on each side. I'll ask upstream if we can shrink the handle. Edit: We could compromise by setting the padding to 3px, and just accept a 3px overlap with the content.

[daviewales]

I should mention that upstream suggest that we should try PanelPaned from libpanel if we're not happy with the default GtkPaned.