Hacker News Reader

Comment by audidude | Hacker News Reader

Wow, I've never had so much of the hard work myself, colleagues, and individual contributors have done misattributed to one company.

For those interested in what actually was improved, and some attribution for those involved, see https://blogs.gnome.org/shell-dev/2019/11/22/a-review-of-gno...

View on HN

Come on, Christian. Daniel van Vugt at Canonical did a huge number of performance fixes on mutter and gnome-shell this release. Some of those I had to personally vouch for because your colleagues wouldn't land them otherwise.

Can you elaborate on that a little? I've always gotten the impression that gnome is actively hostile to new contributors and anyone who isn't part of the "inner circle", so I'd be interested in hearing more about what that actually looks like, from someone who isn't very anti-gnome.

As someone who went through the pipeline, GNOME is not actively hostile to new contributors, and is actually really friendly, as long as you agree with the overall design and direction of the desktop. In one of the cases, I'd say that what happened was that there were two competing methods for how to fix a performance issue, and some of the maintainers involved were not graphics experts, so I was able to guide the team to determine which version to land, which happened to be the version by Canonical.

Canonical's version: https://gitlab.gnome.org/GNOME/mutter/merge_requests/189

Endless's version: https://gitlab.gnome.org/GNOME/mutter/merge_requests/402

This is much more well-understood now that open-source is popular, but it wasn't understood very often back in the day, which is that maintainers have the power to say "no", and do so frequently. If you are a new contributor and you try to change the design, you won't have a great experience.

I mean sure, but a lot of open source software is driven by the idea that developers "scratch their own itch".

It's a bit of a pain that so many patchsets need to be maintained separately for common "scratch my own itch" type features in GTK, instead of the feature just getting buried in a gconf setting somewhere. There are an increasing number of little things in GTK that require you to do things the "gnome way" or maintain separate patch-sets. Any attempt to figure out how we can satisfy both parties gets disregarded pretty quickly.

Obvious examples include thumbnails in the file-picker or type-ahead instead of relying on gnome's tracker or slow file-search.

I guess there's some subtle difference between "hostility" and "refusal to co-operate with other stakeholders" that I'm not getting.

> It's a bit of a pain that so many patchsets need to be maintained separately for common "scratch my own itch" type features in GTK, instead of the feature just getting buried in a gconf setting somewhere.

In this case, the pain is in the right place. Mainline needs to be very careful about signing up to maintain new code, especially if it's used by almost no one.

Thumbnailing is one of those things that's difficult because it's a desktop service. Windows / OS X has one desktop, so there can be a tighter integration between the toolkit and the desktop. My recollection is that thumbnails in GTK+ work fine assuming you have the GNOME thumbnailer running, but lots of people use GTK+ outside of those environments, and it doesn't work there.

This is usually when someone says the word "standards" and expects everyone to go "oh, we haven't thought of that!", but standards take a lot of work, and if there are disagreements in the design and direction of the system, no standard is going to be made. My recollection is that thumbnailing was just one of those things.

Sorry, I think I misspoke. Thumbnails do generate properly and show up in GTK file picker, without needing any kind of hard dependency on gnome or any desktop services. That's not actually a hard problem, it was standardized way back.

The actual problem is this 15 year old bug: https://gitlab.gnome.org/GNOME/gtk/issues/233

This right here has collected most of the patches I'd consider to be important, and the maintenance requirements do not appear to be significant. Of course it is work that doesn't directly benefit the gnome DE.

https://github.com/krumelmonster/gtk3-mushrooms

But it's important to note that GTK is not gnome. It's really important to recognize that as gnome fights harder to become it's own platform, that other platforms do make use of GTK. The gnome-foundation being completely inflexible on the needs of other projects means that at the end of the day it is really hard for other people to collaborate on GTK.

Gnome can do whatever it wants, but the idea that GTK is only supposed to serve the gnome project does seem like a bit of a betrayal. That seems to be a pretty common thought: https://en.wikipedia.org/wiki/GTK#Criticism

3.34 wasn't a one-person show Jasper. This article reads like it was a one company thing.

Sure, there was a ton of great collaboration, but "mis-attributed" is wrong. Canonical's desktop team definitely lead the charge of compositor performance. Be nice; there's no reason to keep the Canonical/GNOME rift open anymore. They did absolutely fantastic work this release.

And thankfully we've been lucky enough for your important contributions as well.

Speaking of whom, anyone knows what's up with Mr. van Vugt? He hasn't been active in GNOME's gitlab in the past month.

Canonical engineer on performance improvements on GNOME for Ubuntu 19.10: https://discourse.ubuntu.com/t/boosting-the-real-time-perfor...

Canonical fixed gnome

Reply on news.ycombinator.com