New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Hide scrollbar if scrollback buffer is empty #574

Open
rhssk opened this Issue Feb 22, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@rhssk

rhssk commented Feb 22, 2018

There are plenty of situations where the terminal application has it's own scrollback mechanism (vim, weechat etc.). In that case the termite scrollbar is just taking up space without any benefit.

But I find it really useful when reading text directly in terminal (dmesg output etc.) so I'd rather keep the scrollbar enabled.

I was wondering if there's some kind of way of telling if there's something in termite's scrollbar buffer and show/hide the scrollbar depending on that. I'm not familiar with GTK coding at all, but to me it looks like all the configuration is done before the main loop (gtk_main) and it wouldn't really be possible to call something like gtk_widget_hide(scrollbar) on-the-fly.

@egmontkob

This comment has been minimized.

egmontkob commented Feb 23, 2018

What would that space be used for? I can see two possible approaches. One is for the window to dynamically change its width, which might be quite disturbing. The other one is to have some more room for the actual terminal emulation. This latter one can practically only work for VTE-based emulators that don't install geometry hints (such as Termite). Note that depending on the graphical theme (scrollbar's width) and the font size, I guess typically you'd get 1 more extra column if at all, maybe under some IMHO rare circumstances 2 columns.


There are two ways a scrollbar can be "useless", that is, scrollback buffer is empty.

One is the terminal emulator's "normal screen" at startup (before a screenful of data is produced), or after a reset or similar operation. The other one is the "alternate screen" mode. Typically fullscreen apps (vim, weechat etc.) switch to this mode. The alternate screen does not have a scrollback buffer.

Currently I believe a VTE-based app can tell when the scrollbar is unusable (that is, either of these mentioned two cases is present), but cannot tell these two cases apart.

I'm not sure if hiding the scrollbar in the first case would be useful, I'd guess it's more misleading. And depending on the strategy for hiding/showing the scrollbar, it might result in the terminal emulation area shrinking by a column after the first pageful of data is produced, causing it to rewrap lines etc., which may not be a nice user experience.

I'd guess it's better if the scrollbar is only hidden in the alternate screen mode. This requires explicit support (signals emitted) from VTE. Moreover, most likely a heavy cleanup is desired for VTE's quite messy scrollbar handling, since currently updates to the scrollbar's parameters are not always atomic, e.g. bug 709089 might block this feature, I don't know. The fact that VTE's probably going to work around a GTK+ bug 769566 does not make it cleaner at all.

Also note that VTE would perform rewrap-on-resize operation back and forth on the contents of the normal screen, which might be expensive if there's a giant scrollback, and may in some rare cases slightly mangle the contents (e.g. around TAB characters). We might think of a solution where the normal and alternate screens inherently have different sizes, but that just sounds way too complicated.

Let's also note that certain apps, including vim are known not to handle correctly if they receive multiple resize events quickly after each other, due to a race condition. A similar race condition may easily result in many apps not properly starting up if a resize event is received during their startup, which would happen with this feature.

So, changing the terminal's size is quite problematic, IMO not worth it going for, for the benefit of typically 1 extra character column. Changing the window's width might probably be a better approach, if Termite can do it for non-maximized/fullscreen windows only, and more importantly, in a way that doesn't result in VTE resizing back and forth.


Yet another, probably significantly cleaner and more elegant approach could be to (optionally) use an overlay scrollbar, as (optionally) done by e.g. Tilix and Roxterm. Overlay scrollbar is clever enough to only show when there's scrollable content, and only when the mouse is hovered over.


Yet yet another workaround on user side could be to theme the scrollbar to be narrower. That's what I do :-) I'm using Ubuntu with Unity 7 desktop and Ambiance theme. I have these in my ~/.config/gtk-3.0/gtk.css for a narrower scrollbar in gnome-terminal, sure something similar could work for other themes and for Termite too:

terminal-window scrollbar.vertical slider {
    min-width: 5px;
}
terminal-window scrollbar.vertical {
    margin: 0px;
}

This scrollbar is thin enough for me not to worry about wasted screen real estate.

@rhssk

This comment has been minimized.

rhssk commented Feb 24, 2018

Although the benefit would only 1 or two columns, I'd still call that a win if the implementation would be relatively simple. But it looks like it isn't.

CSS does indeed improve things (new vs default)

.termite scrollbar.vertical slider {
  min-width: 3px;
}

.termite scrollbar.vertical {
  margin: 0px;
}

Not exactly what I had in mind but good enough for now, thanks for the detailed answer by the way.

@rhssk rhssk closed this Feb 24, 2018

@egmontkob

This comment has been minimized.

egmontkob commented Feb 24, 2018

Just for the record, I'm not Termite's developer. Overlay scrollbar might be a simple and viable idea for him to consider, maybe let's keep the bug open until we hear his take on that? :) Also I'm wondering if you could try this option in Tilix or Roxterm, just to see if you like its overall behavior?

@rhssk rhssk reopened this Feb 24, 2018

@rhssk

This comment has been minimized.

rhssk commented Feb 24, 2018

For Roxterm the scrollbar looks like the default Termite one and I didn't see any options to change that.
Tilix looks quite nice. The scrollbar works as an overlay and hides itself after ~2s unless mouse cursor has moved. It also correctly hides the scrollbar completely in vim etc.

@egmontkob

This comment has been minimized.

egmontkob commented Feb 24, 2018

Maybe you'd need a newer Roxterm, dunno. It's under Preferences -> Edit current profile -> Scrolling. Anyway, it's irrelevant since you could try it out with Tilix.

Now that you've confirmed that you like this behavior, I'm also curious what Termite's author will think of this.

@grmat

This comment has been minimized.

grmat commented Jul 13, 2018

PR #618 adds the ability to set overlay scrollbars. There is also the possibility of setting the policy to GTK_POLICY_AUTOMATIC, which does exactly what rhssk wanted, but I've had issues using top with that.

Feel free to comment on the PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment