System76: A Case Study on How Not to Collaborate with Upstream

I enjoyed your post, and the other issues mentioned were easier to follow and understand what you mean.

I'm sorry that this happened.

So a GNOME user with the POP_OS! theme will see those styling elements when opening an app that's using libadwaita, without any special modification to the app or compile process?

I've been following GNOME development for years, and recently getting interested in seeing how KDE handles things behind the scenes, and it's hard to miss the fact that the most prolific GNOME developers are the same 3 or 4 faces that have a really hard attitude against any type of discussion around their changes. I won't name names, but most issues on their Gitlab around any major change usually devolve into one of them saying "we're volunteers, send a merge request is you want it different". Ignoring the fact that most of their projects have opened and unanswered merge requests in the dozens. And hundreds of unanswered issues and even more on their old bugzilla.

The "volunteer" excuse is the most common passive aggressive response in the open source community, to hide behind when there's actually no real interest in entertaining different point of views or alternative suggestions.

So yeah, development is done in public, but they are set on their ways, dislike outside input and tend to get really rude and curt if you disagree with their idea. There are countless examples that pretty much anyone in the Linux community knows about.

I actually have no real qualms with the direction GNOME is going, but they are the reason I've never contributed to the project. They are a fickle and hard to please bunch, unless you're part of the internal clique.

I'm all for asking politely if you're going to ask at all, but... why should asking even be necessary? Why not just post the justifying data by default? That seems like less work than "data available upon request if you ask nicely."

The argument was that it would lower cognitive load, without any evidence backing it up, and obviously with no input from people who regularly have to mix different input systems - where the ability for IME state to match context of the window they are in, especially as sometimes the different tasks in different windows would have incompatible needs on current IME state.

I do not see it as wrong, Gtk and GNOME developers have said a lot of stuff over the year but at the end of the day it is what they do that matters and ever since Gtk3 they basically took over Gtk.

> I mean, I hear this asked for frequently but it's not clear what you want.

How is it not clear, i explicitly provided Win32 as an example right after the part you cut at. After all...

> You can keep using Qt 2/3, GTK 1/2 and those are technically "stable" but of course the trade off there is that you don't get new features, or bug fixes.

...Win32 does get new features and bug fixes all the time - even the pre-XP controls (i mean the non-themed common controls) still get updates.

Qt 2/3 and Gtk 1 (not Gtk 2 so far though) aren't realistic targets either as you can't make a binary and expect it to be available anywhere - except perhaps Slackware which still distributes Gtk 1 (i do not think it distributes Qt 2 or 3 though). So you have to bundle the libraries with your application (**please** do not compare this with Windows, Windows come with a A TON of stuff you can rely to be there even if you do not use it - like a GUI toolkit for example... actually a bunch of GUI toolkits, but let's stick with Win32 which is what i originally brought up) which not only bloat the application itself but also version lock the dependencies to whatever you bundled, including its features and bugs.

So for example a Gtk2 or Qt 2 or Qt 3 application (and perhaps a Qt 4 application too, though not 100% sure) might work but, e.g., it wont get a Wayland backend because the bundled version you have was never updated for it. It also wont get high DPI support for the same reasons. If you bundle Gtk3 or Gtk4 or Qt 5 now and someone finally implements per-monitor window events under X11 for scaling like in Windows which also requires toolkit support, your application wont support those because instead of using the system bundled libraries, you use your own. If some distribution decides that enough is enough and implements a better file dialog for Gtk again your application wont get the new functionality because instead of using the distribution's libraries you use your own. Etc.

What i want is simple: a stable ABI so that binary applications can keep working in future (think timeframes of 20, 30 years and more, not just a couple of years or whatever) while getting new features whenever that is technically possible with the same binaries, a stable and backwards compatible API so that source code can still be compiled as-is in the future (or at least the library wont be the reason it wont be compilable) while still getting new features for applications that are still in active development to use so that they look, perform and behave better but without forcing everyone to upgrade in a step-lock but instead letting them do that whenever they can (and assuming they even need the updates - let applications where these updates do not matter for keep using the existing APIs), any documentation, be it first party or third party, that was written over the years wont be invalidated and the invaluable and limited time of documentation writers wont be wasted and instead be used on new stuff where that matters, the knowledge of those who bothered to learn the library wont be invalidated, application developers who spent time targeting the library wont have to waste time re-do things that they've already done just to get more or less the same result, etc.

See OpenGL as an example: now OpenGL has gained bad rep over the recent years (and i personally blame Khronos over its mismanagement) but regardless, a Windows application that was written back in the late 90s using the OpenGL 1.1 API worked on GPUs of the time that usually all they could do was triangle rasterization and everything else was done on the CPU. Then the exact same application, same EXE file, could run on a later GeForce 2 TI that implemented many parts of the API in hardware. Then nowadays, the exact same application, same EXE file, can run on a modern GPU that got rid almost all of the fixed function hardware but still implements the same API largely in shaders - but the program works and has better performance than it ever did, even if it doesn't have the best performance it could have. But even better, it can get functionality like MSAA support from the drivers, triple buffering, vsync control, etc that didn't exist at the time. What is more, if the source is still around, chances are it can be recompiled as-is (or at least the OpenGL bits could) and its functionality be extended by adding additional code alongside the existing code to use new features like shaders. In fact this is what Beamdog did with Neverwinter Nights: Extended Edition where the original game was written against OpenGL 1.x but they - almost two decades later - started adding additional functionality to the game (but the original game still works fine).

What i ask isn't fantasy, it is something other APIs have done, including the Win32 API (at least the GUI bits) which pretty much offers what a toolkit offers in Linux.

But.. the linux desktop is way better today compared to then, despite my bitching about it.

Maybe a kickass turnkey cloud-based desktop solution would be a big uptake. AWS has won servers, but why shouldn't they win desktops too? What company doesn't want to move to remote desktops for everyone?

That would probably take some investment in stabilizing the remote/RDP video drivers, a lot like what has always plagued linux desktop: video support and drivers.