Terminal resizing problems

[dsboger-zz]

It seems the terminals have a minimum size, but the splitters do not respect it, hiding part of the terminal. Maybe this image will make it clearer:

Also, I can achieve similar results by just splitting the terminals enough times.

EDIT: Last but not least, moving one splitter changes the position of other unrelated ones.

[gnunn1]

I was packing the terminals in the Paned widget with the shrink option set to true, changing it false fixes this issue.

[dsboger-zz]

The shrinking problem is gone, but I'm afraid other issues have surfaced. If I split the terminal continuously, the window grows past the screen size, even when it's maximized. Maybe a solution is to check if the window/screen has space to fit more terminals and show a message saying that splitting is not possible, and recommending to create a new session?

Also, the issue I mentioned in the EDIT of the original report remains. It would be best if changing one splitter did not affect the other unrelated ones. Maybe also setting property resize to false on the Paned children may solve it?

[gnunn1]

I'll have a look some more tomorrow and play around with the resize as well.

[gnunn1]

Checked what Terminator is doing as a data point, and it looks like they set resize to false and shrink to true, I'll try that tomorrow.

[egmontkob]

Make sure to check out
https://bugs.launchpad.net/terminator/+bug/1520969
https://bugs.launchpad.net/terminator/+bug/1521765

I can't remember the conclusion, other than that GtkPaned sucks and we'd need a GtkMultiPaned which is only available in the ADA binding. We were able to improve the situation to some point, but it's not perfect.

Maybe the best would be in the long run to convince Gtk+ folks to implement GtkMultiPaned mainstream (or we implement it and get it accepted). Or at least add some extensions to GtkPaned so that stacking them can lead to our desired behavior.

[gnunn1]

@egmontkob Thanks for the info, actually I noticed that Christian Hergert seems to be working on a multi-pane, hopefully it gets included in GTK at some point.

https://github.com/chergert/panel-gtk/blob/master/src/pnl-multi-paned.c

[gnunn1]

So I've changed it to the same options Terminator is using, I think as egmontkob points out it's really difficult to get this perfect given the current state of the GTK Paned component. Give the change a try and let me know what you think.

[dsboger-zz]

I've tested it again and got another suggestion: adding more scrollbars.

The problem with shrink=true is that terminal content is hidden "inside" the Paned. In this case, making the whole terminal tile (including the title bar) scrollable would mitigate the problem (although introducing weird double vertical bars).

With shrink=false, the window grows outside the screen. In this case, the whole tiled panel can be made scrollable, allowing the terminals to be added indefinitely without affecting the window size.

Out of these two suggestions, I think I'd prefer the second. In any case, it would be possible to add a suitable minimal height to the terminal content, as very short terminals are not useful.

[gnunn1]

I don't think I would want to add more scrollbars, that's just going to be too messy and ugly for my taste. IMHO at some point you just have to live with the compromises, I don't want to go down the Terminator path of expending significant effort trying to handle sizing and layout issues and options with a bunch of convoluted code and end up with a solution that still only works 90% of the time given the underlying limitations of GTKPaned.

So long story short, beyond tweaking the resize and shrink parameters I'm not planning on doing too much in this area. I actually like the shrink=true as I prefer reducing the content then window growing unexpectedly but I need to play around with both scenarios some more and see the full pros and cons of each.

If my C skills were better I'd consider writing an alternative to the Paned widget but I'm pretty weak in that area, in the meantime I'll keep an eye on the work Christian is doing, his video demo has me drooling a bit :). At some point I'll look at giving his implementation a try and see how it works and looks within Terminix.

[egmontkob]

It still seems to me that a terminal can't be made any narrower than ~360 px. If I make it narrower, part of it becomes hidden, rather than further shrinking.

I believe the question is: who sets this minimal width? Is it the title bar perhaps? I guess it shouldn't do so.

I understand that on one hand, with shrink=true, a vte widget might not fully be displayed, which is quite bad. With shrink=false, however, the entire window might grow larger, which is also quite bad. Not sure which one to go for, in case the user packs an extreme number of terminals into a window. I don't care too much by the way if the user pushes the limits to such extremes, though. I don't care too much either about terminals that are unusably small either (e.g. 100x100 pixels).

What is still quite bad, according to the original report, that even with 2-3 panes it can happen that a VTE of a reasonable size is partially obscured.

[gnunn1]

@egmontkob The issue of the minimum horizontal terminal size was due to the Search drop down concealed with each terminal. The first problem was that I had setCharWidths at 30 for the SearchEntry instead of setMaxCharWidths. The second issue is that the Entry seems to have an annoyingly large minimum size, however this can be addressed by calling setCharWidths(1). If you set both CharWidths and MaxCharWidths it appears the former acts as the minimum and the latter as the preferred size when in a container with more space.

@dsboger Now that each terminal can be shrunk much smaller horizontally (~130 px) I'm OK with disabling shrink so it enforces the minimum size as you have to create a fairly large amount of terminals before the window starts growing. Please try things out and give me your feedback, any issues let me know and I'm happy to look at it some more.

Thanks both of you for your help and patience with this issue.

[egmontkob]

@gnunn1 Thanks to you for working on this :) I think the new behavior is totally okay (and probably would be just as okay with shrink=true too).

[dsboger-zz]

It is working fine for me too.

[gnunn1]

Thanks, closing the issue.