Unneeded spacing at the bottom of the terminal

[Brottweiler]

Comparing RXVT-Unicode and Termite, there is a spacing at the bottom of Termite. Like this:

Termite:

RXVT-Unicode:

How do I remove this spacing, or is it "hardcoded"? Why is it there?

[thestinger]

Enable the size_hints option in the configuration file if you want it to behave like urxvt, where the window can only increase by multiples of rows/columns.

[Brottweiler]

@thestinger I set size_hints = true then changed the geometry accordingly, but the spacing is still there.

[thestinger]

I can't replicate anything like this. If there's not room for a row at the bottom, it will be dead space without size hints. The behaviour of urxvt is the same, and the only difference I'm aware of is that it uses strange spacing for rows and columns instead of respecting the font's spacing.

[Brottweiler]

That seems to be the thing. If I have no geometry, and no size_hints set (I assume its set to false by default), it works as it should, but then I can resize per pixel which can screw it up still. With size_hints set to true, it seems that there always are a row at the bottom, that is too small for the prompt, or something.

[Brottweiler]

Ok, nevermind. If I have size_hints commented out, then I can edit the geometry in pixels so that the space removes. But if I set size_hints to true, then I will always have the spacing.

[saivert]

I have a patch I use for myself. It seems to get the job done, but I have not tested it on anything but Gnome 3 desktop (Mutter/Gnome-shell).

diff --git a/termite.cc b/termite.cc
index 53324d6..fcab139 100644
--- a/termite.cc
+++ b/termite.cc
@@ -221,8 +221,8 @@ static void set_size_hints(GtkWindow *window, int char_width, int char_height) {
     static const GdkWindowHints wh = (GdkWindowHints)(GDK_HINT_RESIZE_INC | GDK_HINT_MIN_SIZE | GDK_HINT_BASE_SIZE);
     GdkGeometry hints;

-    hints.base_width = char_width;
-    hints.base_height = char_height;
+    hints.base_width = char_width + 2;
+    hints.base_height = char_height + 2;
     hints.min_width = char_width;
     hints.min_height = char_height;
     hints.width_inc  = char_width;
@@ -1021,7 +1021,7 @@ gboolean position_overlay_cb(GtkBin *overlay, GtkWidget *widget, GdkRectangle *a
 }

 gboolean button_press_cb(VteTerminal *vte, GdkEventButton *event, const config_info *info) {
-    if (info->clickable_url && event->type == GDK_BUTTON_PRESS) {
+    if (info->clickable_url && event->type == GDK_BUTTON_PRESS && (event->state & GDK_CONTROL_MASK)) {
         auto match = make_unique(check_match(vte, (int)event->x, (int)event->y), g_free);
         if (!match)
             return FALSE;

Updated 8. jan 2015!!

It also requires you to hold Ctrl when clicking URLs so you can still make text selection just like in gnome-terminal. Not all of us use termite in a tiling window manager.

[paulgrove]

I am seeing this as well, I have highlighted the issue in this image:

I purposefully selected all the text in the window to highlight where the extra space (dark green) is along the right and bottom of the window.

I have enabled size_hints. If I resize the window it resizes in character sized increments as you should expect, and the extra space remains the same size, as if the window were just too large in these dimensions.

edit: for reference I installed from git today via archlinux AUR package. 2nd edit: I double checked, the extra space to the right and bottom is not large enough for another character to fit

[paulgrove]

Another update to this, I have some wide characters in my font, and the extra space to the right seems to line up perfectly if I put one of these wide characters in the right most column, which sort of explains that.

Not really sure about the extra space at the bottom though.

[Narrat]

Got the same "issue", whith this "dead" space. size_hints is enabled. Example with cdw:

Those bars appear on every occasion (started with or without geometry option) and are best recognized with ncurses programs, like cdw or vifm (at least for me)

[kj]

I was seeing this too. I couldn't use size_hints, so I had to find the "correct" pixel geometry, which always seemed to be a multiple of the font size + 2 pixels (as in the patch above). Setting the padding for VteTerminal to zero (as in the README) fixed this and allowed me to use size_hints, so I guess the widget has a default padding of 1px, at least in my environment (I'm running Arch Linux & Gnome if it makes any difference). Can the calculated geometry when using size_hints take the widget's padding into account?

[paulgrove]

To confirm what kj just said, adding the following to my ~/.config/gtk-3.0/gtk.css file fixed this issue for me:

VteTerminal {
    padding: 0px;
}

I guess I should have rtfm!

[Brottweiler]

:+1: @og01 and @kj

Should this be closed as resolved then?

[saivert]

No, I don't think so. An application should not require specific configuration in widgets to work as intended. Code needs to factor in the padding or programatically set this to zero for the widget instance.

[thestinger]

I'm not entirely clear on what the issue being reported here is. It's a cell-based program so only a multiple of the cell size is going to be non-dead space. If it doesn't use size hints, it has to cope with the dead space itself by filling it in. If it does use size hints, then it's up to the window manager if it respects them (otherwise it's the same as without them). The cdw screenshot looks like size hints working as intended, the window manager is just filling in the space around the window with a different fill colour.

VTE does use some padding around the edges by default, and CSS is the right way to disable that. It's not just adding that padding at the bottom though, it does it all the way around the edges. By default, it uses 1px of padding for me but it depends on the GTK theme.

[saivert]

Sure, the window manager is responsible for following the size hints but this is a standard X11 thing and most window managers follow it except for tiled wms where it doesn't make sense. My hack adds 2 pixels to both horizontal and vertical size_hints which fixes the problem. This ensures that the window resizes in steps that fit the VTE widget exactly and doesn't leave any leftover space. Because of the apparent 2px default padding of the VTE widget the container window doesn't have enough space for it using current size hints so you will always have leftover space in the bottom and to the left of the VTE widget regardless of window size. I'm not sure if it is the VTE widget refusing to fit in the window or if the leftover space is actually inside the VTE widget where it just doesn't render any text cells because they would be truncated. I need to study the code more.

[thestinger]

The issue might be that we're not properly including the padding in our code.

[Narrat]

Just to make it clear with the cdw screenshot. Using another vte based terminal (in this case roxterm (since 3.x on vte3)) there isn't this spacing. And a difference in size, although they get the same geometry parameter (doing it in the "classical" geometry), and the same font + font-size https://paste.archlinux.de/qVAVC/ top left: starting commands black background in cdw => roxterm grey background => termite

In this conestellation the termite window is larger then the roxterm one (and the larger part is the unneeded spacing). If I let them completly overlap this also applies for the the black spacing to the right. Checking the size (xwininfo), the wm tells me, they're the same geometry (although actual height and width is different)

[thestinger]

Okay, so this is just a bug with how the size hints are set. Fixing it now.

[rlopzc]

I'm seeing the same space, as you can see in the image. Modifying the line height seems to decrease the size of the bottom space.

Setting the margin-bottom to -10px seems to work but space is eaten. I can't use -8px because it doesn't work as expected