I think, @Harvey hit the highlights, but I'll go ahead and lay out my thoughts here just so that it's clear where I personally stand on this.
Many people don't know this, but I've actually spent a fair amount of my professional career working on web-based applications. In my undergrad years I got distracted by chasing trends and frameworks. It meant that I couldn't do as much as I would have been able to if I had just focused on improving things incrementally. One of those trends was "mobile-first" development. Most people forget that smartphones are only a little over a decade old now. We used to design for 1024x768 running on anything from IE7 to the then new Google Chrome. It was clear that we needed to change how we were doing things to handle mobile devices, and later, HiDPI displays. We couldn't think of websites as print-media anymore. They needed to react (groan) to changes in window size, display size, available hardware, etc. As is true with most course-corrections, the first set of changes are always too far in the other direction. For us, this meant relying too heavily on bloated CSS and JS frameworks to build our web applications. Worse, we spent so much time circumventing the limitations of web-browsers with JS, that standards like CSS and JS have barely evolved in the last decade. Worse, web UI has changed to support mobile and touchscreens as a first priority, meaning that become the elements have become sparse and padded to hell, even on desktop "optimized" styling. If you don't have a HiDPI display, this gets even worse. Meanwhile, I moved away from all of that, wrote a 4KB (uncompressed) CSS toolkit that doesn't use any JS, and it meets 80-90% of the requirements for responsive UI design. Compare that to Bootstrap or Foundation which are hundreds of times larger.
But of course, you're probably wondering what all of this has to do with libhandy and GTK4. People forget the history of things pretty easily these days. If I were to ask you why GTK3 exists and why GTK2 needed to be replaced, most people would just summarize it as GTK2 being too old or cumbersome to work with. The reality isn't much more complicated, but most people would miss it entirely: GPUs became popular and powerful. With this wealth of graphics power lying untapped, people started expecting their GUI environments to start looking nicer and having "expensive" things like animations. GTK2 was written in a time when everything was rendered on a CPU and GPUs were too expensive or too slow to consider targeting. It didn't fit the mold of this new paradigm. So GTK3 was born to rise to this new challenge. Now, we are at another crossroads where mobile devices, HiDPI, switchable graphics, Vulkan, Wayland, and a host of other new technologies need to be addressed and handled. We don't necessarily need to support both CPU and GPU rendering in the same toolkit. Focusing on one means simpler code and being able to optimize better. GTK4 is what will make that happen for GTK.
But there's a caveat to that. GTK4 has been in development for a long time and people still want to see those kinds of things in GTK3 applications. Purism recognizes this need and wrote libhandy to provide a set fo GTK3 compatible widgets which fill some of the chasm between GTK3 and the expectations of GTK4. It seeks to mostly improve the responsiveness of certain widgets by replacing them entirely and focusing on mobile device support and touchscreens. This is fine if your a company trying to promote GTK3 for mobile applications running on Linux. But it begs a couple of pretty serious questions:
- Why couldn't they just have worked on improving the existing GTK3 widgets?
- Why do they assume that "mobile-first" is inherently better? How do they know this won't harm the Desktop experience?
- Why are they going around and patching
libhandy into desktop applications like GNOME Boxes that have no reason to be running on mobile systems?
- Won't all of this just be a waste of time once GTK4 is out?
I won't speak for @JoshStrobl, but I personally feel that Purism should have worked on improving GTK3 widgets rather than writing their own widget toolkit that they are now going around and "infecting" other projects with. I think this will harm the desktop experience in those applications. Having looked at many applications that use libhandy, it's my personal opinion that they look like mobile applications that no one even bothered testing on Desktop systems. Not all that dissimilar from running iOS apps meant for iPhone on an iPad or a Mac, or the similar experiences on Android. If we aren't learning from past mistakes, what's even the point?
If we start running into problems with the default applications on Budgie, we'll just replace them. As far as GNOME is concerned, I'd much rather focus on having a Budgie 11 that blows it out of the water. I don't really know what that means for us long-term with libhandy on GNOME. For now we'll handle it on an app-by-app basis. Hopefully, GTK4 will pan out and the core GNOME applications won't need libhandy at all going forward. I don't really see a future where libhandy exists on GTK4 because of all the improvements they have made. Time will tell.
