Also, it's a FOSS project. Which means you can make your voice heard and get involved. Just try and be kind when you make suggestions. Or, even better, contribute yourself: https://www.gnome.org/get-involved/
Unfortunately that's not how the Gnome project has been run. Even back in Gnome 2.x times. There's a famous very funny jwz blog post about this (that I won't link because of some well known reasons).
I'm just trying to understand where this bad reputation for gnome comes from.
Patches are available for type-ahead, in particular the gtk-mushrooms fork. If open source is about "scratching your own itch" gnome is making it really hard for developers to do that. There was discussion of burying that features somewhere deep in the gnome registry, all kinds of options, but it's clear that pull requests are not welcome, even if the option is buried deep in some config file somewhere and is only accessible to power users.
That seems to be the case a lot of the time when outsiders try to solve their own problems with a pull request. There's just no room for compromise or for solving your own problems.
As a point of comparison, you may want to look through all the other merge requests that actually do get accepted, the majority of them do: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests?sta...
The problem is that GTK was used as a generic toolkit, and they've added a bunch of weird customization's to make it work better with their platform. That fucked over a lot of people who used that toolkit on non-Gnome platforms, and for non-Gnome uses.
Most people using GTK didn't sign up to be part of the gnome platform. Firefox isn't a gnome app. They (and everyone else) assumed it was being developed as a generic and cross-platform gui toolkit. Bit of a bait and switch there.
The tight integration between gnome (the platform) and GTK (the cross-platform GUI toolkit) seems an awful lot like a betrayal, like taking something that was for everyone and well.. taking it. Making it all about themselves, and burning the commons so other people can't use it. Or at least like a heavy-handed attempt to force people to write Gnome apps instead of GTK apps.
But, since I've said this before, I'll say it again: If the other people who use the toolkit want to have input, they need to contribute more. AFAIK there are zero non-GNOME devs working full time on GTK. I hope that changes, i.e. I hope the other desktops can find funding to send more designers and developers to collaborate with the GNOME people so everyone can have their say. That is the real issue here, I think it's incorrect to suggest that anything was "taken." It's open source, there isn't anyone who's going to take the code away from you unless you blatantly violate the license.
https://gitlab.gnome.org/GNOME/gtk/-/issues/839
Also: https://bugzilla.gnome.org/show_bug.cgi?id=748672
The GTK devs were saying that they wanted a flag shared between nautilus and the file picker that would enable/disable typeahead. Unfortunately nautilus refuses to implement that flag, which I think means we're all still relying on forks for that feature.
So you're not really allowed to solve one without solving the other, last I checked.
So yeah, the issues is very much in both, and you can't solve the issue with GTK without solving it in Gnome.
The final comments from the developer directly contradicts this claim:
>I'd be happy to review a merge request that added the ability to disable recursive search in the file chooser using a GSettings option ... I was thinking more along the lines of having a key in the file chooser settings schema that would be observed by Nautilus.
The idea there is that the key should be in a standard location read by nautilus (or some other GTK file manager) if it also decides to implement that feature. Edit: I also should note that it appears there was not even initial consensus about this, the other GTK developer seemed to be skeptical at first.
systemd does have a very opinionated code style, but that's not much different from (say) Linux kernel.
If the professional designer in question really is expected to do something different, such as make usable software, then a review of job performance is sorely needed.
The link was an interesting read eitherway and I can absolutely understand where the frustration comes from. The users' comments just flew over the developers' heads. Nonetheless it looks more like a breakdown in communication than willfully ignoring with deceitful intentions on the part of the developers in my opinion.
https://gitlab.gnome.org/GNOME/gtk/-/issues/839
Look at why LXDE switched from GTK to QT.
Take a look at when a bunch of Gnome developers decided theming wasn't okay (as opposed to fixing themes): https://stopthemingmy.app/
Take a look at this bug-request on the transmission torrent client: https://trac.transmissionbt.com/ticket/3685
> I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately.
Take a look at the whole history of client-side decorators, particularly the suggestion that every SDL-based app should implement their own CSD support: https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3552...
There's plenty there if you just look around.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests?state...
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests?state=me...
If you're going to look at the pattern of historically rejected requests, please also consider looking at the pattern of requests that were accepted.
If you'd like, I can give you a more thorough explanation as to what is actually happening in any of those issues you've linked.
As you can see Gnome is mostly a redhat project these days: https://hpjansson.org/blag/2020/12/16/on-the-graying-of-gnom...
It's not surprising that things get merged when they come from redhat-affiliated developers.
I don't think so. Gnome seems like a bit of an old boys club. I think the post I linked backs that up.
I'm sorry but this has never been true during the development of wayland. A quick search shows dbus has been in freebsd since 2004, before wayland even existed: https://svnweb.freebsd.org/ports/head/devel/dbus/Makefile?vi...
The problem with creating additional wayland-only solutions is that they tend to need good, strong implementations in the toolkits first for it to really make sense over a dbus implementation that already exists. (The wayland api is not particularly friendly for application programmers) The person advocating for the protocol is usually the one who has to implement that.
Then I must have misremembered something. Thanks for the correction!