I wholeheartedly support this bugreport. Many apps are disabling easy up/down scrolling this way as this causes pages to scroll much to far up or down by a simple touch if the scrollbar. Latest themes are a disadvantage to usability: scrolling used to be much more user-friendly than presently!

CC: (none) => dvgevers

Same here on i586.

CC: (none) => piscestong
Hardware: x86_64 => All

Agreed.  I've seen this issue on some machines (but not others) in MageiaUpdate and other drak tools as well.  I believe this is a gtk+3.0 regression.  Hopefully this can be fixed for everyone.

Blocks: (none) => 15527
Source RPM: unknown => gtk+3.0

Happens here after todays update.
Firefox affected but MCC appears ok

CC: (none) => westel

This has been discussed on dev too 2 years ago: https://ml.mageia.org/l/arc/dev/2013-12/msg00266.html

It's indeed a new behaviour than GTK+3 introduced back then, so GTK+2 applications (e.g. Libreoffice) behave the old way, and GTK+3 (e.g. Firefox, Chrome) applications the new way. I'm not sure about Qt4 and Qt5 but I guess they use the legacy mode too.

The main problem now is that after two years of daily usage of Firefox or Chrome, most users are likely used to the GTK+3 way (even Windows users). But for the sake of consistency we could still have a go at changing this for Mageia 6 onwards.

Summary: Scrollbar behavior is not consistent across apps => Scrollbar behavior is not consistent between GTK+3 apps and the rest

Apparently back then the issue was worked around by disabling the new GTK+3 behaviour in oxygen-gtk3, but since we are now using adwaita, this fix is gone.

CC: (none) => mageia, olav

I went to test with firefox, and it now appears that there is no vertical scrollbar visible, although it functions as if one were there, i. e. if you click on where the scrollbar ought to be, it reacts as if it were there.  This must have happened in the last day or two.

The workaround of using right-click works for gtk+3 (firefox) but not gtk+2 (thunderbird), so the inconsistency remains.

The gtk+3 behavior is nice to have available if you want it, but is there a way to exchange the function of left-click and right-click ?

To re-ask a question from the older thread in dev, if this is fixed in adwaita, will that correct the behavior in the installer ?

gtk+3.0 doesn't have a registered maintainer in our database, so assigning to packagers collectively.

If one of the packagers is maintaining this package, please update the maintainers database accordingly.

Assignee: bugsquad => pkg-bugs

This is a dupe of bug 14922, opened Dec 2014. Behaviour has been around for ages. If other desktops want GTK+3.x to behave differently, then have _that_ desktop set an xsetting for this so it behaves differently only on _that_ desktop. Patching/changing GTK+3.x is not needed and the wrong change.

(In reply to Olav Vitters from comment #9)
> This is a dupe of bug 14922, opened Dec 2014. Behaviour has been around for
> ages. If other desktops want GTK+3.x to behave differently, then have _that_
> desktop set an xsetting for this so it behaves differently only on _that_
> desktop. Patching/changing GTK+3.x is not needed and the wrong change.

I disagree.  This has nothing to do with desktops, it has to do with applications behaving as they always have no matter where in MGA they are running.

The fix given in bug#14922 is:
*************************************************************
To restore the standard behavior,place :

gtk-primary-button-warps-slider = false

in

/etc/gtk-3.0/settings.ini instead ~/.config/gtk-3.0/settings.ini

and use left click for pgup/pgdown.
*************************************************************
and we should implement this.

Obviously somebody in gtk-3 land anticipated that this wouldn't go over too well as an unconditional change.  They were right, it doesn't.

(In reply to Frank Griffin from comment #10)
> I disagree.  This has nothing to do with desktops, it has to do with
> applications behaving as they always have no matter where in MGA they are
> running.

That's just a preference, but ok. Let's assume I go along with this.

> and we should implement this.
> 
> Obviously somebody in gtk-3 land anticipated that this wouldn't go over too
> well as an unconditional change.  They were right, it doesn't.

If you want the app to behave the same in all desktops, then you don't need to patch anything. All gtk+3.0 apps already behave _exactly_ the same across all desktops.

Note that previously due to Oxygen setting the xsetting it already differed across desktops. Now for Mageia 6 it's suddenly a blocker that it is different. This isn't logical.

As said before: it has been around for ages and changing how GNOME behaves because of wanting a different experience within KDE is kinda rude.

I think you're missing the real problem(s).

First, almost no end user knows the difference between a gtk-3.0 app and a gtk-2.0 app.  All they are going to see is that some apps behave one way and others behave differently.  No end-user is going to understand why two Mozilla apps like Firefox and Thunderbird behave differently.

This is the same issue for GNOME and KDE.  Not every application we offer has converted to gtk3, and the ones that haven't will show the old behavior under both desktops.  That may be acceptable for some minor apps with small user bases, but it's not acceptable for core apps like FF, TB, LO, etc.

Second, no one but an aficianado is going to limit himself to using only apps which were early converters to gtk3 years ago.  In the case of Firefox, I only noticed this about the time I entered this bug, and I use Firefox every day.  So, as far as the timeline argument goes, the idea that gtk3 has been around for a while becomes irrelevant if the major apps that people use are only converting now.

Or are you saying that FF has exhibited the gtk3 behavior in GNOME for years and only started exhibiting that behavior in KDE recently ?

This seems to turn into an endless discussion. But my thoughts in another way.

I don't think people switch desktops often. Tiny amount of people try out one desktop after another. The way to influence gtk+ at runtime has existed for at least 2.0 (xsettings).

I've used GTK+3.x for a very long time. I assume you notice the change because:
1) I assume you're using KDE
2) Firefox is starting to use gtk+3.x
3) Oxygen-gtk is what changed gtk+3.x behaviour
4) Oxygen-gtk is mostly a theming engine and that is gone
5) Not using Oxygen-gtk resulted in more than just having a different theme; it also changed the behaviour of gtk+2.x

#5 is the problem. If the xsetting was still set you wouldn't have noticed. Yet the solution you propose is to change how GNOME 3 works instead of just changing the behaviour.

I disagree with your assumption that people mainly using gtk+3.x can be dismissed as an "aficionado". To me it is entirely reasonable to use mostly apps that come with the desktop. I mainly use gtk+ apps. Lots of years ago I used KDE. During that time I mainly used KDE apps (additional functionality over just Qt).

And yes, for years Firefox used gtk+2.x with a different scrollbar behaviour while all other gtk+3.x app used another scrollbar behaviour. Now for Mageia 6 that's suddenly a blocker?

What I don't get is why my suggestion is ignored? Why not per desktop? What is so unreasonable or strange about it? Why is the only solution something which changes gtk+3.x under all desktops?

I can fully understand that something like Firefox is noticed _way_ more than anything else. IMO I don't consider it really a gtk+3.x app; it draws pretty much everything itself and just emulates gtk.

Sorry, but we are not going to break Gnome/gtk+3 behaviour just so it looks nice in KDE/Plasma...

We are not KDE distro. Never was, never will be...

We are a linux distro that provides multiple DEs, including KDE/Plasma and Gnome...

CC: (none) => tmb

Meaning... if you want it changed in KDE, find a way to do it without breaking Gnome

This is getting very far afield from my original intention, partly it seems due to my own ignorance of how to control these behaviors.

My concern is simply that major stuff continue to behave as it has been behaving.  This includes core applications like FF, TB, LO, and also the installer.  If these things are currently behaving differently under different desktops, then let them continue to do that.

If FF has been using gtk3 behaviors under GNOME for a long time, and only started using them in KDE because of some obscure recent theme change, then I am perfectly fine with GNOME FF continuing to use them.  My understanding was that FF worked the same way on any desktop, but if that's not the case, so be it.

What I don't find reasonable is suddenly changing the behavior of major apps for reasons no end user is going to understand.  I suspect very few users have any idea what a theme is, that we patched oxygen to do this, and why we're hesitant to patch whatever we're using now to do the same.  Likewise, if there is an xsessions setting which can be used on a per-desktop basis, then there should be code to do that for each desktop.  GNOME should set it for gtk3, and KDE should set it for gtk2 (or gtk3 minus the changed behaviors).

There is no reason why a KDE (or any other desktop) user should suddenly see a behavior change because GNOME decided to change.  

And there is *absolutely* no reason why the MGA installer should suddenly behave differently because of some GNOME-desktop-specific change.  I would think this had been made obvious by the slew of installer GUI bugs reported when the installer was first converted to gtk3.  Regardless of the underlying technical cause of the problem, most of them boiled down to "it's not doing what it used to do", or "it's not behaving like Windows does".

Bottom line: if an app currently uses the gtk2 scrollbar behavior in *any* environment it should continue to use that behavior *in that environment*, whether we set that behavior for the entire environment or just for the app in that environment.  I'm not advocating that apps which have been using gtk3 behaviors in some environments and whose users are happy with this be affected.

@Thomas Come on.  You've been around long enough to remember that Mandriva and then Mageia was primarily a KDE distribution.  Multiple desktops were always supported, but as a dedicated GNOME 2 user until GNOME 3 came along, I was always aware that GNOME was a poor relation compared to KDE.  Our standard DM was always KDM, and every release cycle would see GDM break trying to log into KDE (or some other desktop) because KDM had been modified and GDM not.  I certainly don't want to break GNOME (or anything else whose user base doesn't consider it broken), but neither do I want to break KDE (or anything else whose user base is going to *consider* it broken) if this behavior suddenly shows up unbidden.

(In reply to Frank Griffin from comment #16)
> Bottom line: if an app currently uses the gtk2 scrollbar behavior in *any*
> environment it should continue to use that behavior *in that environment*,

It was actually inconsistent in GNOME 3. It's going to be consistent. I'm not going to change that just because you think that's better.

I've given lots of hints that I understand that impact to other desktops is an issue. Last request to accept that I'm trying to help and to pretty please let GNOME 3 be.

> And there is *absolutely* no reason why the MGA installer should suddenly behave
> differently because of some GNOME-desktop-specific change.

Except for the the total obvious: it uses GTK+.

A change made either in GTK+ or for GNOME obviously _can_ impact other stuff. That's why there's Cauldron. That's why there is a QA team. You're dictating your personal opinion of how GTK+ should behave as a requirement for Mageia. It's not workable. AFAIK we have 0 GTK+ developers.


Actual time invested by me:
1) I've checked how difficult it is to set an xsetting in KDE. Found that it is super easy to change e.g. https://projects.kde.org/projects/playground/base/xsettings-kde/repository/revisions/master/entry/xsettings-common.c. I'm planning to reach out to KDE, provide a patch and suggest that it is probably sane to patch it in. No clue if a Mageia user usually has xsettings-kde installed or not. Module came from Mageia and is unmaintained at KDE.

2) I've checked how difficult it is to patch gtk+ properly. Basically I can use the function gdk_mir_screen_get_setting from gtk+/gdk/mir/gdkmirscreen.c as example. Then change gdk/x11/gdkscreen-x11.c that sets (meaning: undoes the default) when environment variable is e.g. DESKTOP_SESSION=KDE. But I forgot what environment variable was the proper one. There are multiple ones.


Any other gtk+ based desktop I assume will handle it for themselves. As #2 seems pretty easy and low maintenance, I think that's already quite nice. No need to even have xsettings-kde installed.

Note that due to some Postfix upgrade problem I fortunately didn't read comment 16 because why the fuck did I spend time on this?

(In reply to Frank Griffin from comment #16)
> What I don't find reasonable is suddenly changing the behavior of major apps
> for reasons no end user is going to understand. 

Put up or shut up. Who did this? Who changed the behaviour? Let's get some pitchforks. Who went after Firefox to change their behaviour? Whomever they are, let's ban them and any of their applications from Mageia!

https://bugzilla.mozilla.org/show_bug.cgi?id=627699

Yeah, Firefox developers⦠now we can either continue responding in this way. It's great for showing of the community spirit. I highly prefer the technical approach though.

(In reply to Olav Vitters from comment #17)

Olav, you've got the wrong end of the stick here.  I'm not trying to jerk you around, and (as I've said previously) I'm not advocating that gtk3 behaviors that have existed in various places for years and with which users seem happy should change.

I'm deliberately taking the point of view of an end user, which is easy for me since I know practically nothing about gtk3.

> (In reply to Frank Griffin from comment #16)
> > Bottom line: if an app currently uses the gtk2 scrollbar behavior in *any*
> > environment it should continue to use that behavior *in that environment*,
> 
> It was actually inconsistent in GNOME 3. It's going to be consistent. I'm
> not going to change that just because you think that's better.

Nobody really cares about the purity of gtk3 and whether some upstream decision to change an expected behavior is good or bad.  All some certain class of users (and you seem to have a much better grasp of who they are) is going to see is that it worked this way yesterday and it works differently today, and today's behavior is not what they expect.

> 
> I've given lots of hints that I understand that impact to other desktops is
> an issue. Last request to accept that I'm trying to help and to pretty
> please let GNOME 3 be.

I have repeatedly stated that if GNOME3 users have been seeing this behavior for quite some time and are happy with it, then they should continue to see it.  I admit that my statements of that position have modified as I've learned more from the comments here about exactly who is affected and what can be done about it, mostly thanks to you.

> 
> > And there is *absolutely* no reason why the MGA installer should suddenly behave
> > differently because of some GNOME-desktop-specific change.
> 
> Except for the the total obvious: it uses GTK+.

Ah, here's the crux of the problem: lots of stuff running outside of GNOME has chosen to use GTK+.  Most of it has historically used the GTK+2 scrollbar behavior, and steps appear to have been taken to force this behavior even after the default GTK+3 behavior changed, largely because that's what GTK+2 Linux users and Windows users are going to expect.

GNOME is entitled to inflict whatever they want on GNOME users.  But when Mageia makes the decision to use a GNOME toolkit in non-GNOME components, it becomes our responsibility to ensure that we configure it in such a way that we don't cause major behavioral changes.  That applies to non-GNOME desktops as well as the installer.

I can see your point of "hey, you want to use GTK+, you take whatever baggage comes along with it", but as long as there is an option that can be configured for these environments, my view is that it ought to be.

*Somebody* seems to have put something into oxygen for exactly this purpose, and even though oxygen is no more, the rationale for that change is no less valid.

> 
> A change made either in GTK+ or for GNOME obviously _can_ impact other
> stuff. That's why there's Cauldron. That's why there is a QA team. 

And that's why I opened this bug report.  And why comments 1-4 were posted.

>You're
> dictating your personal opinion of how GTK+ should behave as a requirement
> for Mageia. It's not workable. AFAIK we have 0 GTK+ developers.

As you've already pointed out, there seem to be many options for fixing this that don't involve modifying GTK+.  And one might wonder why we base our installer on GTK+ if we have no in-house expertise or willingness to tweak it.

Again, see comments 1-4.  It's not just my personal opinion.

> 
> 
> Actual time invested by me:
> 1) I've checked how difficult it is to set an xsetting in KDE. Found that it
> is super easy to change e.g.
> https://projects.kde.org/projects/playground/base/xsettings-kde/repository/
> revisions/master/entry/xsettings-common.c. I'm planning to reach out to KDE,
> provide a patch and suggest that it is probably sane to patch it in. No clue
> if a Mageia user usually has xsettings-kde installed or not. Module came
> from Mageia and is unmaintained at KDE.

Thanks for this.  If this is truly just a KDE issue, this should do the trick.  Won't help the installer, though.

Just out of curiosity though, are you certain that GTK+2 stuff (like FF) under GNOME has been exhibiting the GTH+3 behavior for years ?

> 
> 2) I've checked how difficult it is to patch gtk+ properly. Basically I can
> use the function gdk_mir_screen_get_setting from gtk+/gdk/mir/gdkmirscreen.c
> as example. Then change gdk/x11/gdkscreen-x11.c that sets (meaning: undoes
> the default) when environment variable is e.g. DESKTOP_SESSION=KDE. But I
> forgot what environment variable was the proper one. There are multiple ones.

Sounds great, but we'd need an environment variable for the installer.  And again, this assumes that the desirability of the GTK+2 behavior is defined by the particular desktop.

> 
> 
> Any other gtk+ based desktop I assume will handle it for themselves. As #2
> seems pretty easy and low maintenance, I think that's already quite nice. No
> need to even have xsettings-kde installed.
> 
> Note that due to some Postfix upgrade problem I fortunately didn't read
> comment 16 because why the fuck did I spend time on this?
> 
> (In reply to Frank Griffin from comment #16)
> > What I don't find reasonable is suddenly changing the behavior of major apps
> > for reasons no end user is going to understand. 
> 
> Put up or shut up. Who did this? Who changed the behaviour? Let's get some
> pitchforks. Who went after Firefox to change their behaviour? Whomever they
> are, let's ban them and any of their applications from Mageia!
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=627699
> 
> Yeah, Firefox developers

The point isn't whether the FF developers chose to go with GTK+3.  The point is that we took action to disable the default GTK+3 behavior in spite of their decision for some years now, at least under KDE.  If that was the right decision then, I don't see why it is suddenly the wrong decision now.

I grok your technical opinion that "GTK+3 is the way of the future and all you luddites had better fall in line sooner if not later", but from a QA perspective you don't just go yanking the rug out from under expected behaviors and drag it in through the back door.  Like I said, if GNOME wants to screw around with their UI, that's their call.  But if Mageia chooses to use GTK+ outside of GNOME then it's MGA's call as to how to tweak it to achieve our objectives.  

And one of those objectives should be continuity of user experience.

(In reply to Frank Griffin from comment #18)


> GNOME is entitled to inflict whatever they want on GNOME users.  But when
> Mageia makes the decision to use a GNOME toolkit in non-GNOME components, it
> becomes our responsibility to ensure that we configure it in such a way that
> we don't cause major behavioral changes.  That applies to non-GNOME desktops
> as well as the installer.
> 

And you still dont get it.
You seem to be happy with behaviour changes from KDE3 -> KDE4 -> Plasma,
but when Gnome changes something, then you go "oh no..."

And everything does not always "have to" stay the same... its called progress...

> I can see your point of "hey, you want to use GTK+, you take whatever
> baggage comes along with it", but as long as there is an option that can be
> configured for these environments, my view is that it ought to be.
> 
> *Somebody* seems to have put something into oxygen for exactly this purpose,
> and even though oxygen is no more, the rationale for that change is no less
> valid.
> 

That was a "Mandrake/iva corporate decision" back then that everything had to look like KDE.

Thankfully we dont have to keep that and have now finally removed that since the forcing of oxygen stuff introduced breakages in Gnome that endusers "had to live with or workaround"... so we are just fixing a long-time regression...

What would you think KDE/Plasma users would say if we would flip this whole issue around and enforce Gnome look/feel on them...?

> 
> As you've already pointed out, there seem to be many options for fixing this
> that don't involve modifying GTK+.  And one might wonder why we base our
> installer on GTK+ if we have no in-house expertise or willingness to tweak
> it.

Its another thing we brought with us from Mandriva days...

Feel free to rewrite the installer in another language if you think it's better...


> The point isn't whether the FF developers chose to go with GTK+3.  The point
> is that we took action to disable the default GTK+3 behavior in spite of
> their decision for some years now, at least under KDE.  If that was the
> right decision then, I don't see why it is suddenly the wrong decision now.
> 

Because forcing KDE style stuff on gtk/gnome introduces regressions that is not an option... we are trying to provide a clean Gnome experience...

And you seem to think that gtk+3 is ony a "minor vesion bump" of gtk+2 so everything have to behave the same... but it is not...


> I grok your technical opinion that "GTK+3 is the way of the future and all
> you luddites had better fall in line sooner if not later", but from a QA
> perspective you don't just go yanking the rug out from under expected
> behaviors and drag it in through the back door.  Like I said, if GNOME wants
> to screw around with their UI, that's their call.  But if Mageia chooses to
> use GTK+ outside of GNOME then it's MGA's call as to how to tweak it to
> achieve our objectives.  
> 

That it is, but we still wont break Gnome in the process..

> And one of those objectives should be continuity of user experience.

Actually Mga6 is the perfect time to do changes to the user experience... (remember progress...)

Plasma is also introducing some new stuff, so it's a good "Mageia Refresh / facelift time".

And we are still in development phase adjusting to new changes all over... so things will still change

(In reply to Frank Griffin from comment #18)
> Sounds great, but we'd need an environment variable for the installer.  And
> again, this assumes that the desirability of the GTK+2 behavior is defined
> by the particular desktop.

You're getting me wrong. I'd love if the installer did NOT use GTK+. The development versions sometimes have bugs that are difficult to reproduce and difficult to get fixed. The current GTK+ devel version is _super_ buggy. All that time that I try and test GNOME 3, it is breaking the installer.

IMO the installer could do whatever the hell it wants. If something different is wanted, just make it so. The purpose is to install Mageia, not to show off some toolkit (Qt/GTK+/whatever).

> The point isn't whether the FF developers chose to go with GTK+3.  The point
> is that we took action to disable the default GTK+3 behavior in spite of
> their decision for some years now, at least under KDE.  If that was the
> right decision then, I don't see why it is suddenly the wrong decision now.

I don't want GTK+ leading to inconsistencies within other desktops. If I can I'll fix it.

> I grok your technical opinion that "GTK+3 is the way of the future and all
> you luddites had better fall in line sooner if not later", but from a QA

No: It is: every desktop should make their own decisions. If Qt doesn't work nicely with GNOME 3 I'd ask for a change _when running in GNOME 3_. If some GNOME 3 app runs a bit weirdly in KDE, then "meh". Some GTK+3 app, then "meh".

If you notice it often (like Firefox), then I'll try and help out.

> perspective you don't just go yanking the rug out from under expected
> behaviors and drag it in through the back door.  Like I said, if GNOME wants
> to screw around with their UI, that's their call.  But if Mageia chooses to
> use GTK+ outside of GNOME then it's MGA's call as to how to tweak it to
> achieve our objectives.  

_without_ impacting GNOME 3! Which is often perfectly possible! 

> And one of those objectives should be continuity of user experience.

What you want is your desktop to behave the same way. If you tell me: GTK+3 within KDE is inconsistent/fucked up/complete mess. Or an: x/y/z behaviour doesn't work in KDE, then let's sort it out. If you look back, the "luddites had better fall in line sooner if not later" is not at all how I responded.

What people are complaining about is not that GTK+3 behaves some way. It is that it is GTK+3 within KDE behaves _different_ because they're using _KDE_! Don't use this as a argument to say GTK+ should change also in GNOME 3. If the GNOME 3 behaves consistently but it is unworkable for someone it is up to the developers of that desktop to do something about it. Any suggestion to just change GTK+3 I'll ignore. But as soon as you tell me you're not using GNOME 3 then it is a completely different thing. Then GTK+ is impacting your other desktop experience. That I do care about.
Note: I don't care one bit about KDE in the same way that I don't care about millions of other topics. No interest; nothing more.

If some other GTK+3 desktop has their scrollbar behaviour changed: It really is up to them to change it back. It is pretty easy and as a GTK+3 desktop it is _their_ responsibility. Not some Mageia KDE packager/user.

A brief history: Loads of years ago every toolkit was entirely inconsistent. To ensure a toolkit could reuse the settings from its environment freedesktop.org was started. A very outdated and incomplete list of settings to ensure that the experience across applications is consistent is at:
http://www.freedesktop.org/wiki/Specifications/XSettingsRegistry/
This was created around 2001. Same people who created this are still involved. My suggestion of xsettings seems to be taken up as a dismissal or something. However, it is the exact way we've ensured consistency for ~15 years!

Recently one of the KDE sysadmins pointed out a GNOME mailing server configuration issue that was causing problems for them. I communicated a bit with him and fixed it. How difficult to you think it would be for me to get a KDE git account approved and merge all the outstanding xsettings-kde patches? It would mean any improvement made for KDE Mageia would automatically improve the experience for lots of distributions.

Anyway, I'm going to fix this as outlined in comment 17.

Some reality check would be nice. There are lots of things that could be done. Various things are broken. A scrollbar behaviour in an installer is very high in my "there are more important things to care about" list.

Source RPM: gtk+3.0 => gtk+3.0, xsettings-kde
Assignee: pkg-bugs => olav

I was reading this conversation from the beginning. As Mate Deskotp maintainer, which is currently a gtk+2 desktop (possibly will migrate to gtk+3 for Mga 7); gtk+3 behaviour changes also effect the desktop experience. No, i don't think it is a bug for gtk+3 but desktop environments themselves. I suggest (and think for Mate) about to desktop environments should set expected "consistent" behaviour. Like, Olav suggests for xsettings-kde package. Tough i don't sure if it is appropriate to modify behaviour of gtk+3 for non Gnome desktops. See, I intend to add a line to /etc/materc which starts mate desktop:

> echo "gtk-primary-button-warps-slider = false" >> $HOME/.config/gtk-3.0/settings.ini

But, that will modify all gtk+3 applications behaviour per user and may effect user's Gnome session if both Mate and Gnome is installed.

One question for Olav; is there another way to change gtk+3 behaviour for *just MATE* and not any other?

I certainly don't like gtk+3 behaviour of scrollbars but i'm against to patch gtk+3, i believe that we should keep as possible as to keep vanilla upstream.

CC: (none) => tarakbumba

(In reply to Atilla ÃNTAÅ from comment #21)
> One question for Olav; is there another way to change gtk+3 behaviour for
> *just MATE* and not any other?

Does MATE use its own theme? Basically in a theme file you can put a file (IIRC settings.ini, but need to check) in the themes settings directory to change the gtk+ settings only when that theme is used.

If MATE doesn't have its own theme, I'm wondering if a fake theme can be created which just points back to 'Adwaita'. Then put (IIRC) settings.ini in the fake theme.

Not sure if MATE also has a fork of gnome-settings-daemon; that would be another way of achieving the same result.

(In reply to Olav Vitters from comment #20)

> IMO the installer could do whatever the hell it wants. If something
> different is wanted, just make it so. The purpose is to install Mageia, not
> to show off some toolkit (Qt/GTK+/whatever).
> 

Actually this happends since we re-use/share code between drakx tools and the installer, so gtk+ fixes for drakx* affects installer...

However, if needed we could probablt drop in a custom settings.ini during stage2 build in case installer need some specific modifications...

(In reply to Olav Vitters from comment #22)
> (In reply to Atilla ÃNTAÅ from comment #21)
> > One question for Olav; is there another way to change gtk+3 behaviour for
> > *just MATE* and not any other?
> 
> Does MATE use its own theme? Basically in a theme file you can put a file
> (IIRC settings.ini, but need to check) in the themes settings directory to
> change the gtk+ settings only when that theme is used.
> 
> If MATE doesn't have its own theme, I'm wondering if a fake theme can be
> created which just points back to 'Adwaita'. Then put (IIRC) settings.ini in
> the fake theme.
> 
> Not sure if MATE also has a fork of gnome-settings-daemon; that would be
> another way of achieving the same result.

Olav, Mate uses its own Mate theme but i don't think we can change this behaviour for all circumstances. When a user changes the theme than our modifications to Mate theme would gone. 

Mate has mate-settings-daemon (gnome-settings-dameno fork) so i think we can use that, if you explain how a bit :)

Option A:
Modify static FixedEntry fixed_entries
https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/xsettings/gsd-xsettings-manager.c#n413
Find the equivalent for MATE.

Option B:
Change the default override key
https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/xsettings/README.xsettings
See how to change defaults in mageia-theme. No need to patch, you just change things. IMO the README isn't very clear on how to properly set it.

PS: Don't forget to file a bug upstream for option A.

Update:
- Merged some patches in xsettings-kde (https://github.com/KDE/xsettings-kde/commits/master). Strangely I only see them showing up on the github mirror.
- Apparently this setting isn't exposed as an xsetting. Asked why at https://bugzilla.gnome.org/show_bug.cgi?id=688524.

Update:
- GTK+3.x fixed: https://git.gnome.org/browse/gtk+/commit/?id=5cbc247c08129e3bad290d9cdc8e881f9105ac3b
- xsettings-kde fixed: https://quickgit.kde.org/?p=xsettings-kde.git&a=commit&h=fa3970dce66d9f19c52e5ed4777dea3bb723f982 (+ brown paper bag fix)
- added gtk+3.x patch in gtk+3.0-3.19.7-2.mga6
- added xsettings-kde patch in xsettings-kde-0.12.3-10.mga6

Note that I didn't add a Mageia specific patch to gtk+3.x for having it check for KDE as was my idea in comment 17. Did figure out the standardized environment variable; XDG_CURRENT_DESKTOP.

Thanks for the fixes, Olav :-)

I'm very glad FF now not only works well (scrollbar, filling out a field), but that it starts normally instead of only after a long delay.

Plasma5 looks OK here, after logging out and back in. I wasn't aware of major gtk+3 related problems with it, though, unless the often invisible netapplet icon was related. It is visible now.

CC: (none) => marja11

Um, FF scrollbar is still the same for me (gtk+3 behavior).  Was rgere something I needed to do other than rpmi --auto-update >

(In reply to Frank Griffin from comment #30)
> Um, FF scrollbar is still the same for me (gtk+3 behavior).  Was rgere
> something I needed to do other than rpmi --auto-update >

It's pretty difficult unless you give me more details.

First off:
- What desktop environment?
- Cauldron?

(In reply to Olav Vitters from comment #31)
> (In reply to Frank Griffin from comment #30)
> > Um, FF scrollbar is still the same for me (gtk+3 behavior).  Was rgere
> > something I needed to do other than rpmi --auto-update >
> 
> It's pretty difficult unless you give me more details.
> 
> First off:
> - What desktop environment?
> - Cauldron?

KDE and Cauldron, up to date.

Weird. Is xsettings-kde installed and running?

Ping? Is xsettings-kde installed and running?

Sorry, somehow I missed comment 33.  xsettings-kde is installed, and according to ps it is running.

Move this report to a Mga7 tracker (which doesn't mean it is forbidden to work on it now)

Blocks: 15527 => 18932

Just as an aside, I recently had a reason to research an openSUSE install for a customer, and both tap-to-click and the scrollbar behavior was exactly as I expected (enabled, and gtk+2 behavior)

I use mate (since it started, to replace gnome2), and frequently I run into the gtk3 scroll bar behavior.
It is highly dysfunctional in a list or document with a large number of pages, which I frequently encounter.

On a totally up to date mate desktop, with no other desktop installed.
So whatever 'fixes' have been implemented simply don't work.

I suggest that gtk3 behavior for scroll bar be reversed globally for mga, and that if a gnome session is started, during the session the gtk3 scroll bar behavior be reactivated for gnome.
This will have the advantage of ensuring coherent behavior in the non-gnome desktops (which I understand all want the traditional gtk2-type behavior).

@Olav
Wouldn't this be doable ?
If so, it would solve the problem for all desktops with the minimum of fuss.

CC: (none) => andre999mga

(In reply to andré blais from comment #38)
> On a totally up to date mate desktop, with no other desktop installed.
> So whatever 'fixes' have been implemented simply don't work.

For KDE I've implemented the behaviour in xsettings-kde. Other desktops should do something similar and direct GTK+ to behave whatever they want. To make that happen, suggest to file a bug with XFCE. The reported behaviour within KDE I've fixed, so marking this as fixed.

Resolution: (none) => FIXED
Status: NEW => RESOLVED

I don't see how you can consider this fixed if you only fixed it for KDE. Nothing in Summary or Comment 0 suggest a KDE-only defect.

(In reply to Olav Vitters from comment #39)
> (In reply to andré blais from comment #38)
> > On a totally up to date mate desktop, with no other desktop installed.
> > So whatever 'fixes' have been implemented simply don't work.
> 
> For KDE I've implemented the behaviour in xsettings-kde. Other desktops
> should do something similar and direct GTK+ to behave whatever they want. To
> make that happen, suggest to file a bug with XFCE. The reported behaviour
> within KDE I've fixed, so marking this as fixed.

Firstly, as noted in comment #40, the bug report was not restricted to KDE, so the fix for KDE does _not_ fix the problem, so reopening.

With all due respect to Gnome3, since it is the only desktop that wants the changed scroll behavior, the resolution suggested in comment #38 is the most appropriate.
i.e., revert the change in gtk+3 globally for mga, then whenever a Gnome3 session starts, redo the change for the Gnome3 session.
That way, every desktop gets the default behavior that is favoured by the desktop.
As noted in comment #38, for long lists or very large files, the new behavior introduced by the gtk+3 scroll change is dysfunctional.

The alternative to this sort of solution is dropping gtk from other desktops, and non-Gnome applications.  Not sure that is what gtk developers want.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

> I wholeheartedly support this bugreport.

  +1

Having recently moved over to Mageia-6 I could not understand why using he scrollbar in LibreOffice Writer had become different - and less convenient.

I now see why...

CC: (none) => maurice

I am also adding my comment/voice to this bug. 

Restoring conventional behaviour of scrollbars. ...

As a Linux distribution decision, Mageia could then presumably introduce
a script in the updates routine where it could institute these default
settings for the distribution? I gather from my 40 clients using Mageia,
that the overall feeling is that they would prefer to use the slider in
its more conventional way rather than the new GTK default. This would
put the behaviour more in line with what the rest of the world is using
by default under the Win and Mac systems.

I am not sure that we, as Mageia proponents, are making any friends when
users are confronted with different behaviour of the scroll bars, we are
more likely frustrating our newer users and giving then a little
negative feeling of using our distro. IMO, Mageia should have a more
homogeneous user experience with scrollbar usage.

Cheers,

Marc

CC: (none) => marc

hi,

this is planned to be fixed and an update to mga6 will be done when fixed.

Olav any idea how to force breeze theme in Plasma for gtk2 applications ? ( gimp, filezilla, etc ) ?

CC: (none) => mageia

(In reply to Nicolas Lécureuil from comment #44)
> hi,
> 
> this is planned to be fixed and an update to mga6 will be done when fixed.
> 
> Olav any idea how to force breeze theme in Plasma for gtk2 applications ? (
> gimp, filezilla, etc ) ?

Will the fix be universally applied to whichever theme a user will pick in the Plasma settings? For example, if one were to choose any other theme than "Adwaita", will the fix also be applied to any other theme?

Looking forward to the fix.

Marc

(In reply to Felix Miata from comment #40)
> I don't see how you can consider this fixed if you only fixed it for KDE.
> Nothing in Summary or Comment 0 suggest a KDE-only defect.

Good to spot that! I've changed the summary to accommodate. Note that as per my previous comments, GTK+ should be directed via an xsetting to behave differently. That's not unto GNOME maintainers.

Feel free to reopen this bug btw.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED
Summary: Scrollbar behavior is not consistent between GTK+3 apps and the rest => GTK+3 app scrollbar behaviour is inconsistent within KDE/Plasma vs other apps

Olav, there was no mention of KDE or Plasma until you brought it up in comment 12. This problem is not limited to KDE/Plasma, so it's only fixed WRT KDE apps. When I start Gnumeric in a TDE or IceWM session, scrollbar behavior is the unintuitive new unwanted Gnome behavior, inconsistent with TDE's and other non-GTK3 apps.

Status: RESOLVED => REOPENED
Summary: GTK+3 app scrollbar behaviour is inconsistent within KDE/Plasma vs other apps => Scrollbar behavior is not consistent between GTK+3 apps and the rest
Resolution: FIXED => (none)
Whiteboard: (none) => fixed kde/plasma

(In reply to Nicolas Lécureuil from comment #44)
> hi,
> 
> this is planned to be fixed and an update to mga6 will be done when fixed.
> 

And in the installer for MGA7 ?  As we've established that users get confused by this, having the first thing they see in their MGA experience confuse them is not a good thing...

The installer has two different scrollbar behaviours?!?

(In reply to Olav Vitters from comment #49)
> The installer has two different scrollbar behaviours?!?

Well, it uses gtk+3, and at one point it was exhibiting the new behavior, e. g. for multiple language selection.  This might have gotten fixed silently, but this was discussed back in comment#20.

Is there a Mageia-6 fix for this irritating retrograde scrollbar behaviour?

Otherwise I'm quite happy with Mageia-6!

Resetting assignee. As explained enough times, GTK+ makes this configurable via xsettings. It works for GNOME. I fixed it for KDE. If this is troublesome for some other desktop, those maintainers have the ability to change it. A proper change is xsettings, like I did for KDE. Not overrides or ini files!!

Status comment: (none) => The scrollbar behaviour of GTK+ can be controlled per desktop. If another desktop wants different behaviour it's up to the desktop to do so.
Assignee: gnome => bugsquad

(In reply to Felix Miata from comment #47)
> Olav, there was no mention of KDE or Plasma until you brought it up in
> comment 12. This problem is not limited to KDE/Plasma, so it's only fixed
> WRT KDE apps. When I start Gnumeric in a TDE or IceWM session, scrollbar
> behavior is the unintuitive new unwanted Gnome behavior, inconsistent with
> TDE's and other non-GTK3 apps.

People again making me a TDE, IceWM developers.

If you assign this to GNOME, then either I should have the ability to close the damn bug (WONTFIX) or whatever, or it should NOT be assigned to GNOME.

These reopen games make me utterly pissed off!

Please stop doing these re-open games. If you want something fixed, the behaviour of pissing people off is utterly pointless.

I utterly detest this bugreport. I don't want it in any of my buglists. Either I can decide on things or I don't in which case I do NOT want to see the bug.

These reopen games... unfortunately the newest comment made me see the mess again. I was planning on ignoring it entirely... fuck :-(

"Ignore Bug Mail" setting: Yes!!  (again: I'm never going to work on this)

CC: olav => (none)

I think part of the confusion here is that at least two of the most popular apps - FF and TB - either don't use GTK+3 or else deliberately reset behaviors to their own preferences.  I chronicled the needed changes to their prefs.js at one point, but I should have copied it here.  I'll look for the original post.

So, if the primary use of GTK+3 (or pseudo-GTK+3) apps in other desktops is one or both of these, users would conclude that Olav's fix doesn't work when, for all other GTK+3 apps, it does.

Still, if for no reason other than lower impact of a fix, I think the point is well taken that if every other use of GTK besides GNOME in MGA wants the old behavior, the sensible thing to do would be to globally change it in GTK and then reset the defaults in GNOME initialization.  That would cover the installer as well.

Of course, that doesn't cover FF/TB.  Perhaps these could be fronted by a shell script which checks the DE and adjusts the prefs.js accordingly.

If done correctly, this should give GNOME users exactly what they want.  Presumably the GNOME DE allows GNOME users to customize these settings under the assumption that without customization they would get the GTK defaults.  Resetting the defaults during initialization would then apply their customizations (if any) to the real GTK+3 defaults, as expected.

Here's the original post:

***********************************************************

Effectively, they switched the effect of mouse button 1 and mouse button 2 on the scrollbar.

Supposedly, this can be reverted in general by:



in /etc/gtk-3.0/settings.ini set

[Settings]
gtk-primary-button-warps-slider = false


in /usr/share/themes/Adwaita/gtk2.0/gtkrc comment out

gtk-primary-button-warps-slider = 1


This doesn't work for TB and FF because they "do it themselves", but you can go into both of their prefs.js and set

user_pref("ui.scrollToClick", 0);

For the full description see http://kb.mozillazine.org/Ui.scrollToClick .

> Having recently moved over to Mageia-6 I could not understand why using he 
> scrollbar in LibreOffice Writer had become different - and less convenient.

  This really is bothersome...

How can LO Writer be persuaded to revert to the previous mode?

Add a libreoffice.sh file to /etc/profile.d/ with the following line:

export SAL_USE_VCLPLUGIN=gen

which will get you non-gtk3 behavior.  Another approach is to install the libreoffice-gtk2 package, and instead use:

export SAL_USE_VCLPLUGIN=gtk

Just tried that:

 cat /etc/profile.d/libreoffice.sh
# Added as suggested in https://bugs.mageia.org/show_bug.cgi?id=17185
# to get non-gtk3 behavior of scrollbar
export SAL_USE_VCLPLUGIN=gen

- and re-booted, but LO Writer still moves to top of doc if click above the position marker in scrollbar.

Anything else I should have done?

If you open a terminal window and type "set | grep VCLP" do you get any hits ?

If not, your libreoffice.sh is not being executed, probably because the executable bit isn't on.  Try
    chmod +x libreoffice.sh

And you shouldn't need to reboot, just log out and back in.

FWIW I tested this by doing the export in a terminal window and then typing "libreoffice", but the above should have the same effect.

Did that (incl. logout/in) and checked it is now marked 'executable', but still no change in behaviour:
  Clicking above/below the position marker in the scrollbar shoots it way back or forward in the document (e.g. p.264-->p.80-->p.10).

So still have to use PageUp or PageDown key to see adjacent pages.

Perhaps I'll just have to come to terms with that. :-(

>If you open a terminal window and type "set | grep VCLP" do you get any hits ?

Did you try this ?

>FWIW I tested this by doing the export in a terminal window and then typing "libreoffice", but the above should have the same effect.

How about this ?

$ set | grep VCLP
SAL_USE_VCLPLUGIN=gen

$ export SAL_USE_VCLPLUGIN=gen
[mab@newpc ~]$ libreoffice
[mab@newpc ~]$

So how did LO behave when you launched it from the command line above ?

Sadly, no - same new problem...

I don't know what to tell you.  I had the GTK+3 behavior in LO until I did the export "gen" in a terminal window and ran LO from the command line.  I had previously installed libreoffice-gtk2, and "gtk" worked as well.  I uninstalled libreoffice-gtk2 and tried again, and "gen" gave me the gtk2 behavior but "gtk" gave me the gtk3 behavior.

I haven't yet tried logout/login (although I have added the /etc/profile.d script), but I'll post here again when I have.

Maybe you should try installing libreoffice-gtk2 and trying again.

I scoured the mailing list archives and this bug looking for the DE that Maurice is using, to no avail.

Nevertheless, I've tried on host gx62b, formerly mga5 running KDE4 but now after eradicating KDE and urpmi upgrading to mga6, then installing TDE, to employ all the Google-suggested ways I could find to override the miserable default GTK3 scrollbar behavior in LibreOffice Calc 5.3.4-2.3. My effort so far has been fruitless. 'export SAL_USE_VCLPLUGIN=gen' prior to 'libreoffice-calc' via script in Konsole does not help either.

The override with Firefox ui.scrollToClick is working as expected.

This bad scrollbar behavior does not exist with LibreOffice 5.3.5.2 on openSUSE 42.3 running KDE3.

> Maybe you should try installing libreoffice-gtk2 and trying again.

  That did the trick!  (It also installed libreoffice-x11, I see.)

Ah, back to normal...  :-)

BUT, the icons in the LO Writer toolbars a TINY now!

How does one enlarge the icon size there?

(In reply to Maurice Batey from comment #68)
> > Maybe you should try installing libreoffice-gtk2 and trying again.
 
>   That did the trick!  (It also installed libreoffice-x11, I see.)

> Ah, back to normal...  :-)

Same for me WRT scrollbars if preceding startup with export SAL_USE_VCLPLUGIN=gen. Icons and menu text remain too tiny.

So how do we get menu bar contents enlarged?!  Help...

For icons, Tools -> Options -> LibreOffice -> View.

For menu font size, you can try playing with https://ask.libreoffice.org/en/question/71652/how-to-change-font-size-for-dialogs-not-just-menus/

> For icons, Tools -> Options -> LibreOffice -> View.

  Jackpot! Just changed 'Automatic' to 'Large'.
Also preferred Oxygen icons, so happy bunny now!

(Was also happy to see the 'Saving in progress' live bar back along the bottom.)

Thank you, Frank!

Also, I notice that "gen" uses very small menu fonts while "gtk" uses larger ones.

Instructions at the URL in comment 72 are a clumsy kludge. :-(

Inserting 'export SAL_USE_VCLPLUGIN=gtk;' before 'libreoffice --calc' in the menu starter entry produces the desired LibreOffice UI fonts matching DE's fonts. So I tried instead adding 'export SAL_USE_VCLPLUGIN=gtk' variously to ~/.profile, ~/.bash_profile, ~/.bashrc, and /etc/profile.local, none of which had the desired effect. The variable did appear in set output only when put in ~/.bashrc.

What's the procedure to set SAL_USE_VCLPLUGIN=gtk globally so that every users' LibreOffice menu entries do not need to be reconfigured manually in order to have the DE's UI font configuration respected?

I'm not sure what executes /etc/profile.local, if anything.  The current MGA architecture uses /etc/profile which executes every readable *.sh file in /etc/profile.d, so that's where I put a libreoffice.sh with the export in it, and it works fine, with "set | grep VCLP" showing the assignment.

I've lost track of the arcane rules for when .profile and the various .bash* profiles are executed, but if you want the assignment to be global I'd forget them and go with the /etc/profile.d approach.

[...]
> People again making me a TDE, IceWM developers.
> 
> If you assign this to GNOME, then either I should have the ability to close
> the damn bug (WONTFIX) or whatever, or it should NOT be assigned to GNOME.

I think Olav has a point.
It is really a GTK problem, & not GNOME.
So I think we should fix the GTK3 default for Mageia, and let Olav revert it for GNOME.

That way every desktop gets what it wants. 

Keep in mind that GTK developers recognized this change in behavior as problematic, and provided an easy way to change the default.

Created attachment 9732 [details]
108 DPI screenshot on TDE desktop

(In reply to Frank Griffin from comment #76)
> I'm not sure what executes /etc/profile.local, if anything.  The current MGA
> architecture uses /etc/profile which executes every readable *.sh file in
> /etc/profile.d, so that's where I put a libreoffice.sh with the export in
> it, and it works fine, with "set | grep VCLP" showing the assignment.
Placement in /etc/profile.d/ works, but on closer inspection, LO is not precisely respecting TDE font settings (all Sans Serif in KControl, which fc-match shows to be Droid Sans). The screenshot shows obvious differences between glyphs in LO and Konsole. I can't be sure whether the font family is different, or the size is a half size larger in LO. I lean strongly toward different family. Firefox doesn't even come close, but that's clearly WONTFIX bug 21201 damage.

> For menu font size, you can try playing with https://ask.libreoffice.org
> /en/question/71652/how-to-change-font-size-for-dialogs-not-just-menus/

Could not get anywhere with that!

The LO Writer toolbar icons are a good size now, but the text in the toolbar and options window are TINY, and nothing I have tried has changed them.

I have to lean forward closed to the screen to read the lesser-used ones...

(In reply to Maurice Batey from comment #79)
> the text in the toolbar
> and options window are TINY, and nothing I have tried has changed them.
 
Did you try 'export SAL_USE_VCLPLUGIN=gtk' as Frank explained and works for me?

> Did you try 'export SAL_USE_VCLPLUGIN=gtk'

Thank you for reminding me, Felix!

My 1st attempt was to set 'export SAL_USE_VCLPLUGIN=gen' in /etc/profile.d/libreoffice.sh, but when that didn't work I installed libreoffice-gtk2, which did.

But I forgot to change the above entry to "....=gtk" in libreoffice.sh, which I have now done and I now see larger fonts in the toolbar etc.  :-)

> But I forgot to change the above entry to "....=gtk" in libreoffice.sh, which I > have now done and I now see larger fonts in the toolbar etc.  :-)

No, that was a mistake; I'm now back at square 1 with retrograde scrollbar!
Will reverse that and put up with small toolbar fonts...

On MGA6/TDE14.0.4 host gx62b with packages libreoffice-gtk2, libreoffice-gtk3 and libreoffice-x11 installed, I have /usr/local/gtk-3.0/settings.ini containing:
	gtk-primary-button-warps-slider = false
I removed ~/.config/libreoffice and /etc/profile.d/libreoffice.sh, rebooted, started TDE session, and opened LibreOffice Calc from unmodified TDE menu to find:
1-SAL_USE_VCLPLUGIN unset (in Konsole)
2-scrollbar behavior bad (GTK3's scroll-to-click "warped" slider)
3-UI text unacceptably small
4-toolbar icons OK

I restored /etc/profile.d/libreoffice.sh (containing only
	export SAL_USE_VCLPLUGIN=gtk
), quit TDE session, started new TDE session and LibreOffice Calc to find:
1-SAL_USE_VCLPLUGIN=gtk (in Konsole)
2-scrollbar behavior good (old/GTK2/TDE/KDE scroll one page per blank space click)
3-UI text wrong (though quite acceptable in size)
4-toolbar icons OK

@Maurice

Comment 81 or 82: which is it ?

@Felix

>3-UI text wrong (though quite acceptable in size)

What's wrong with it ?

(In reply to Frank Griffin from comment #84)
> >3-UI text wrong (though quite acceptable in size)
> What's wrong with it ?
Minor, described in comment 78, observable in the attachment.

(In reply to Felix Miata from comment #85)
> (In reply to Frank Griffin from comment #84)
> > >3-UI text wrong (though quite acceptable in size)
> > What's wrong with it ?
> Minor, described in comment 78, observable in the attachment.

Oh, yeah.  From what I read the export setting is supposed to set its information from the DE system settings, but how well it does that I couldn't say.

I still don't understand why if the scroll setting is correctly set in both GTK2 and GTK3 and if the export specifies one or the other that the scrollbar isn't correct in LO using GTK3.

The SO refused to use Mageia-6 as the top/bottom arrows are missing from the scrollbar.

The following fix seems to solve the problem:

 Create a file called ~/.config/gtk-3.0/gtk.css and add:

    *{
    -GtkScrollbar-has-backward-stepper: 1;
    -GtkScrollbar-has-forward-stepper: 1;
    -GtkRange-slider-width: 13;
    }

(There was no such file in our Mageia-6.)

The scrollbar looks a little narrow, so will experiment with the slider-width setting.

This does not, however, solve the slider bar problem; clicking either side still sends focus to top or bottom, instead of up/down 1 page...

(In reply to Maurice Batey from comment #87)
>  clicking either side still sends focus to top or bottom, instead of up/down 1 page...

SAL_USE_VCLPLUGIN=gtk as described in several comments here (e.g. #83) does not work on your SO's installation?

Apologies!

The SO was complaining about FIREFOX; not clear how to apply above solutions also to Firefox as well as Libreoffice...
  (Is it as simple as having a 'firefox.sh' in /etc/profile.d?)

The "~/.config/gtk-3.0/gtk.css" approach brought the top/bottom arrows back in Firefox, and I wondered if there might be a similar solution to revert Firefox's scrollbar to former 'page up' 'page down' clicking on scrollbar...

[Please excuse haste; am in process of preparing for hospital on Thursday.]

The problem I had with the solution for Libreoffice was that the LO menu fonts shank to *tiny*, and I was unable to restore them to normal size.

> (Is it as simple as having a 'firefox.sh' in /etc/profile.d?)

  Seems not - just tried it...

Granted, it's getting confusing to read this bug.  Here's a synopsis:

Comment#10 / comment#56 tells you how to revert the scrollbar behavior in gtk+3 across the board.  That leaves FF, TB, and LO, which don't go by what is set in gtk.

For FF and TB, you need to change each one's prefs.js as described in comment#56.

For LO, you can't *just* affect the scrollbar behavior.  The best you can do is roll it back to *not* use gtk+3 at all.  This is described in comment#75 through comment#81 .  What seems to work for everyone is exporting SAL_USE_VCLPLUGIN=gtk in a /etc/profile.d script *and* having libreoffice-gtk2 installed.

In Firefox, the about:config setting

	ui.scrollToClick;	0

is required to recover traditional single page up/down behavior. Alternatively,

	user_pref("ui.scrollToClick", 0);

can be included in a plain text file named user.js in the Firefox profile directory (by default it does not exist - you must create it if you want it). The latter method has the same effect as the first, but will reset it on application start each time if it had been changed.

(In reply to Frank Griffin from comment #56)
> This doesn't work for TB and FF because they "do it themselves", but you can
> go into both of their prefs.js and set
 
> user_pref("ui.scrollToClick", 0);
 
> For the full description see http://kb.mozillazine.org/Ui.scrollToClick .

Mozilla recommends not editing prefs.js directly. Configuration edits should be applied either via about:config, or user.js.

What is the status of this bug report, is it still valid?

If so (also since this report already contains over 90 comments), it would be better to file one or more (depending on how many applications are affected) new bug reports.

Keywords: (none) => NEEDINFO

I've been using the above documented workarounds for quite a while now, so I have no idea what behavior a vanilla system exhibits at this point.

I suppose since FF, TB, and LO aren't affected by the global GTK settings, they should have separate bugs.

Open questions on this bug are whether to change GTK+3 globally and revert it for GNOME or require each DE to change it itself, and what to do about the installer.

Keywords: NEEDINFO => (none)

If ui.scrollToClick in Firefox ESR52 or 58 or SeaMonkey 2.49.2 is unset (no ui.scrollToClick line in prefs.js or in about:config),

		gtk-primary-button-warps-slider = false

in /etc/gtk-3.0/settings.ini running TDE in Mageia 6 on host big41 produces expected/gtk2/historical behavior. I've tested elsewhere also - having the same line in ~/.config/gtk-3.0/settings.ini works too.

Even with this workaround, GTK3 remains a usability handicap because of bug 21201 .

See also:

https://bugzilla.mozilla.org/show_bug.cgi?id=1269172 NEW SeaMonkey
Behaviors transposed for {Click on Scrollbar} and {Shift+click on Scrollbar}

https://bugzilla.mozilla.org/show_bug.cgi?id=1444223 NEW Core
Honour cross-platform AND system AND user scrollbar preferences

Resolution ?

Ping ?

It is still a problem with unadapted mga6.
The workarounds all work, except for LO

For LO, adding
  /etc/profile.d/libreoffice.sh
with the line
  export SAL_USE_VCLPUGIN=gtk

as well as installing the package
  libreoffice-gtk2
  
only works if invoke libreoffice from the console,
and not if click on a libreoffice file, which is the usual way of opening a libreoffice file.
I even tried inserting the export text with env as an option to click on for a LO file, and it just loaded libreoffice with the unwanted gtk3 behavior.

So still very awkward to use with libreoffice.

Note that the problem with LO outlined in comment 100 may be related to LO version 5.3.* (current in mga6) requiring libreoffice-gtk3 .

Internet posts indicate that libreoffice-gtk3 could be uninstalled with version 5.2.* (on linux, likely RedHat).

Hi,
New classical M7final x86_64, xfce desktop.

This is not new, but still present.  For a long time I've been seeing errors where data in an MCC window extends below the lower frame.  Usually there is a slim hint of the scrolling bar just visible on the right, or if its not visible, hovering the mouse in its vicinity will bring up the scroll bar.

Problems:
1. The scroll bar sometimes will not come up with cursor in its vicinity.  e.g. at this instant I'm in MCC Services and daemons, lowest line showing is dm-event, no scroll bar to access lower ones.

2. As I've known from prior behaviour, easily worked around by now clicking on any of the displayed lines of text, when the scroll bar will reappear for a moment and can be displayed by hovering the mouse cursor in its position again.  Still, its a bug.  I've seen repeated discussions in the 'discuss' forum over time with folk at cross-purposes, probably secondary to this bug.

3.  When the scroll bar is available, its behaviour is unexpected.  In many environments, clicking in the empty space above or below the scroll-bar slider results in the display shifting in a controlled page-up or page-down increment.  Not so with MCC - the scroll-bar jumps to current mouse position.  One can guess at the proportion of the alphabet to traverse to get near intended position, but its hit and miss.  Would be much better obeying standard convention as above.

I suspect this may not be just in MCC?

I've discovered this bug 17185 where gtk3 issues extensively discussed, and re-opened it for further review.  My points 1 & 2 above are maybe a related but separate issue.

CC: (none) => tablackwell

Ping ?

(In reply to Frank Griffin from comment #103)
> Ping ?

Well, I can tell you this, in Mageia 7, there is no libreoffice-gtk2 package, only libreoffice-gtk3.  So these work-arounds no longer work for LibreOffice.  The only thing that works is to uninstall libreoffice-gtk3 so LibreOffice will revert to the built-in/generic controls.  And that will also mean using the generic file dialogs, different looking menus, etc.

I installed the ClassicLook theme, and that did change the look of the scrollbar to be the "classic" look/layout in both LO and Firefox.  But clicking still warps in both.  gtk-primary-button-warps-slider=false  seems to just be ignored system-wide, whether it is in /etc or $HOME settings.

Firefox (I am using vanilla 79 at the moment that I install manually) will return to classic behavior if I manually add the ui.scrollToClick=0 in about:settings (the setting has to be created, it is no longer built-in).  But nothing I tried will fix LibreOffice 6.X while in KDE under Mageia 7.

This is very frustrating and ridiculous.

CC: (none) => crxssi

(In reply to M D from comment #104)

> So these work-arounds no longer work for LibreOffice.  The only thing that works is to uninstall libreoffice-gtk3 

Oops, that was a different system.  You CAN'T remove libreoffice-gtk3 now, because in Mageia 7, they made everything dependent on that package!  (That is not the case with vanilla LibreOffice, you can choose to not install the "kde-integrations" package.

So the only remaining option is the   export SAL_USE_VCLPLUGIN="gen"  kludge.

The scrollbar behaviour of GTK+ can be controlled per desktop. If another desktop wants different behaviour it's up to the desktop to do so.

As far as I know, if there is a change from upstream (GTK3 developers), it is not our responsibility. Us (downstream, Mageia), as we are not a particular desktop-distrospecific, we can't propose a fix for an upstream change.

So no. Definitely, we won't fix it. It is not a bug from a Mageia perspective. It is a GTK3 behaviour, so move on. You dislike it? Please report upstream here:

https://gitlab.gnome.org/GNOME/gtk/-/issues

Mageia Bugsquad

CC: (none) => ouaurelien
Resolution: (none) => WONTFIX
Status: REOPENED => RESOLVED

I disagree.  Upstreams do stupid things sometimes because they live in their own little world where they have tunnel vision about what they care about.  A distribution's job is to integrate a whole bunch of things made by developers that may not all have a shared vision into one consistent product.  Sometimes that means reverting stupid upstream decisions, or at least giving users an easy way to change them.

Resolution: WONTFIX => (none)
Status: RESOLVED => REOPENED

Thanks all involved here.
GTK3 will be replaced by GTK4 upstream. Seems there will not new development on this library, upstream relies only on GTK4 for now.
XFCE just finished his transition to GTK3, also.

For this BR, can user tell me which GTK3 apps do have wrong scrollbar behavior and on which Desktop environment?

For me, Mageia 8, Plasma 5.20, Firefox seems to behave like Dolphin. Libreoffice now uses KF5 based backend under Plasma so I don't seen any remaining GTK3 apps on this Desktop env.
I don't use other Desktop. I don't use other GTK3 apps.

Again:
(In reply to Olav Vitters from comment #52)
> Resetting assignee. As explained enough times, GTK+ makes this configurable
> via xsettings. It works for GNOME. I fixed it for KDE. If this is
> troublesome for some other desktop, those maintainers have the ability to
> change it. A proper change is xsettings, like I did for KDE. Not overrides
> or ini files!!

Assigning globally.
Nothing to do in Bugsquad.

Whiteboard: 7final => (none)
Target Milestone: Mageia 8 => Mageia 9
Assignee: bugsquad => pkg-bugs

Hi Aurelian,

Summary is in comment#92.  This isn't an Olav or GNOME issue, it's an issue owned by FF, TB, LO, and our installer.  Basically, if non-GNOME MGA components want to use GTK+3, it's their responsibility to make it work like GTK+2.  For FF, TB, and LO it's their responsibility because they mimic GTK on their own and don't obey the GTK config file options.  They all have custom workarounds which may may morphed over time.  But my primary concern is the installer, which has no workarounds whatsoever, either for this issue or for the related "no tap-for-touch" support which is just another mis-behavior we allow to be implemented because somebody upstream dislikes it.  Other distros override it (SUSE), but for some reason we choose to leave it in place out of either respect or laziness in spite of the fact that it flies in the face of what users expect.

Hmm, no, I have to backtrack and include all of the DMs (at least for the tap-to-touch) which no longer have any configuration dialogs and disable tap-to-touch by default.  Ahh, for the days of GDM2 which could actually be configured.