4 ms·
I use Gnome 3 daily, and I have to say that some of the points do have validity. However, it's only a matter of time until these minor issues are fixed, and I
by hahainternet 14y ago
I use Gnome 3 daily, and I have to say that some of the points do have validity.
However, it's only a matter of time until these minor issues are fixed, and I happen to think that the general design is excellent.
- ajross 14y agoGnome 3 has been shipping in Fedora for over a year now, and they just pushed the third such revision. I'd say they're running out of their matters of time and entering the realm of "long standing breakage" at this point. Here's my biggest personal peeve: keyboard navigation in the overview screen has never worked. The gnome-shell process in that mode steals events from gnome-settings-daemon (which normally handles hotkeys). This means that if you like to do things like launch apps from the keyboard (I mean: who wants to launch an app when in the overview/app-launcher screen?!) it just doesn't work. Combine that with the fact that the overview screen pops up automatically when you close the last window on a screen (I mean: who wants to launch an app just after closing another one!?) and it drives me up the wall daily. Three times now I've straight up decided to fix this, but it's a non-trivial codebase and I always give up before making it work. The core folks really need to look at this problem, but at this point I doubt they ever will. Consistent keyboard navigation is clearly not a priority. (edit: this is the issue in question: https://bugzilla.gnome.org/show_bug.cgi?id=643111 https://bugzilla.gnome.org/show_bug.cgi?id=643111)
- ChuckMcM 14y ago"However, it's only a matter of time until these minor issues are fixed" I think that is not true, And I'll share my reasoning as to why I believe that and then someone can help tell me why I'm wrong. My argument is that 'minor issues' are a function of design change + implementation maturity. Which is to say that as a design evolves, the evolution requires changes in the base code, these changes have ripple effects on other things that had made assumptions about the implementation and tracking down the ripples gets as far as the 'big ones' and then it ships with the proviso that the smaller problems will get ironed out 'over time'. Except once you release the newer version it sparks new design changes and those changes create ripples of their own and so even when the original minor irritations are fixed, you cannot tell they are fixed because there are new minor irritations to contend with. I claim that this is an unavoidable consequence of the 'bazaar' aspect of FOSS development. People write code, they want to contribute, they change stuff, there is few barriers to good ideas getting into the project, so there is no governor on change so there is no time for the changes to stabilize. In the 'cathedral' mode some company stops development, and works only on stability for some period of time, so that the final product is 'done.' This is not to say that cathedral software doesn't have 'minor annoyances' it can, but often that version will continue to be stabilized with no new features over time. And that is externally enforced by a management heirarchy. I think it would be safe to say that minor issues that are left in Gnome 2 will be fixed over time, as there are very few people putting in new features to 2 and slightly more people putting in bug fixes. But that occurs because its a 'dead' project from the perspective of 'new' stuff.
- technomancy 14y ago> "However, it's only a matter of time until these minor issues are fixed" "Give me an API flexible enough and a repl in which to hack it, and I shall move the world."