GTK3 regressions from a GTK2 perspective

To be honest, I am getting fed up of the way all major Linux desktops are going in terms of bloat and fat menus, window headers etc. From what i can see, GTK3 is behind much of it. But, I can't be sure because I lack the technical knowledge. I should stress, this is a personal issue and I am sure many people will find the latest desktops to be just fine for them and I have no problem with that.

My next install is going to be Openbox, pcmanfm desktop manager, Lxpanel and a modified Openbox menu pinned to that panel cos it has a nice menu editor called "obmenu", unlike Lxpanel's menu, which is a right bugger to edit. My main reason for using LXpanel is the easy capacity to have things like the clock and other indicators as well as buttons for windows.

It's basic and simple and works. It also has the advantage of being super fast and lightweight and I really do mean lightweight. The setup described above comes in at under 200mb on the Ram. I've been experimenting with the above in a VM for a few months now and it works great for me.

I realize the above setup is pretty esoteric and will certainly not be to the taste of most users and that's fair enough. That being the case, I would always recommend Mate as the desktop of choice for those wanting one off the shelf.

Why did GNOME team have to do any of this? Who there thought any of the above was a good idea?

I really dislike the direction GTK3 headed. Lots of things for GTK2 became broken in GTK3 and people have to basically start over with theming for it. These have been sad years.

Honestly, 18.04 has been nothing but regressions over 16.04 from my perspective. The way things are going you're going to have to pry 16.04 from my cold dead hands as it appears to be the last Ubuntu Mate release not infected with GTK3 and the limitations that come with it.

I understand it's not entirely the fault of the hard working Devs, but it's disappointing nonetheless.

If it's green or nothing, I'm going to KDE once I upgrade from 16.04.

Which is a shame as I absouotely love Ubuntu Mate.

I don't get why people hate gtk3, it's great as well as Mate.

I am not a big fan of CSD, but come on, some applications implement it right (usable).

Anyway, it's a global trend from all app developpers, on all systems, that would be hard or very costly to fight.

I don't think it is worth to fight this already lost battle.

I would prefer to see the Mate project continuing to focus on the fundamentals for a responsive and traditional desktop environment (panels, window management, workspaces, menus, file browsing, etc.), fix the bugs and get more momentum.

I feel I need to be more specific in my answer.

I am using almost none of the default utility that come with Mate, preferring superior, better maintained and accidentally GTK3 applications:

• Mate-terminal --> Tilix
• Atril --> Evince
• EoM --> EoG or Gthumb
• mate-calc --> gnome-calculator
• pluma --> gedit

Gnome-disk is already installed by default and it's great.

I only keep using Caja, because Nautilus really sucks and Nemo is not recent in the repos.

EDIT: I should add Engrampa, for its integration with Caja and because file-roller also sucks after the removal of some features (password setting).

I am feeling it's a dead-end. How the Mate community can continue to keep these forks on par with their newer alteratives?
Apparently, it's not going very well.

On the other side, I regret that some core components (panels, window managers, file browser) suffer from quite important and serious bugs that are not being fixed.

It's maybe an isolated opinion, but I don't care about basic utilities when I choose Mate. I care about having solid and configurable foundations.

Maybe the project should keep its resources to focus of them.

If you think GTK3 is bad, wait until GTK4 comes out. They already removed icons from menus because it's no longer fashionable.

All this make me think we're gonna have to start looking at Qt sometime in the future...

Agreed...

And I know little to no C++ to understand Qt than GTK anyway...

I only started using Linux around 2016. Before that I was a total ■■■■■■ when it came to programming and software and was a full-blown Windows user. So I don't know how GTK2 was in the good-old GNOME days, but I have fallen in love with MATE since coming across UM and have learned so much since then; and maybe because of that I don't see or feel all the nitty-gritty details that have regressed all over the years, but I have seen how stupendously GNOME 3 and/or GTK3 has been removing stuff to be a pleasant experience when I sit in front of my desktop.

And I understand the emotion behind of all the old users...

I have found MATE and UM to be reliable, and it works more than enough for me, despite the regressions.

I wish you did, but you don't. I've been on three desktops technically; GNOME 2.xx, GNOME 2.xx but modified as my own desktop and xsession, and MATE. All of them foundationally GTK 2, two of the three options impossible. Then there came the change where certain GTK 2 apps aren't feasible because you can't just change gnome to mate in config files and have it work.

Now with 19.04 I cannot install my preferred (and less error-prone) global EQ without pulling in prior libraries which no longer exist in Canonical's Disco repos. It's BS.

I'm tired of change. All the moving's wearing me out. It makes Windows' interface design, even with the modern changes they've made feel more stable. At least, ten years from now I'll still know how to use Windows.

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...

Huh? I'm uisng a pair of 43" 4K UHD displays just fine and have had four 1080p Virtualbox VMs displayed on one screen.

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.

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.

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/ 6
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?

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?

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...