GtkScrolledWindow is simply incompatible with VteTerminal.

Thanks for the quick reply, would it make sense for VteTerminal to emit a warning when a GtkScrolledWindow is the direct parent and/or update the documentation to include a note about this. I suspect the inclination of most developers new to VteTerminal would be to place it in a GtkScrolledWindow rather then use a separate GtkScrollbar.

I added a note to the docs.

Isn't this a dup of the recently fixed bug 757448?

Oops, didn't read the last sentence of the original report :)

Gerald, could you please apply that patch and let us know if it fixes the problem?

Christian: It would be nice to have a new 0.42.x tarball released so that next Ubuntu LTS picks up this fix. It doesn't effect g-t but might effect people wishing to develop a new vte-based app.

So I built the 42.2 tag and manually applied the patch specified here to vte.cc. I still have the same issue. I can tell the patch is applied though because the artifact at the bottom that I was getting before is now gone. Also to clarify, the vte in the scrolled window it is actually 2 rows high, not 1.

I'm somewhat new to GTK development, so just to make sure I'm doing this right I'm setting up the ScrolledWindow as follows (D code, but it's pretty straight forward):

        terminalOverlay = new Overlay();
        ScrolledWindow sw = new ScrolledWindow(vte);
        sw.setPolicy(PolicyType.NEVER, PolicyType.AUTOMATIC);
        sw.setHexpand(true);
        terminalOverlay.add(sw);

When I use GTKScrollbar with the vte not in a ScrolledWindow it is sized as expected.

I don't think this is bug 757448, but is simply due to the incompatibility of VteTerminal with GtkScrolledWindow's sizing algorithm.

(@Egmont: I can certainly tag a new 0.42.x release, but as per usual, someone else will have to produce the tarball.)

(@ChPe: Yup, that's what I meant, if you could please ask whoever creates the tarballs, thanks!)