Weekly Edition
Return to the Front pageRecent Features
| |||||||||||||
GNOME 3.0 worries
The mood on some GNOME mailing lists in the weeks prior to the
recently-concluded GUADEC conference was somewhat somber; some members of
the community were clearly feeling that GNOME development had slowed down,
that the project lacked vision, and that GNOME was threatening to lose its
relevance with users. GNOME subsequently emerged from GUADEC with a new executive
director, plans for a 3.0 release, and a new burst of enthusiasm. It's
amazing what a week in an exotic city with large amounts of beer can
achieve. Since then, however, the enthusiasm has dropped a bit, and work
on a proposed 3.0 press release appears to
have stalled. GNOME is now faced with some big decisions, and it's not
clear what the project will do.
The initial driving force behind this effort appears to be a plan by the developers of the GTK+ toolkit to move to a new ABI without concerning themselves with backward compatibility. Years of enforced ABI stability have left GTK+ with a large pile of compatibility cruft which the developers would like to leave behind; in addition, there are major changes planned which would be hard to do in a backward-compatible mode. So the GTK+ developers would like to start over with a 3.0 release. Lots of planning is being done to make the transition easy; among other things, care will be taken to ensure that GTK+ 3.0 will coexist nicely with older installations. But, in the end, it's an incompatible ABI change. At this point, the loudest objections seem to come from Miguel de Icaza. He fears that a new version of GTK+ will leave independent system vendors behind and, perhaps, lead to a series of ABI-breakage events. In particular, Miguel takes issue with the plan to make the ABI changes for the GTK+ 3.0 release, and only add the new features (which, like much of the GNOME 3.0 plan are somewhat fuzzy at the moment) later. The needed new features, he says, should be driving the whole process. And, if at all possible, those features should be added in a way which does not require an ABI flag day. It would appear that the GTK+ developers are determined to make this change, though, so expect it to go forward. But a GTK+ change is not the same as a GNOME change; there is no particular need for GNOME to make a major release just because an important library it uses has done so. Anybody who has looked at the linkage of a GNOME application knows that GNOME uses a lot of libraries; they cannot all drive major GNOME releases. So, one might ask, what is happening with GNOME in particular that warrants a 3.0 release? This question was, arguably, most eloquently asked by Luis Villa, who has described GNOME 3.0 as "a terrible idea." Luis's point is that an ABI change is not enough to motivate a major release; instead, there must be a fundamental vision of a better way to do things. That vision, he says, is not there now. This is not an unprecedented situation in the GNOME community:
2.0 almost failed for this exact reason- before there was a clear
vision about doing usability/simplicity-centered design, the new
version number was a huge invitation to insert $VISION here,
leading to all kinds of crack.
A 3.0 process without a clearly-articulated vision will invite the same sort of "crack." It will also throw away the rare public relations opportunity that comes with a major update:
Finally, from a media perspective: the reason GNOME 2.0 was a
success in the Linux media, and the reason KDE 4.0 has been a
failure, is that GNOME 2.0 had a clear, persuasive story around it:
simplification and usability. No one in the media cared that we had
a new toolkit, except where it had specific features (mainly i18n)
that had user benefits. Writers ate up our usability story- they
could tell their readers the story we put out there, and it made
sense to them. KDE 4 has no coherent user-focused story, so this
incredible opportunity to reach out to the press has been
squandered.
There are, certainly, interesting ideas to be found in the GNOME community. The online desktop ideas, Document-centric GNOME, and the mobile initiatives are examples. But it is true that nobody has, yet, put together a concept of GNOME 3.0 which is broad enough to unify and direct all that work while simultaneously being concise enough to fit onto a bumper sticker. Chances are good that most GNOME developers do not know what GNOME 3.0 really means; those outside of the development community will have even less of a clue. The KDE 4.0 experience should be on the GNOME project's collective mind as it ponders a possible 3.0 release. Future KDE users may see KDE 4.0 as the turning point where their desktop started becoming truly great, but, for now, it does not look like a whole lot of fun for the KDE development community. GNOME developers, one assumes, would prefer not to have a similar experience. GNOME 2.x has been around for some time; it may well be true that it is time to make a big jump. It would be gratifying to see some new energy and directions from the highly creative GNOME development community. If the project can come up with a set of overall goals which can inspire that community toward a set of common ends, GNOME 3.0 could be a spectacular success. But those goals, if they exist, have not been communicated to the community yet, and that is making some GNOME developers nervous. (Log in to post comments)
GNOME 3.0 worries Posted Jul 24, 2008 6:42 UTC (Thu) by louie (subscriber, #3285) [Link] (Luis Villa here.) It is worth emphasizing that there are lots of great options for GNOME out there. Jon mentions a couple in online desktop and document-centric ideas; in addition, deep integration of search, 'people', and collaboration have all also been discussed. So I'm not, overall, worried about the future of GNOME- one or more of these will happen. And in the meantime, there has been tons of incremental progress in refining the desktop experience and laying the groundwork for the next generation of desktop. I just don't think calling anything '3.0' makes sense until there is real movement in one of those directions.
GNOME 3.0 worries Posted Jul 24, 2008 8:22 UTC (Thu) by jhellan (subscriber, #17103) [Link] Speaking as a Gnumeric developer currently on leave, I have to say that the Gnome 3.0 proposal sounds like a plan to turn one trainwreck (the GTK API/ABI break) into two. Jon Kåre Hellan
GNOME 3.0 worries Posted Jul 31, 2008 5:58 UTC (Thu) by ovitters (subscriber, #27950) [Link] Could you be more specific than train wreck? We're open to suggestions, but if your only argumentation is 'train wreck', then you're obviously going to be ignored.
GNOME 3.0 worries Posted Jul 24, 2008 8:32 UTC (Thu) by ikm (subscriber, #493) [Link] My idea: revert to 1.4 and call it 3.0.
Revert to 1.4 Posted Jul 24, 2008 21:26 UTC (Thu) by rfunk (subscriber, #4054) [Link] Or call it XFCE.
GNOME 3.0 worries Posted Jul 24, 2008 9:25 UTC (Thu) by MathFox (guest, #6104) [Link] In my opinion (as user) a desktop is there to enable a user to do his/her work efficiently. Having a stable, reliable and usable platform is what the user cares about. If there is no coherent well laid out vision of a big leap forward in the user interface, just stick to incremental improvements. I can imagine that GTK+ is working on a new ABI. That does not mean that the new GTK+ would be API-incompatible. If a mere recompilation of GTK/GNOME program is enough to move it to GTK3, there will be few compatibility issues for Open Source programs.
GNOME 3.0 worries Posted Jul 24, 2008 10:21 UTC (Thu) by Frej (subscriber, #4165) [Link] If we are looking for core stuff to change, here is one. :) Look at how many ways we show a program depending on it's state. Why? For me rhythmbox shows up three places, if you subscribe to the idea of topbar as shortcut bar. "A program in memory is the same as program on storage". [1] There is a technical difference, but who cares? [1] I gave up on a non-techie phrase, i suck.
GNOME 3.0 worries Posted Jul 24, 2008 13:37 UTC (Thu) by nix (subscriber, #2304) [Link] 'Program in memory == program on storage' works only until you do a backup, and is really annoying unless you have truly infinitely-long undo (or persistent time-expired undo at least). Otherwise, you make a mistake and you can't tell if you can undo it or not...
GNOME 3.0 worries Posted Jul 24, 2008 10:25 UTC (Thu) by russell (subscriber, #10458) [Link] As a long term gnome user, I'm worried this will end badly. There has been little, if any, far reaching direction during the recent incremental development. While this may be a result of incremental development; where people get used to looking only a short distance in front of them; it does mean they don't have a well oiled machine developing direction. If I could suggest a place to start looking for a 3.0, it would be with the HIG, not a particular gnome component or feature set. It shaped 2.X and could do the same for 3.X Components change all the time, but it's the HIG that users see.
GNOME 3.0 worries Posted Jul 24, 2008 11:31 UTC (Thu) by filipjoelsson (subscriber, #2622) [Link] I'd like to advocate "integrity and connectivity". If I knew that my data was safe(r) with gnome than with the alternative (xfce) - I'd switch back in a minute (I'm on gentoo - there's some compilation involved here, would switch back even faster otherwise ;). For example, if I'm reading some interesting webpage and firefox/linux crashes (or I have to shut down in a hurry and killall -9 firefox) - the next time I start firefox, I get the choice to restore the browser to where I broke off (to the point that I get to keep browsing history and pretty much everything else). I'd love to have this as a standard behaviour in gnome apps! The second thing would be to have connecting my phone/pda do the right thing. (Admittedly it's been a while since I last tried and was dissatisfied with the solultion.) Having connected a phone should result in having gui access to contact list, alarms/reminders, storage and modem without following four different howtos.
GNOME 3.0 worries Posted Jul 24, 2008 15:06 UTC (Thu) by drag (subscriber, #31333) [Link] Instead of really getting to into 'the vision' it's time for 'put up or shut up'. One of the 'natural' aspects of software development I've noticed is that you have a very very very hard time defining the question without working on the answer. That is your ideas about what a program should do and how it's going to do it is going to be wildly different from the actual practical execution of your ideas. You can't predict in a accurate manner what your needs are until you actually need them. So what needs to be done is that people need to start hacking their ideas into Gnome and GTK. Start moving, start shaking things up. If they wait around for everybody to agree with them THEN NOTHING WILL EVER GET DONE. That's all. There is never any guarantees to anything in life. So people, who want change, are simply going to have to start hacking those changes. When they reach a brick wall, when they reach the point were the policy of ABI compatibility is holding them back then they mark that up and discuss it with other people. Everybody who is prominent seem to say the same thing: 1. Breaking ABI for Breaking ABI's sake is stupid and destructive. 2. Don't pull a KDE 4. If Gnome does that it will be a huge mistake. 3. Not totally against ABI breakage.. They just need a _demonstrable_ and have a very damn good reason why it _needs_ to be broken. If people have a concrete reason why they can't do what they want and they have a plan of action then that's a entirely different matter. As a end user I care about a few things, in the order of importance, starting with the most important: 1. I need my applications to run. I need to be able to get work done on a day to day basis. 2. I need a effective work environment with good work flow, consistent, and is fast to use. (this is very different from actual code performance. The code can be slow as crud as long as it's faster then me I don't really give a damn) 3. I need to have decent documentation (doesn't matter were, just as long as it exists and is accessable) and good help system. 4. I need the ability to write simple programs in a sane and consistent manner. I need to be able to deploy these programs. I need to be able to run these programs created by other people. I need to have these programs to be able to run without constant maintenance. (aka enterprise-ish stuff) 5. I want it to be fast. I want it to take advantage of my hardware for efficiency and run fast on older machines to reduce the cost of running the software. 6. I want it to be pretty. Pretty is very good. Pay careful attention to the needs vs wants. Just my opinion. Take it or leave it. If your a Gnome developer, this is your project and all I can say is 'Go for it'. Really.
GNOME 3.0 worries Posted Jul 24, 2008 23:10 UTC (Thu) by russell (subscriber, #10458) [Link] The days of hack it in or your opinion doesn't count are over. If people don't share a common vision it won't happen because gnome is too big for one person to hack it all. Who's going to be the person to hack multi touch into everything? Without a vision of what it should be everyone will implement it differently.
GNOME 3.0 worries Posted Jul 25, 2008 5:51 UTC (Fri) by drag (subscriber, #31333) [Link] It still works great for the Linux kernel. People hack in all their own favorite little projects all the time and if they are good enough, get them into the kernel. And unlike Gnome, the Linux kernel is a massive project that is supported by all sorts of corporations and is used in very mission critical all over the place. Which approach do you think is the best one? It's quite possible that what Gnome needs is much less 'vision' then it currently does. "Show us your code or shut-up" is something that I think is a good approach in a open source project. What people want it in this 'break API' thing is demonstrable reasons why it needs to be broken and in what ways and why breaking it would be a great idea. Without that it's all just hand waving.
GNOME 3.0 worries Posted Jul 28, 2008 23:39 UTC (Mon) by russell (subscriber, #10458) [Link] The kernel isn't quite what you think. If your stuff doesn't meet with the vision of the senior developers it won't get in full stop. There is a lot more "vision" imposed in the kernel than in gnome. 20 years of engineering have shown me there is one constant about software engineers. They know what there user whats, how the user should do it, and they are always right ( At least that what they think ).
GNOME 3.0 worries Posted Jul 31, 2008 18:01 UTC (Thu) by ipes (guest, #43384) [Link] > 2. Don't pull a KDE 4. If Gnome does that it will be a huge mistake. Not doing it would be an even worse mistake though. Gnome will simply be left behind. Just look at KDE 4.1. Compare it to KDE 4.0 and 3.5.9. Extrapolate to KDE 4.2.
any detailed info on GTK+ plans? Posted Jul 24, 2008 17:38 UTC (Thu) by brouhaha (subscriber, #1698) [Link] Is any info on the GTK+ plans online somewhere? I keep hearing about it, but haven't found anything substantive. Surely someone from the team must have given an Impress presentation or something? The GTK+ roadmap in the wiki seems to be out of date. If people have a problem with a 3.0 release of GTK+ not having new features, there's a simple solution. Call it 2.90, and work from that toward a 3.0 with whatever fancy new stuff is desired. I have no sympathy for the people bitching about the GTK+ API changing. If you don't have a clean break at some point, it will just keeping accumulating cruft. If there wasn't a plan for 2.x to work in parallel with 3.x for a while, it would be a valid concern.
any detailed info on GTK+ plans? Posted Jul 25, 2008 0:29 UTC (Fri) by giraffedata (subscriber, #1954) [Link] If people have a problem with a 3.0 release of GTK+ not having new features, there's a simple solution. Call it 2.90, and work from that toward a 3.0 with whatever fancy new stuff is desired. The way I read it, the problem they have is with a release of GTK+ having a different ABI and no new features. I.e. pain without gain. I assume the advantage of doing that lies in a smoother transition, for users and developers.
any detailed info on GTK+ plans? Posted Jul 26, 2008 19:07 UTC (Sat) by mmarsh (subscriber, #17029) [Link] My impression was that the "gain" in the ABI breakage would be a smaller, more-responsive GTK+ due to the expulsion of cruft. That can be pretty significant for a lot of people, say those of us limping along on six-year-old laptops.
any detailed info on GTK+ plans? Posted Jul 27, 2008 8:19 UTC (Sun) by dannyobrien (subscriber, #25583) [Link] Honestly, it might make sense to make 3.0 the "lost the cruft" update for GNOME, too. Just do a major, no extra features, overhaul of the whole system. It might not be as badly needed, but if you do it now, and flag that's what you're doing, I don't think anyone would be upset. I don't know enough about GNOME internals to pinpoint what that cruft would be, but I bet every developer has a little list of their own...
any detailed info on GTK+ plans? Posted Jul 29, 2008 18:38 UTC (Tue) by oak (guest, #2786) [Link] > My impression was that the "gain" in the ABI breakage would be a smaller, more-responsive GTK+ due to the expulsion of cruft. That can be pretty significant for a lot of people, say those of us limping along on six-year-old laptops. Do you have any link that would list this "cruft" and any *numbers* on what expelling it would gain? I doubt the speedup would be anything user visible (10% sounds pretty optimistic and something like that isn't really user visible).
any detailed info on GTK+ plans? Posted Jul 29, 2008 18:59 UTC (Tue) by brouhaha (subscriber, #1698) [Link] I too doubt that there would be any speedup. I think the issue is more a matter of getting rid of deprecated interfaces and fields so that new code doesn't have to support them. There's too much internal detail exposed, which makes it difficult to add new features while maintaining full compatibility. That's why they want to make the structures opaque and use setter/getter functions.
any detailed info on GTK+ plans? Posted Jul 29, 2008 23:14 UTC (Tue) by mmarsh (subscriber, #17029) [Link] No. The article mentioned cruft, and it's a natural assumption that there's likely to be speed gains in ditching it. How much -- who knows? Not having to maintain backwards compatibility means that developers can focus on other things, and it's difficult to predict what those gains might be. Efficiency isn't an unreasonable guess. Honestly, the only speed impact I really notice from GTK+ is when firefox is rendering a particularly complex web page in a backgrounded tab, bringing the current tab essentially to a halt. That's not too frequent an occurrence, though.
any detailed info on GTK+ plans? Posted Jul 30, 2008 0:38 UTC (Wed) by oak (guest, #2786) [Link] > The article mentioned cruft, and it's a natural assumption that there's likely to be speed gains in ditching it. How much -- who knows? Anything performance related should be backed up with test-case(s), numbers and conclusions based on those numbers, everything else is bound to be dead wrong. > Honestly, the only speed impact I really notice from GTK+ is when firefox is rendering a particularly complex web page in a backgrounded tab, bringing the current tab essentially to a halt. I don't think this has anything to do with Gtk. Firefox doesn't use Gtk to draw www-page content (for obvious reasons, Gtk widgets are quite different from www-form widgets) and if it's in background tab, there isn't even anything to draw. I think it's more to do with JavaScript & Flash content (Flash doesn't use Gtk either), CSS and complex page layout / layering. Firefox has all tabs in same process (to save memory I assume) and AFAIK doesn't really thread its work that much.
kde 4.0 problems Posted Jul 31, 2008 10:03 UTC (Thu) by hyartep (guest, #53194) [Link] As I see it, the only problem with KDE 4.0 is that it should be called KDE 3.9. It was well stated the 4.0 version is not suited for joe average user, but as preview and version from which applications should begin to stabilise. Unfortunately, everybody was eager to try it out and forgot that it was not expected to be super stable and finnished. Now 4.1 is far better (it is published, along with KDE-PIM, but some apps, that are not direct part of KDE, such as Koffice or Amarok are not ready yet). And probably 4.2 will be great with most apps ready (these are just my expectations).
kde 4.0 problems Posted Jul 31, 2008 11:20 UTC (Thu) by forthy (guest, #1525) [Link] KDE 4.0 is more a PR disaster than a technology disaster. It should have been KDE 3.9 or KDE 3.99, a "sneak preview" for ordinary users, the base of development for other people. Apparently, the inner working of KDE 4 is sufficiently better that projects like kdenlive ditch their KDE 3 support, and go straight to KDE 4 for the next release. That's how it should work. I agree that for normal users, KDE 4.2 is probably the best time to switch over - KDE 4.1 is some sort of "beta" quality for normal users - good enough to work with it long enough to find the more subtle bugs. KDE 4 has certainly someone with a vision driving it forward.
KDE 4 and Gnome 3 Posted Jul 31, 2008 19:42 UTC (Thu) by guym@arizona.edu (guest, #14981) [Link] a. It is not a given that if Gnome simply focuses on refining the great desktop they have, while KDE spins out after dumping the great desktop they had, that Gnome will be at a disadvantage and lose increasing numbers of users. In fact the opposite might be true. b. Also as a long-time KDE user myself, I'd like to submit that KDE 1.0 was the turning point where my desktop started being truly great.
|
|||||||||||||