| |||||||||||||
The GNOME project at 15The GNOME project at 15Posted Aug 15, 2012 22:23 UTC (Wed) by hp (subscriber, #5220)In reply to: The GNOME project at 15 by codewiz Parent article: The GNOME project at 15
I think developers and designers often take flames and polls and the like as a data point saying "there is a pain here" -- but not as a prescription for how to solve it. Most of the time flames boil down to the following:
This is completely understandable and I have the same emotion pretty often. I frequently avoid upgrading software especially to the ".0" release. Sometimes, software should not have been changed. It's not better enough. If there was some reason to change, the developer is in a tricky spot. They have to figure out how to satisfy both the reason for the change, and patch up the pain of the change. This is often genuinely hard. Often when people are frustrated by a change they aren't willing to rationally discuss any option other than "just change it back" and that's what most of the flames end up being about. Developers may feel it's best overall (for users in general) to find a solution other than "just change it back" but if you're in the midst of being aggravated and unproductive you don't have the patience for trying to find the best answer. Having the development process out in the open just pisses people off in this situation, sadly, because they aren't looking to participate. They are just frustrated and trying to get stuff done. It devolves into all kinds of tangents and speculations we're all familiar with (about people's motivations and what's wrong with the software industry and somehow everyone's complaints are what "the community" wants and my identity is at stake and I'm switching to XYZ and I should have been consulted and so on). Lots of drama. Eventually somebody just has to buckle down and say "here are all the known issues and some possible solutions and pros and cons and let's figure it out," make another change that might improve matters, get feedback on that one, iterate again... It's tempting to believe that software design can be a matter of taking a poll or doing some usability tests or some other mechanical system, but unfortunately that doesn't work. It would be nice if it did.
(Log in to post comments)
The GNOME project at 15 Posted Aug 16, 2012 1:24 UTC (Thu) by bojan (subscriber, #14302) [Link]
> Sometimes, software should not have been changed. It's not better enough.
> If there was some reason to change, the developer is in a tricky spot. They have to figure out how to satisfy both the reason for the change, and patch up the pain of the change. This is often genuinely hard.
Example: using 3D rendering. Hardware is already there, which can do a better job of it, relieve the CPU, lower the power consumption etc. So, changing the system to be able to take advantage of it is a good thing (while not breaking the system for setups that don't have 3D rendering). Full marks.
Example: overview. Gnome is primarily a desktop system, not a smartphone or a tablet system. Inventing philosophical reasons along the lines of "minimising distraction" (as if panel autohide didn't already exist and as if notifications could not be turned off) is an example of a change just for the sake of it. Because it was fashionable to do it. In the process, the visibility of the whole desktop was completely lost, GUI/mouse actions became more complicated, windows could not be properly minimised and users are now constantly exposed to completely unnecessary animations. It was not hard to figure out at all that there was zero need for this change on the desktop. Thumbs down.
Example: overview v. fallback mode. Depending on your hardware, Gnome 3 acts in surprisingly and almost entirely different ways. There is no functional reason for this (the main reason is overuse of animation). Both 3D and 2D versions could have been made to look more alike. Thumbs down.
Example: Nautilus type-ahead removal. A great example of a change without justification. Users tell developers that they use and like type-ahead, which is substantially different from search. Developers reply with: "it's gone anyway", because search is better (but it's actually quite something else). Thumbs down.
And so on and so forth.
If developers cannot come up with a genuine functional improvement as a result of a change, they should not be engaging in it.
The GNOME project at 15 Posted Aug 16, 2012 2:12 UTC (Thu) by hp (subscriber, #5220) [Link]
> If developers cannot come up with a genuine functional improvement as a
> result of a change, they should not be engaging in it.
Nobody changes things just for kicks. Truly.
There isn't some moment where people say "OK, I can't come up with any reason this is an improvement, but I'll do it anyway."
The GNOME project at 15 Posted Aug 16, 2012 2:16 UTC (Thu) by hp (subscriber, #5220) [Link] Maybe it was my fault for saying "Sometimes, software should not have been changed. It's not better enough." What I mean is with 20/20 hindsight, in retrospect sometimes it should not have been changed. i.e. people make mistakes.
The GNOME project at 15 Posted Aug 16, 2012 23:47 UTC (Thu) by bojan (subscriber, #14302) [Link]
As I said in some other posts, I think Gnome 3 can actually be fixed rather easily. The Cinnamon effort proves this quite neatly (unfortunately, it also creates even more desktop fragmentation).
The GNOME project at 15 Posted Aug 17, 2012 12:40 UTC (Fri) by codewiz (subscriber, #63050) [Link]
> As I said in some other posts, I think Gnome 3 can actually be fixed
> rather easily. The Cinnamon effort proves this quite neatly > (unfortunately, it also creates even more desktop fragmentation).
I agree. I tried Cinnamon a while ago and I liked the concept, but I found it still a little rough.
Like Unity, Cinnamon probably had to patch the GNOME libraries or live with APIs designed exclusively for Gnome Shell. In recent times, multiple GNOME developers have advocated for tighter end-to-end integration across the software stack, which sounds like a polite way to say that they won't take patches from other GNOME-based desktops unless they benefit Gnome Shell directly.
The situation for distributors is less than ideal: they're being forced to either carry forked versions of upstream libraries, or ship Gnome Shell only.
(disclaimer: the above is based on what packagers are saying in multiple forums, I haven't looked at the patches in question).
|
|||||||||||||