That I agree on! GNOME 3 has made an enormous change compared to what was done to Windows; it's no wonder so many people moved away...
1 Like
Huh? I'm uisng a pair of 43" 4K UHD displays just fine and have had four 1080p Virtualbox VMs displayed on one screen.
Under GTK3 (16.10 onwards), it does. GTK2 (16.04, which I'm on) doesn't natively support HiDPI. Plus, I've got some apps that don't scale properly (GIMP, Inkscape) without resorting to "hacks", until they update their code to GTK3.
SADLY, Gnome is brown-nosing RedHat and Pottering all the way... and we'll end up with a horrible OS that is not GNU/Linux any more, but "Red Hat systemD/Linux", with Gnome embedded in it (cursed are the ones that use another DE!) and no freedom of choice.
@Gonzalo_VC, what does SystemD have to do with GTK? Also, I would recommend reading the copyright notice on 90% of the files in the MATE source code: the desktop environment you love was, and still is, contributed to by Red Hat engineers.
2 Likes
All those things are orbiting around the same spot. GTK - Gnome people are bowing to RH decides, and Potterting stuff, made for RH is becoming MANDATORY in Gnome, and polluting a lot of things in the ecosystem. MATE will (even now) suffer the non-freedom situation. Can you have Ubuntu (any flavor, any platform) without systemD?
I don't have an issue with SystemD as it's not limiting my options like GTK3. I don't agree with a number of the so called advancements of GTK3 that are more like regressions compared to GTK2.
It's for this reason that my upgrade to 18.04 may involve a switch to Qt and a complete change of distro.
4 posts were split to a new topic: GTK3: Changing the overlay/momentium scroll bar
Could you please have a look here: https://ubuntu-mate.community/t/human-gtk3-traditionalhumanized-theme-for-ubuntu-mate-18-04/
Lately I've been thinking a lot about the subject. It's no news that GNOME 2/GTK+ 2 crowns the perfect balance between configurability and elegance, but by this point it's crystal clear that its ideals are no longer in line with the current GNOME project and it's only going to get worse with GTK 4 as pointed out earlier.
I'm almost sure that we need a new toolkit, whereas it's a fork of GTK+ 2 or a reimplementation that draws from its concepts.
2 Likes
I think what we need is more developers...
GTK2 was great, GTK3 is better in many aspects, but they dropped things that not enough software used and that there were not enough people to maintain... GTK4 will be a continuation of that: better, but more specialized libraries for GNOME's use cases.
Forking GTK*, and/or forward-porting parts from "the good old days" sounds great in theory, but who's going to do it? Who's going to maintain it?
Off the top of my head, the MATE team is growing at a rate of, what, 1 developer a year? All volunteers too.
GNOME (and thus GTK) have hundreds of developers, many of which are paid to work on it. To expect them to stop and wait for us is unreasonable when we're the ones that chose this path.
I think what we're doing is fine: we backport what makes sense from GNOME, we add our own features every now and then, and we make wishlists to keep moving us forward. It works. We have an amazing desktop environment that makes us proud and happy. Some features will suffer with every upgrade, but we add other necessary ones too.
In the end, we do the best we can to keep things balanced between "traditional" and "modern". That's probably one of the hardest things to pull off, and yet that's where MATE really shines.
8 Likes
The root of it, I would guess - and this is purely gut feel: I haven't looked at the code - is the obsession with smooth scrolling and/or "momentum" scrolling that's appeared since 16.04. Experimenting with 19.04 today, after staying on 16.04 all this time, is just endlessly frustrating, because almost NOTHING works properly or well. But the scrolling issues are WAY up there, along with the filechooser amnesia.
I take it it's too much to hope that there's a #define lurking somewhere in the source to just turn it off and have 1 atom of input translate to one atom of movement again, instead of 0 half the time and 2d6 the other half?
The other thing I wanted to mention is this: https://aur.archlinux.org/packages/gtk3-mushrooms/
I expect you've long since seen it, but I only found out about it today and figured it was worth bringing up just in case. He admits he basically doesn't know how to code, but it might ease some of the burden occasionally?
Thanks for spotting the typo and mentioning gtk3-mushrooms. I haven't heard of that project till now. I'll have a little play at building it on Ubuntu and see how it goes.
If it works well, it might be worth creating a PPA to contain this patched GTK3.
gtk3-mushrooms certainly works nice for GTK apps I use on my main Manjaro (KDE) desktop.
I was experimenting and kind of compiled it on Ubuntu MATE 19.10, but it doesn't look like all the patches were working -- likely I haven't compiled or installed it properly. 
The experiment lies here if anyone wants to try and get it compiled/installed properly on Ubuntu MATE:
It's recently had a different maintainer, whom doesn't appear active at the moment. I created an issue suggesting the tab scrolling with mouse wheel patch (#25). Personally, I like this idea to install an alternate GTK3 package providing the desired "classic" functionality, even if it means carrying a warning label. 
Does anyone have any ideas about the mousewheel bugs? Those are now the last thing keeping me moving to 18.04 (and then hopefully on to 20.04 next year as well). Not the last thing I'd like to fix or see fixed, but the last absolute blocker for me.
I know Hutterer has been making a LOT of behavioral changes to libinput, but right now I can't tell if the utterly-broken mousewheel issues are because of that, or GTK3, or a combination of the two - but regardless of the root cause, the fact that the system randomly fails to respond to respond to wheel events is a real problem for me.
As far as I can tell from xev the events certainly seem to be happening reliably (though it's always hard to be truly sure) and my suspicion is strongly that it's just a GTK issue, especially since there's clearly been a rewrite of the pieces involved in e.g. Caja windows to scroll smoothly in response to thumb changes rather than just jump to them. (Which I personally hate and would very much like to be able to revert, since it does it in things like Pluma as well and makes it much harder to compare files in different documents as the scrolling is inconsistent, though that may just be a different aspect of the bug).
I can try to wander through the code next weekend, but since this bug has probably been there since 18.04 I'm hoping someone has dug into it already and might have found a workaround. (I've tried "gtk-enable-animations=0", but that doesn't fix it: it results in a weird hybrid mode where it usually jumps the way I want, but also randomly goes into smooth-scrolling mode still at times, with no apparent rhyme or reason to why it's picking one over the each time. And it ignores the settings completely if you use PageUp/Down, and always smooth-scrolls for that. ffs GNOME...)
One other question that springs to mind is, with the CADT apparently now preparing to inflict GTK4 on the world, what's the dev team's plan for that? Or is it not far enough along yet to start worrying about?
1 Like
What mouse wheel bugs are you referring to? Have you filed them with launchpad or github?
With regards to GTK4, there's not a whole lot to be done at the moment. It's a changing API still, so any changes done to MATE might need to be reverted anyway. Multiple GTK versions can coexist happily anyway, so this is a very low priority for now.
Today I have reported two bugs about tab scroll with mouse wheel:
but the list of affected programs is bit broader and we need to decide how should we follow MATE HIG:
If present on the mouse, the scrollwheel should scroll the window or control under the pointer, if it supports scrolling. Initiating scrolling in this way should not move keyboard focus to the window or control being scrolled.
If it supports both horizontal and vertical scrolling, perhaps suggest unmodified scrollwheel should scroll vertically, and<Shift>+scrollwheel should scroll horizontally.
Patching every app with GTK_NOTEBOOK may be difficult and ineffective.
And other problem is that non-MATE applications may not have these patches...
Weird - I could have sworn they were in this thread.
The mousewheel just randomly doesn't work at times, notably in caja windows (which I tend to scroll through that way a lot). Just now, I went through 4 clicks on the wheel in there and absolutely nothing happened at all. Then it suddenly "woke up" and started working.
If I switch to a different window (click to focus) but then hover over the caja window and scroll the wheel, it will almost always ignore the first event but then respond to subsequent ones. Give the caja window focus then switch away from it again and start over, and the first wheel movement gets ignored again.
I never filed a bug for it, for several reasons: because I couldn't imagine it not being fixed by the time I would have first considered actually switching to 18.04 (i.e. several months after release) ; because I've seen how the GNOME team handles bug reports, so it would have been a waste of time if GTK3 was the cause (which seemed likely) ; and because I didn't have the time to pin down exactly when it failed, since it does work properly sometimes - it's only just now that I noticed that it always misses the first event if unfocused, for example. "Sometimes it doesn't work" isn't exactly the sort of bug report that encourages even the most conscientious developers to spend time trying to reproduce and fix things. 
[GTK4] is a very low priority for now.
Thanks - that's what I was hoping to hear. 
Obviously, my bug is different to Norbert's - his has the advantage of being a loss of functionality 100% of the time rather than an intermittent problem.
@Norbert_X - unless you've already filed it, you're missing one for the fact that it also doesn't work for caja's document windows any more either.
But, hmm, that github link is interesting. This is a clear case of functionality being removed across the board, so it seems odd that you'd need more than one bug report or more than one (core) fix.
@devs, is there really no less painful way to restore that than adding it back in to every single affected app?! I mean, I get that you want as few diffs as possible against upstream GTK3, but that's an insane burden. You must have the patience of saints...
I never filed a bug for it, for several reasons: because I couldn't imagine it not being fixed by the time I would have first considered actually switching to 18.04
If devs don't know about it then it wouldn't get fixed
2 Likes