More GNOME Performance Optimizations Being Tackled Thanks To Canonical

[lumks]

It would be easier for them to switch to Plasma, it doesn't even need a fix.

Except for everything enterprise related. There is no working PIM on KDE, there is no working SMB on KDE (go ahead, try to stream over SMB in KDE). On top of that is Qt still frustrating to use on Linux because nobody supports it.

Now gnome, which is a Linux enterprise desktop, is supported be everyone who supports Linux, has IBM/RedHat as developer and a massive user base. + You can simply recreate unity with extensions. Gnome is far from perfect, but the better platform to start from.

[olympus]

Except for everything enterprise related. There is no working PIM on KDE, there is no working SMB on KDE (go ahead, try to stream over SMB in KDE). On top of that is Qt still frustrating to use on Linux because nobody supports it.

Now gnome, which is a Linux enterprise desktop, is supported be everyone who supports Linux, has IBM/RedHat as developer and a massive user base. + You can simply recreate unity with extensions. Gnome is far from perfect, but the better platform to start from.

You are right, Gnome has become a project by a corporation, now by IBM. KDE is a community project.
This is what Canonical should do, work on making KDE a valid solution for enterprise too.

[pal666]

The point was that 144Hz doesn't want to mix UI toolkits for whatever reason

for very clear reason of using broken distro

[royce]

Just my 2p. After all these years, Gnome is still inferior to Unity in many areas including usability, performance and stability. Unity became the standard Linux desktop for many years for most people, and many of us still use it.

[amehaye]

Thanks for pointing out these changes Michael. I still think they get far too little attention from the resident GNOME developers. In many of the merge requests, all of the issues pointed out have been fixed. Some of the changes even fix long-standing issues not strictly performance related along the way. Naturally, some people are starting to ask: "Why the holdup? Why isn't this being merged?" This is quite frustrating.

There are a bunch of people that manually apply these patches because they make such a big difference. I think this alone should signal how important performance improvements are.

It's been 4 months since this article went on the air, and as far as I'm aware not a single MR was accepted yet. Some of them have been open for almost a year - see, for example, https://gitlab.gnome.org/GNOME/mutte...e_requests/119 - but even though these changes greatly enhance the user experience, they hang to rot.

Michael maybe it's time to post another article, just to nudge the GNOME developers into accepting some of this work. It would really be a shame not to get it all merged before the next release.

[royce]

It always seemed to me gnome developers are quite hostile to Mr van vugt for some reason. Stopping pull rewuests for the most obnoxious reasons, including coomit comments not to their taste. No wonder nothing ever gets done at gnome.

[amehaye]

It always seemed to me gnome developers are quite hostile to Mr van vugt for some reason. Stopping pull rewuests for the most obnoxious reasons, including coomit comments not to their taste. No wonder nothing ever gets done at gnome.

Judging by gitlab, a relatively large percentage of Daniel's MRs were actually accepted (currently it's 25 out of 68). However it does seem to take forever for an MR to be honored.