Gnome says libinput should deal with scroll speed. Libinput says GTK+ should deal with it. Patches have been lying around for both but neither has gained any traction.
I like Gnome's DE in general but this issue showcases the rough edges of open source collaboration the Gnome project is infamous for.
Even KWin's (original?) implementation of the feature wasn't great and caused issues with applications, apparently: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4672#not... Broken as though it might be, at least they're trying something, which I appreciate more as an end user than the complete lack of scroll settings.
Why is it better than Gnome 2 then? This is what I prefer (it's called Mate now).
I've configured KDE Plasma to look almost identical to Mate (the defaults are similar to Windows, nice, but I prefer the Mate layout):
- top panel / bottom panel
- desktop switcher bottom right
- task bar on bottom
- desktop button bottom left
- clock top right
- app indicators top right
- app icon launchers on top bar
- app menu top left
It's not just layout, either. Gnome can be configured to do much of this, but it just feels terrible. Task bars can't be dragged to re-order. Desktop switchers just have numbers instead of contents. Animations are slow and annoying. Etc. Etc.
I don't have a 4K monitor, but what does `xrandr --output HDMI1 --scale 0.8x0.8` do? I have a 1024x768 monitor and do to all the useless whitespace in modern programs, I scale into the opposite direction.
But I agree Gnome lost the plot completely, and sadly Gtk too. Which is a pity, because I prefer GTK+ to Qt, but they deprecated so much useful Widgets and the alternative given is 'just don't do that'.
You can render at 2x in Mate, and then scale it down slightly (ie 1.25x1.25) with xrandr, but taking a large image and scaling it down using a cubic filter won't look as sharp as real fractional scaling.
The command you gave is upscaling, which will be worse than 2x + downscaling.
Real fractional scaling scales the sizes of elements before rendering. This results in the sharpest image and there is no resizing/filtering in the loop.
KDE Plasma uses QT6, which also supports this.
> Gnome uses GTK4, which supports this. Mate uses GTK3, which does not.
Damn. I tend to build against an older GTK3 version, because GTK deprecated so much good stuff, but that means my programs won't work correctly for that. I need to look whether it's easy to backport this.
I just want to type which app to launch or do some quick math or search for something, I don't need my windows and UI to fly in 14 different directions and then back again every time I need to do those things. Ditto for just want to lazily do something on my dock with the mouse. It's seriously one of the most ill designed off-putting UX things about Gnome.
full screen is still its own thing as you mention, though
Window snapping was implemented some time ago: https://www.macrumors.com/2024/06/12/macos-sequoia-window-ti...
Instead of win key, you can press F3, or just set a hotkey that works for you in the System Preferences
Instead of clicking the red maximize button, you can double-click the window header / title. This will use an algorithm to try to resize the window to the best size for its content.
Except when it's a Qt application, which has no drop shadows because client-side decorations shenanigans.