A GTK+ 3 update
blog.gtk.org
blog.gtk.org
It's almost as if devs care more about stable APIs than about endless churn for minor features!
People probably would've had less trouble and been less upset if Gnome wasn't in a privilege position and had to just be another user in the ecosystem.
Gnome and other apps didn't break, because they weren't concerned about theming themselves.
Just this week, me upgrading a GNOME extension resulted in the user session completely crashing, getting me back to the login screen, and making me lose about half an hour of work.
Now, of course, I could put the blame on the sole developer that developed that specific extension (one of the preinstalled ones in Ubuntu now), but I don't. I blame GNOME that a botched extension update lead to the entire session crashing, instead of doing something normal (like reverting to the previous version and showing "update failed").
We did all of this refactoring, rebuilding, and yet... Where's heterogeneous graphics card support? Where's heterogeneous DPI support? Why does multiple desktops still suck? Even using all open source drivers, Linux feels dated and immature at the same time :( I miss feeling like it was ahead of Windows.
Consider switching to BSD or Devuan (and donating time/money/bug-reports).
I think Linux generally works on the desktop. It's true that GNOME 3 is still buggy. I've had Nautilus crash on me while copying files and other horrible things.
Wayland hardly has any apps with native support, it crashes a lot and the hardware support sucks too. Also (afaik) applications such as Wine can never be ported to Wayland.
However GNOME and Wayland are just one bleeding edge.
If you run X with some stable WM or DE, things work so well it's almost boring.
However:
- with multiple GPU configurations, all bets are off.
- Thunderbolt docks and even the Thinkpad dock can be buggy and cause crashes. I've had a few instances of Xorg crashing on dock.
- HiDPI sucks. Linux took the wrong approach from the get go. Now each Xorg client has to be DPI aware, but if it isn't, there is no graceful fallback. There's also no easy way to determine what the DPI should be, and any hopes that you can have monitors with differing DPIs is right out. Wayland tries to fix this, but in my experience so far things look blurry and horrible.
- IME sucks really badly. It almost was good for a bit, with IBus. But now I don't even know what the standard is or how to configure it. How do I even get Japanese IME in KDE? I can get it working in GNOME but good luck getting that to work with apps that don't use GTK.
- Sleep is still complicated. There are multiple DBus APIs for power management, and they're not compatible. GNOME does OK here. KDE does worse, and I find myself needing custom code to inhibit sleep in some circumstances. Not user friendly, though workable for me.
- Resume is more complicated.
- It feels like boot splashes have only gotten worse since the old days. Entering in LUKS keys is still weirdly unfriendly, especially if your boot splash misbehaves.
- X11 has security issues. No shock there, but it makes application isolation like Snap and Flatpak pointless.
- Audio can be tricky. I was a PulseAudio early adopter and like it better than raw ALSA since it covers more use cases like Bluetooth and provides some extra features. That being said I've found it can be problematic on a lot of hardware, sometimes I lose audio until I kill pulse and it's hard to debug. Worse, lately some apps are having difficulty selecting their own input/output devices, making conference calls a nightmare.
This is really just the beginning. Windows sucks too, don't get me wrong, but Linux is definitely not "so stable it hurts"
The last time I had Bluetooth audio actually work, it was before it needed to be routed through pulse. Alsa applications played Bluetooth audio just fine. Then at some dist-upgrade it pulled in a new bluez and that no longer worked, and I literally could not get it working through pulse.
I actually have this experience 100% of the time with pulse: introduce pulse and everything breaks. When things talk to lower level pieces it works fine.
By the way, alsa itself is a little bit of a case study in confusion between api and implementation... My freebsd machines are using the oss audio API with none of the problems that plagued oss on Linux in the 90s.
And all of those problems occurred WITHOUT Bluetooth being thrown into the mix. I had multiple audio devices, including Intel HD Audio, an Audigy LS of some kind, and a USB microphone that presented it's own audio device to the system. (This was a while ago, I have no setups that look like this anymore.) I'd often have the devices come in a different order, and when this happened my mixer levels would be all messed up, and often times if I booted with the microphone plugged in... it'd be the default output device.
With PulseAudio, I have less trouble - things do generally get setup how I expect it, and when they don't I can switch everything at runtime to be correct. It's worth noting that the trouble I have had with stability is heavily tied to hardware. Of course that doesn't mean it's not a PulseAudio issue, but I think a lot of people have trouble that they may not realize is not actually the normal PulseAudio experience. Even latency varies per hardware, in what I can only assume has something to do with how the audio hardware handles timings.
Probably it's part of the reason why I don't have much trouble or complaints either.
Linux has worked on x86 workstations _very_ well for well over 10 years, but it has always required some extra effort to configure etc.
And yeah laptops... they work sometimes.
Gnome just follows on because the gtk team is a very purple Venn diagram with the gnome team (at least for paid developers)
- An app running in Windows or macOS
- An app running inside of KDE or another desktop environment
While the Adwaita theme certainly looks OK, having it be the only stable option is beyond absurd, and makes GTK 3 useless for anyone outside of GNOME, including GIMP, which I believe ironically was the origin of GTK itself to begin with.
While I can't think of another example of where GTK broke other than theming, that doesn't really make it OK. Marking it unstable may effectively cover their ass for fulfilling their promises, but in my opinion that's ridiculous for an aspect of the library that literally can't be ignored.
The reason why theming was unstable is, that it was being reimplemented. That's a thing you cannot do overnight, it takes some time. So if you want a theme that is not adwaita, you have to do exactly the same thing that the adwaita people did: update it for each release. Yes, that takes time too.
Doing things in explicitly marked unstable internals of any framework will get you the authors protecting themselves against you. In Windows, the theme authors got signed themes, in MacOS they got SIP. Yes, it is not a insurmountable problem to avoid both, that's not their purpose, but when something breaks, it is obvious who's fault it is.
GIMP is still Gtk 2 app, so it wasn't concerned with broken theming at all. They have their own work to do with the switch to GEGL.
https://github.com/GNOME/gnome-shell/blob/1f03599d1cf888f73a...
Seems to me that "#include <gtk/gtk.h>" means that gnome-shell does use gtk. Or maybe I am missing some nuance of your statement.
Eight years after GTK+ 3 was released. And people felt the Qt4->5 transition was slow...
I'm glad Mate is around to keep maintaining gtk2/gnome2.
I rather prefer Qt4 apps. Some Qt4 apps look uglier after migrating to Qt5.
On ArchLinux you can run `qtconfig-qt4` to configure the look and feel of qt4 applications.
I always was a great fan of both GTK2 (for the UI) and Qt4 (for the API). GTK3 made me switch to Qt4 for development. Qt5 brings some improvement, but as a user I absolutely hate QML.
Running qtconfig-qt4 and redefining the config I wanted did fix the "ugliness" of qt4 applications after I upgraded to KDE5 (or whenever it was KDE switched qt versions)
What’s worse is that you can find many different recipes on the web on how to enlarge th scrollbars/disable auto-hide, and most of them don’t work or work only some of the time.
And the abandoning of menus, which I guess is mostly encouraged by the GNOME HIG:
Menu bars increase the vertical footprint of an application’s user interface, introduce a large number of disclosure points, and function as a fixed set of inflexible options. For these reasons, header bars and header bar menus are generally recommended over menu bars, along with other design patterns for exposing controls on demand, such as selection mode, action bars, and popovers.
So, now that we have giant 4k screens, we are going to abandon menus. And I am not even a menu user, but they are great for discovering keyboard shortcuts and the the functionality provided by applications. Instead, we have header bar and hamburger menus that can only host a small subset of the items that normal menus could host. Shortcuts become hard to find and some applications provide some shortcut overlay, while in other applications you have to figure it out yourself.
If vertical footprint is a problem, offer the user to put the menu in the system tray macOS style.
Fun fact: the Xerox Star apparently had hamburger menus, application pull-down menus, and later the global menu are an evolution of the hamburger menu. It seems that we are going backwards again, without any clear rationale. Even if hamburger menus were more ergonomic, generations have been trained with the WIMP paradigm.
[1] https://medium.com/@probonopd/make-it-simple-linux-desktop-u...
Files (Nautilus) shows some icons and 5 actual menu items. You have to guess what the icons do, only the zooming icons are somewhat clear. There are no keyboard shortcut hints.
GEdit has just a couple of items and two menus that also contain almost no items. There are also no shortcut hints.
The GNOME Web Browser has items distributed over two menus, a hamburger menu that has virtually no items and a single menu in the system tray with some more items (why are menus even in two different places?). No keyboard shortcuts in sight.
GNOME Software does not have any menus at all.
gnome-terminal is still sticks to the UI paradigm with six menus, plenty of items and shortcut indicators.
They've also eliminated the ability to incrementally scroll by clicking above or below the bar, now it jumps absolutely to the position you clicked! So when you miss the bar, and it jumps to wherever you clicked, it's unobvious how to get back to where you were before the misfire. No more arrow buttons to click on either. It's an egregious UX regression as a trackpoint-only user.
My impression is that the GNOME devs are all using touchpads and/or scroll-wheels for scrolling now and don't click on scrollbars, so they prefer to not see them and couldn't care less about how hard it is to locate and operate them via clicking.
Supposedly GNOME is the accessibility champion of FOSS desktops, but that might have more to do with the dismal state of FOSS desktops than anything else.
But I agree that it is obnoxious. I still haven't found a working GTK3 theme which is (a) dark (b) not "flat" and (c) has usable scrollbars. XFCE-Dusk is almost there, but seems to have been broken by newer GTKs, so I'm currently using Vertex-Dark.
I simply don't comprehend how one reconciles that attitude with accessibility needs, when accessibility is inherently giving a fuck about the minority.
It might be a simple matter of scarcity in developer resources. I presume most of the people bitching about GTK/GNOME in forums like these are actually capable of hacking on the project but don't, myself included. So maybe we should just be more appreciative of what we do have, there's nothing to refund after all.
Except I've had a horrible experience with scroll wheels and GTK3 - it seems to very easily get confused about widget focus.
It doesn't make any sense.
> Windows' file open/save dialogues are so far ahead of everything else that the competition seems like unusable garbage to me. I'm glad KDE/Qt chose to emulate these very closely on Linux. Wouldn't want a desktop where my only choice is Gnome's take at this.
Going back on that promise and saying that GTK 3.22 isn't actually The Stable Version after all feels a bit like a betrayal... but on the other hand, if gdk_window_move_to_rect() is the function I'm thinking of, all is forgiven.
I was trying to create a custom popup the other day and (thanks to limitations in the GDK API) it wasn't possible under Wayland. Trying to dig into why, I found out that GDK had an API that did exactly what I wanted, which I couldn't use because it was internal and unstable. Assuming that API is gdk_window_move_to_rect(), this is the best news I've heard all day.
Good news. From the article:
"gdk_window_move_to_rect as public API"
A project being responsive to the needs of its big users? Shocking and unacceptable.