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.
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
@devs, is there really no less painful way to restore that than adding it back in to every single affected app?!
Correct. Patching GTK is not sustainable and would break between distros, also breaks GNOME compatibility.
The functionality was removed from GTK for reasons that I don't agree with, and adding it to a more central lib within MATE was considered, but would have still required as many changes as the current approach. This way at least the code is consistent across apps and leaves the possibility of modifying any behavior on a specific app if necessary.
It was a trade off. Filing bugs for each instance is just a way of tracking what's done and what's not.
2 Likes
I keep thinking of MATE's GTK interaction as being something where you could reasonably just rebase against upstream periodically, and in that scenario a trivial change to GtkNotebook wouldn't be likely to hit a conflict in years. Clearly that's not the case though.
If devs don't know about it then it wouldn't get fixed
Sure - in case it wasn't obvious already, I've been a developer myself for decades - but it's not like it was a subtle bug, and between the massive libinput changes that were also going on at the time, and the Qt bugs with mousewheel adding the possibility of it being a VirtualBox issue, it made more sense for me to just let all that settle down first, especially since GTK3 meant I wasn't going to switch to 18.04 any time soon anyway.
I'll try a LIVECD over the weekend just to rule out VBox, and go from there. Thanks.
Rebasing upstream is actually the problem, unless you control the distro (Ubuntu, Fedora, etc), you wouldn't be allowed to do that.
Also, plenty of people run multiple DEs on the same machine, and most use GTK, so they could break too
1 Like
Ah, right - only Canonical / Red Hat / etc get to do that.
I'd have thought at this stage in GTK3's life - other technical issues aside, and IDK what those would be - that it would be fine to maintain a fork and just static link the MATE apps against that. But that's also because I'd rather have some apps work well rather than all of them be worse, regardless of the inconsistency, which isn't a position a maintainer can really have. (Though it hasn't stopped Firefox etc from doing exactly that, making what for most people is the most used app they have acting differently to the rest of the system!)
I think "plenty of" people using multiple DEs is probably biased by the circles you move in and the MATE / Mint relationship, but in the abstract I don't think it really matters: nobody expects e.g. KDE and GNOME to offer the same functionality or behavior as each other, and users are realistically learning the DE itself, not Qt or GTK. But it also doesn't matter how true my comment is, because unless there's a good way to run multiple versions of GTK3 on a machine on a per-DE basis, it's all academic.
unless there's a good way to run multiple versions of GTK3 on a machine on a per-DE basis, it's all academic
True that
Also a maintenance nightmare. The GNOME/GTK teams are well staffed and have great incentive to keep the entire thing running well, so as much as I disagree with some (many?) of their decisions, they do an amazing job, and I'm more than happy just backporting some things and fixing others on our side.
The MATE team is just a handful of devs doing this for love and beer; the GNOME/GTK teams are a well funded group of paid professionals (and many volunteers) doing this, in part, to maintain profitable enterprise contracts.
4 Likes