How it shall look… # Linux & BSDs # Windows # macOS # State on Fedora 40 Workstation & XFCE Spin… # Screenshots taken from the GNOME bugtracker, copies to not stall their GitLab instance.
More closed and non-customizable systems are much more stable. I guess that’s what GNOME devs are trying to achieve and I don’t really mind it. We have other options for those who need customization. The most used and mainstream one really should be focused on stability. Though I don’t think anyone tried breaking icons before. It’s a bit too much. The app devs will need to make multiple icons for different DEs which is a good thing but shouldn’t be forced like that
You’re talking about two different kinds of stability. They are talking about development stability. You are talking about runtime stability.
One thing is to not break applications that use your library because of changes you introduce to it. Specifically changes that go against the standard you’re supposed to be following.
Another thing altogether is to not go outside the memory limits of the application so it doesn’t get yeeted by the kernel.
I’ve had growing pains for KDE on Wayland in the past but it’s been chill in recent times too, I can’t remember having any issue related to that for a long time
The standards are supposed to be the stable thing. If some part of GNOME advertises itself as following a specific standard then it should remain stable in following that standard.
That is a misconception that 99% of the devs don’t understand. Sometimes you do need major changes that break stuff to upgrade the base. GNOME started doing it recently. Keeping old bases for a very long time makes them bloated, hacky, slow and unstable
In that case, you implement the old API or other interfaces so older things will continue working, while having the new one alongside it, and then phase the old one out when nobody is using it anymore. It’s not that hard to emulate an older API with a newer subsystem. Just a shitload of function wrappers and things so that the things your program used to call now transparently use the new system while the program is unaware anything changed from its perspective.
That’s what happens with the Linux kernel. Linus would go apeshit if one of the devs straight up broke a ton of user programs with a change. He’s already demonstrated his commitment to not doing that in one of his mailing list rants. Because unlike GNOME, the kernel is running some pretty critical things all around the world.
GNOME seems to be treating their DE like their own little pet project that they’re tinkering with alone in the basement without caring that millions are relying on it every day. Breaking a large portion of programs on a regular basis is what I do in the evenings. Not professionals.
More closed and non-customizable systems are much more stable. I guess that’s what GNOME devs are trying to achieve and I don’t really mind it. We have other options for those who need customization. The most used and mainstream one really should be focused on stability. Though I don’t think anyone tried breaking icons before. It’s a bit too much. The app devs will need to make multiple icons for different DEs which is a good thing but shouldn’t be forced like that
If stability was their aim, they wouldn’t be breaking stuff all the time…
I would argue that gnome is pretty stable in recent years. Don’t remember when was the last time something crashed.
This might would probably be true for Extensions.
KDE has been unstable for me on Wayland in the past.
You’re talking about two different kinds of stability. They are talking about development stability. You are talking about runtime stability.
One thing is to not break applications that use your library because of changes you introduce to it. Specifically changes that go against the standard you’re supposed to be following.
Another thing altogether is to not go outside the memory limits of the application so it doesn’t get yeeted by the kernel.
I’ve had growing pains for KDE on Wayland in the past but it’s been chill in recent times too, I can’t remember having any issue related to that for a long time
The standards are supposed to be the stable thing. If some part of GNOME advertises itself as following a specific standard then it should remain stable in following that standard.
That is a misconception that 99% of the devs don’t understand. Sometimes you do need major changes that break stuff to upgrade the base. GNOME started doing it recently. Keeping old bases for a very long time makes them bloated, hacky, slow and unstable
In that case, you implement the old API or other interfaces so older things will continue working, while having the new one alongside it, and then phase the old one out when nobody is using it anymore. It’s not that hard to emulate an older API with a newer subsystem. Just a shitload of function wrappers and things so that the things your program used to call now transparently use the new system while the program is unaware anything changed from its perspective.
That’s what happens with the Linux kernel. Linus would go apeshit if one of the devs straight up broke a ton of user programs with a change. He’s already demonstrated his commitment to not doing that in one of his mailing list rants. Because unlike GNOME, the kernel is running some pretty critical things all around the world.
GNOME seems to be treating their DE like their own little pet project that they’re tinkering with alone in the basement without caring that millions are relying on it every day. Breaking a large portion of programs on a regular basis is what I do in the evenings. Not professionals.
I won’t even try to explain. People here only want to argue
No, you’re just dense.
deleted by creator
Don’t advertise the theme as standards compliant then.
Ahh, the old “it’s too difficult for us.”
If the gnome devs are so incompetent, why don’t they just get another job?
They should strive for something like FLTK then, it has much smaller codebase.