Hiding scrollbar cannot be saved to the profile

[Massimo]

Since update to 1.0 there is always a scrollbar initially, even if it is hidden in the profile. Manually hiding the scrollbar works but must be done for every single split on new windows.

I open terminator directly with layouts like
terminator -l "2l2r" -m

[Egmont Koblinger (egmont-gmail)]

Unfortuantely it's a big mess in the gtk3 version too :(

It seems to me like a design confusion rather than just an implementation bug. What's the desired behavior? We should decide that first.

In profile prefs there's a three-state option: Left, Right, Disabled. In the per-terminal right-click menu there's a toggle whether to show it or not. This is already problematic.

It's unclear whether the profile pref is meant to specify the default for newly opened terminals only, or be always applied for existing terminals of the same profile as well (as it is done with most of the other profile prefs, probably the only exception being encoding's default where the word "Default" makes it clear).

Currently altering this setting modifies the scrollbar immediately for existing terminals. That is, it's not just the default for terminals of the given profile, it's the actual desired value at all the times.

With this approach in mind, the per-terminal "Show scrollbar" toggle in the right-click menu probably can't be defined correctly what it should do. In order for the right-click menu's toggle to make sense, the profile pref should be the default of the terminal only, and as such, the wording should make it clear, plus toggling it shouldn't have an effect on existing terminals.

One more problem: If the profile pref defaults to Disabled (as opposed to Left or Right), and then the user enables "Show scrollbar" in the right-click menu, should it appear on the left or on the right side?

This is a bug where we first need to define the desired behavior in a consistent way, and only after that we can go ahead and fix the implementation issues.

One possibility (not sure at all if this is the best):

Rework the profile prefs: instead of the 3-state option have two 2-state options (checkbox, radiobutton, combobox -- whatever):

- Visible by default or not
- Left or right side

Left vs. right would be regular profile pref, that is, toggling it would have an effect on all the terminals immediately. "Visible by default" on the other hand, as its name implies, would only have an effect on newly opened terminals, and as such, toggling it would have no immediate effect. This way the per-terminal right-click "Show scrollbar" option could be kept.

Another possible approach: Drop the right-click "Show scrollbar" menu, and make the profile pref apply to all the terminals retroactively (as it is probably meant to be now).

[Egmont Koblinger (egmont-gmail)]

On a slightly related note, gnome-terminal has already removed the possibility of having the scrollbar on the left. At least from the UI. There's a CSS hack to bring it back:
https://wiki.gnome.org/action/show/Apps/Terminal/FAQ#How_can_I_move_the_scroll_bar_to_the_left_side_of_the_window_.28like_in_xterm.29.3F

Nowadays the scrollbar is always on the right in pretty much every application. Probably some long lived terminal emulators (xterm, urxvt...) are the only exceptions.

And, by the way, Ubuntu default theme Ambiance has an asymmetrical look of the scrollbar, designed to be put on the right.

I don't want to push terminator in this direction, and it'd sure piss off a few "old-fashioned" (sorry, no offense intended) users, but this might be a cleanup idea to consider.

[Stephen Boddy (stephen-j-boddy)]

Fix committed in rev 1660 (gtk2 is fixed by 1766)

OK, So this was actually something that appeared merging one of the big gtk3 port patchsets from yourself Egmont. I'm not sure if it something you did, or something I did when merging, but the line that sets the scrollbar visibility when creating the terminal object was removed. The mistake even got backported to the gtk2 branch.

The profile stores the desired initial state: disabled, on left, on right, with on right as default. The Show scrollbar menu item is a quick run-time only toggle, and if it is not explicitly set to left or right, it will default to right.

[Egmont Koblinger (egmont-gmail)]

I might have indeed broken it, but it could have been together with fixing another bug (bug 1520761 or bug 1522568 maybe -- although the latter one is not marked as fixed), and maybe that other bug is broken now... or I might have broken it due to misunderstanding the intent -- I just realized yesterday in comment 1 that the intent is absolutely unclear.

As of the current version (rev 1660) bug 1522568 is definitely still not fixed (or broken again).

I can only repeat myself: we're facing a way more fundamental design problem than just an implementation bug. There's no way to fix the implementation without changing the design, the intent.

Just the graphical design itself, just seeing two screenshot: the prefs dialog having a three-state option, and the right-click context menu having the toggle for scrollbar visibility is already broken. There is just absolutely no way to come up with any sane, rational, consistent behavior behind these UI elements.

[Stephen Boddy (stephen-j-boddy)]

Fixed in 1660.

(Yes I know you dislike the 3 state/2 state thing, but for now it's working like it was before that line was accidentally removed. Maybe in the future I'll figure out those fancy graphical menus, and I'll add a three button toggle i.e.
 _______________
[ <- | -X- | -> ]
 ⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺⎺
Of course then there's the whole thing of dealing with rtl languages like Arabic. Because the switch is done by the toolkit, so for those guys they have to select the opposite of what they want in the preferences.