Getting rid of overlay scrollbars

[Ascaris]

I just switched to Mint Xfce from Mint Cinnamon, and I would like to know how to get rid of the overlay scrollbars in the various "X" programs (Xed, Xreader, etc). I remember the setting in Cinnamon's Settings, but I can't find anything similar in Xfce. How do I get rid of these horrible things?

[richyrich]

Only places I know where it could be hiding is Menu > Settings > Appearance, or Menu > Settings > Window Manager.

[Ascaris]

Found the solution. It involves setting the environment variable GTK_OVERLAY_SCROLLING to 0.

https://forum.xfce.org/viewtopic.php?id=10881

[slavko]

I did what has been suggested, but it doesn't work for me. Is adding

Code: Select all

export GTK_OVERLAY_SCROLLING=0

to ~/.bashrc only thing you had to do? Are you using Mint 19 or Mint 18.x?
Mint 19 Xfce here.

[MrEen]

Hi slavko.

Have you tried logging out/in or rebooting since the change?

From the OP's signature, it appears they were using 19 as well.

[slavko]

Have you tried logging out/in or rebooting

Yes, of course, rebooted, but it was of no avail.

[Neil Darlow]

Settings | Effects | Overlay scrollbars (logout required). Turn it off ... simples!

[slavko]

Settings | Effects | Overlay scrollbars (logout required). Turn it off ... simples!

Yes... in Cinnamon, not so simple in Xfce.

[MrEen]

See if the last post here helps.

[mint4all]

Have you tried logging out/in or rebooting

Yes, of course, rebooted, but it was of no avail.

Greetings!

Your problem is an old/standing issue. Its been discussed at length on the Xfce.org-forum, @ https://forum.xfce.org/viewtopic.php?pid=49672#p49672 ... My reply @ #9 describes what i did to kill those fade-in/-out scrollbars in the Mint-X & -Y themes (i assume that other GTK3-compliant themes have similar issues). Editing the "/etc/environment" file (as root) fixed my laptop's fresh LM19-xfce install. Credit is due: ultimately, the post on Arch's forum did the trick.

Good luck, M4A

[slavko]

AAAAAAAAH, what a relief! Finally, those pesky things are gone!

Thanks to all off you who offered help!

Now, to summarize, just for the record:
LM 19 Xfce, tried several things (all revolving around system variable GTK_OVERLAY_SCROLLING):

1. If I start program with:

Code: Select all

GTK_OVERLAY_SCROLLING=0 xed

it WORKS (that means NO overlay scrollbars).

2. If I set variable per user, by adding:

Code: Select all

export GTK_OVERLAY_SCROLLING=0

to ~/.bashrc then it DOESN'T WORK.

3. If I set variable globally, by adding:

Code: Select all

GTK_OVERLAY_SCROLLING=0

to /etc/environment then it WORKS, again.

Funny thing is, in both cases 2 and 3, export -p reports variable as set (with value "0"). Now, why in case 2 it doesn't work and in case 3 it works, is beyond my understanding.

BTW, in Cinnamon it's as simple as turning off one switch in Settings » Effects, In MATE it's already set (globally) to "0".

[slavko]

I'm not the OP, so I can't mark topic as "solved", but it should be marked, IMO.

[mint4all]

Glad to see it working for you ... My humble answer to your 3 scenarios: it all has to do with a particular switch-setting's "scope" -- simply speaking, who "sets" the variable, and who "sees" it. If we exclude hacks & exploits for a moment, a "parent" process sets it, and a "child" process sees, ad infinitum (unless some rules restrictions get programmed in). Linux' process tree (Terminal > "pstree") demonstrates that scope, and its underlying rules for who can "see" the parent's settings ... In LM18 & 19, "systemd" is the grand-parent for xfce4-panel, and all the processes started from the panel inherit the parent's settings (aka "environment").

Your #1 scenario works just for that instance because it inherits from the panel, then you set a new variable, and your editor inherits from terminal+commandline; then it goes away when you close THAT terminal window.
Your #2 scenario fails because you are barred from modifying the parent's environment; if you could, every process could do so up the process tree and create chaos at any level including the great-parent's (that's the world of hacks and exploits);
Scenario #3 works because at all levels/tree branches because you, as root, modified the GLOBAL environment of the systemd grand-parent process BUT you had to reboot to make it effective; that's why all subsequent processes (after that reboot) now can see the new setting/variable and act accordingly.

Sidebar: I wished there was a global system flowchart for each DE, such as XFCE or MATE, so we all could comprehend better how it all hangs together ... "Security by obscurity", eh? I hate this way of piecing things together ...

[LinWinux]

Sidebar: I wished there was a global system flowchart for each DE, such as XFCE or MATE, so we all could comprehend better how it all hangs together ... "Security by obscurity", eh? I hate this way of piecing things together ...

Yup, I agree with that 100 percent.

This is a very helpful post, bound to be beneficial to others, so yeah, marking it solved could be even more helpful.

Greetings from Overseas ...

.