Hey.

Apparently there's some feature-regression in gtk since a while,
namely that scrollbars seem to disappear when the conntent isn't
scrolled right then.

Not sure if this is considered a "new fancy feature" or if it's simply
a stupid bug, at least I wouldn't have found any whay to tell
GTK not to do this.

IMHO, that bug is important, since it makes scrollbars by itself
in one half useless, namely showing where one is right now in the
scrolled content.
Probably it's even mor than 50% useless, because most people likely
scroll via the mousewheel, touchpad gestures or simply the keyboard,
so there isn't a particular need of scrollbar for the sake of the
actual scrolling.

However, when I'm in a PDF, lenghy mail or document one typically
may want to know where one is (e.g. how much is left to read),
which is now basically no longer possible unless one keeps moving.


Cheers,
Chris.

Am 13.12.2015 um 03:43 schrieb Christoph Anton Mitterer:

The overlay scrollbars are a feature

Well, I don't agree on the severity, but whatever.

If you don't like the overlay feature, you can use
GTK_OVERLAY_SCROLLING=0 evince

There might even be a .ini setting, but I'm too lazy to look that.
Shouldn't be hard to find.

Michael

Control: retitle -1 make overlay scrollbars more easily system-widely configurable and/or change the default
Control: severity -1 wishlist
Hmm I've actually stumbled over that when googling around, but it
seemed to be an unity thing only... so I didn't dig much deeper.
Well severity is always also based on personal reception... my reason
here was: GTK is a gui toolkit, that "feature" seems to make on of the
core GUI elements pretty useless.
It's as if they'd hide any buttons where one doesn't move the mouse
(with the weird reason, that right now one couldn't click on them
anyway).

But feel just free to reduce the severity... actually I think if
upstream makes such strange features default, it should be more easily
configurable (if Debian doesn't go the more sane and conservative way,
changing upstreams decision to what has been done and proven for
decades.
So I change this a wishlist.
What do you think would be the most appropriate place to set that?
/etc/X11/Xsession.d for system wide and ~/.xsessionrc for per-user?
Or rather xinitrc?

I don't think it should be one of gnome/cinnamon/etc's RC files.
Thanks for the hint.
Unfortunately I couldn't find anything about a corresponding .ini
setting, which would have actually been much better than setting
another envvar...
It even seems that the above may not be enough:
https://wiki.archlinux.org/index.php/GTK%2B#Disable_overlay_scrollbars
indicates one would also need to change the CSS (though that may be
theme related, as these dotted indicators don't appear here at all).



As for the wishlist:
Dear maintainers,
it has been the normal and proven behaviour for... well ever since GUIs
exist, that elements like scrollbars don't just disappear, even though
there *is* scrollable content.
If upstream thinks this is fancy, fine, but I'd consider that feature
rather a regression.
It's likely to confuse users and obstructs them in interaction with the
GUI (for the reasons I've mentioned in the previous mails in that
email).

I think Debian should either overrule that default, giving users the
standard behaviour, one gets (AFAICS) from any other toolkit.
Or alternatively (I you don't want to change the defaults, please, make
it more easily configurable.
I really did search for it for quite a while and - as mentioned above -
even stumble over the overlay scrollbar "feature", but it didn't really
appear to what's happening here.

Therefore, I'd think about a debconf question here. libgtk anyway pulls
in countless other deps, one more doesn't surely harm, and even though
it's not extremely common, there are several library packages (even
core) that use debconf.

To the least, this should be documented in README.Debian.


Thanks,
Chris.

Am 14.12.2015 um 00:45 schrieb Christoph Anton Mitterer:

If you want to see this behaviour changed, please talk to upstream.
Diverting this way downstream is something we don't do on principle.
It simply becomes unmaintainable over time and is the wrong way.
A debconf question is also out of the question.

Regards,
Michael

Well, now that I knew the name of the problem, I was able to find more
information about it, and looking at the various bug trackers
(upstream, RH, arch) it seems to be like CSD, countless of users
complain about it, while upstream simply puts their fingers into their
ears humming some melody ;)
So I guess that's just a waste of time.
I don't think that one simple change of a configuration option would
really make anything much more or less maintainable, would it?
What would be the specific problem with that?
It could be set high priority, so that users aren't typically bothered
by it.
Or one could possible make it a /etc/X11/Xsession.d/ snippet, shipped
by libgtk + some documentation in README.Debian, that makes it easier
for people to get whatever they want.


At least right now, this makes "end-user experience" more or less
random - normal GTK3/GNOME apps have the scroll bars disappearing,...
anything that's GTK2 (iceweasel, libreoffice), qt or other toolkit
works as it used to be.
Doesn't make it really easier for the end-user to get a somewhat
consistent state.


Cheers,
Chris.