I understood that it cost Gnome $150k for Gnome to settle and obtain their own exclusive right of usage instead of doing the right thing and fight the patent.
> I understood that it cost Gnome $150k for Gnome to settle and obtain their own exclusive right of usage instead of doing the right thing and fight the patent.
That's what I meant by "going through", they obviously couldn't fight it in court, would have cost a lot more...
Gnome developers actively discourage fixing things yourself even though they often use that as a reply to bug reports. Fixes are often rejected as "not bugs" so most just give up and move on.
> This result matches well with the few tests that have been done, which suggest that when it comes to pulling and jumping, chimps are about 1.5 times as strong as humans relative to their body mass. But because they are lighter than the average person, humans can actually outperform them in absolute terms, say O’Neill.
I certainly agree, you wouldn't have much of a chance against a chimp one on one without weapons. It's just that the article isn't about chimps, but about much smaller macaques.
We both are stronger and have more stamina than macaques. The biggest male adult macaques are 18kg. That’s probably more that the average adult can raise with one arm but not by much and I insist on average. That’s nothing exceptional for someone in shape.
Considering the weight and power in a human leg, a swift kick would seriously harm and probably kill an average macaque. The issue is not strength here.
Eh, I find it hard to relate to complaints when Gnome devs have spent the last 20 years treating users like they don’t know how to use a mouse & telling anyone Who wants to make it better that they are wrong.
Just FYI. If your suggestions for "making it better" for yourself would be making it worse for other users, then that probably would be why your suggestions weren't taken. GNOME has made accessibility a priority for a while now, so that is why the interaction with the mouse has been done the way it is. (Disclaimer: I am not a GNOME developer, this is just my observation)
More than once the suggestions weren't breaking accessibility at all, and at least once it was GNOME devs deciding unilaterally that they know better than users who will face accessibility issues due to their changes.
Can you please give an example? Keep in mind that if a change fixes some accessibility issues for some people but then causes other accessibility regressions elsewhere, that could also be bad and not wanted. Nobody wants to be the person to make that decision and deal with the angry users, but sadly, somebody has to do it unilaterally otherwise development on the project will not happen.
Really now, if your stance is "it is bad for an open source maintainer to make decisions that might be difficult" then it seems you would have trouble finding any project that suits you.
Forcing single IME state globally and attempting to remove even the possibility of using per-window/application state in IBus. Mind you, this was removing the option, those who preferred single global state already could do so.
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 honestly have no idea what you're talking about, I still see an option for "Allow different input sources for each window" in the keyboard settings panel.
I really don't understand why you are posting this, this is a 9 year old bug that is marked fixed. Please read the rest of the comments on the bug beyond that one and please don't make me regret asking these questions, I'm feeling like my time is wasted when people post these bugs without checking them.
Note that I'm not the person who originally brought this up.
I'm posting that because (a) I believe that is the issue referred to, (b) if you look at the reactions there is definitely a lot of "why would you even want this", there is the "lower cognitive load", and they did go ahead with a release in which it was broken, even though it was reported before the release was finalized.
I see all that, but the issue is fixed now. Yeah they made a design mistake and then they corrected it, it doesn't seem to be much different from any other bug. If you are trying to get help with something, it is not particularly useful to cherry pick comments from a long time ago that are not even relevant anymore. I'm sure we could go through the old bug tracker and find various disagreements in other areas, but that won't really help with the status of a current bug.
They also need to build their own toolkit (this one hopefully not in Rust or at least if in Rust with a C API that is accessible outside of Rust) because at this point Gtk is a vector for Gnomisms to projects outside of Gnome.
Honestly IMO there needs to be a new toolit, one that understands the important of ABI stability over an actual long period of time (see Win32) and being easy to interface by a variety of different languages without having to spent ages for each interface. Gtk fails at the first, Qt fails at both.
They said they weren't going to do that and they would continue to use GTK.
Also, this is wrong:
"because at this point Gtk is a vector for Gnomisms to projects outside of Gnome."
In GTK4 the goal has actually been to intentionally move GNOME specific bits out of gtk and into libadwaita. I can provide a source, if you want.
"one that understands the important of ABI stability over an actual long period of time"
I mean, I hear this asked for frequently but it's not clear what you want. 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. So if you want someone to do something with those, it would help to ask for what you want specifically.
>Also, this is wrong: [..] "because at this point Gtk is a vector for Gnomisms to projects outside of Gnome." [..] In GTK4 the goal has actually been to intentionally move GNOME specific bits out of gtk and into libadwaita. I can provide a source, if you want.
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.
"it is what they do that matters and ever since Gtk3 they basically took over Gtk."
I don't know what else to tell you. If you follow what is happening in GTK4 you will see that they are moving things out of GTK. This is what they are doing at this current point. Also I hope you understand that this stuff is all open source and nobody is "taking over" any projects, it's simply whoever shows up gets to make the decision. It was mostly GNOME that was contributing upstream during GTK3 so that's what happened.
"How is it not clear, i explicitly provided Win32 as an example right after the part you cut at."
Right, if you want Win32 API, you would use Wine for that. But if that's not adequate then please explain. And yes I know there are bugs and missing features in Wine, so that would be the place to start instead of trying to make a new toolkit that would also be incompatible. If you cared about compatibility with old apps then I'm actually very confused as to why you would be asking for a new toolkit, old apps that don't get updated would never use it.
"...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."
Okay but which updates. If you want something implemented in Wine or you want something backported to GTK 1 or Qt 2 or whatever then you need to mention that. I can't guess what it is you want.
"So you have to bundle the libraries with your application which not only bloat the application itself but also version lock the dependencies to whatever you bundled, including its features and bugs."
This is an entirely separate problem of which there are multiple solutions to. Let's not get into this though, take it one step at a time.
"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"
Ok these are real things to ask for, that someone could feasibly attempt to do. I would say just skip all the other things you asked for, cut out the rest of your comment, and just ask for this, because these are real missing features that could be put into an action item. But actually, I don't think either of these would be technically possible for a lot of apps. If an older app uses Xlib functions then that won't work with a native Wayland backend. If it draws pixels to a buffer and doesn't calculate scale then it won't work with high DPI. (You would be surprised how many older apps actually do this...) So that is unfortunately not something that can be fixed in all cases by trying to backport things to an old API and I think you would largely be wasting your time trying to implement those things. At some point you have to accept that the old APIs are just not suitable for some things.
OpenGL is not really a good example because while it might be easy to add some things like vsync and triple buffering, other things (like GPU parallelization) are basically impossible (or extremely impractical) to try to hack into in the GL implementation. The fixed function mode is always going to have its limitations.
"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)"
I mean, already I mentioned how it would maybe be possible to get this in some limited form. But someone has to actually put in the work to get it. Keep in mind, it is not helpful to keep requesting that small open source projects do things exactly how a trillion dollar corporation is able to. You are wasting your time asking for that.
> Right, if you want Win32 API [...] Okay but which updates [...] Ok these are real things to ask for, that someone could feasibly attempt to do.
These are examples. I'm not asking to use Win32 or add updates to Gtk1 or Gtk2. The important part is keeping ABI and API stability. Also i refer to what i'd like to see in a hypothetical library that did things right, not the current ones that either keep doing everything wrong (Gtk) or even if they wanted they can't due to the tech they're based on (Qt, though chances are even Qt could stay API and ABI compatible they wouldn't because they're primary middleware for paying corporations and only secondary a platform library that happened by chance thanks to KDE).
> OpenGL is not really a good example because while it might be easy to add some things like vsync and triple buffering, other things (like GPU parallelization) are basically impossible (or extremely impractical) to try to hack into in the GL implementation. The fixed function mode is always going to have its limitations.
It is a great example because it shows that it can remain API and ABI compatible for decades. Also both CPU and GPU parallelization could be implemented with extensions (though GPU parallelization is something that GPU vendors seem to be moving away from) in a variety of ways, e.g. using display lists in different threads a per-thread shared context that records a thread-local command list for the operations inside the display list than later can be executed via the render thread. Similarly different contexts can be "bound" to different GPUs and yet allow for resource sharing. Those may or may not need new APIs (most likely will) but are still possible. Or a more low-level approach like Nvidia's command list extension could be used instead.
> But someone has to actually put in the work to get it. Keep in mind, it is not helpful to keep requesting that small open source projects do things exactly how a trillion dollar corporation is able to. You are wasting your time asking for that.
Well, i'm not explicitly asking for someone to do anything, especially from projects that do not seem to be interested in any of that. My comment was about what i ask for to exist, not what i ask for from someone or some specific project.
Also
> This is an entirely separate problem of which there are multiple solutions to. Let's not get into this though, take it one step at a time.
This isn't a separate problem, it is a problem that exists because libraries do not have stable ABIs and programs cannot rely on libraries that are on the system to provide fundamental functionality that wont break (or even wont disappear) in a couple of years (or whatever other short timespan).
There is this great commentary by Linus from almost a decade ago...
...where he went into the issues and yet they are still there because instead of trying to fix the problem at the core (which is what he explicitly mentions about ABI stability, like it is done in the Linux kernel - BTW this also would be a good example), the developers who work on these projects instead decided that the best solution isn't to decide and stick with a stable ABI but instead provide a standardized form of the "bundle your own libraries" approach - which barely solves anything related to not having stable ABIs.
The vitriol thrown at Gnome devs has always been a needed reminder that engineers are just as capable of falling for a surface-level and biased narrative as the average American. The fact that many of the Gnome maintainers still continue to develop the Gnome ecosystem is a bonafide miracle.
The one grain of truth in this mess is that many diehard desktop users don't want innovation, they want the traditional 00s style desktop. MATE, Cinnamon and XFCE serve that crowd swimmingly so can we stop with the hate?
I was thinking something similar: on one hand system76 is probably wrong, but on the other hand gnome is trash and consistently screws up their users so...
So happy I moved to XFCE (and i've been trying KDE lately).
