What about Gnome 3.0?
25. September 2006
Why and when?
To me, Gnome 3.0 (or ThreePointZero) looks like a phantom. There are several thoughts filed about it in the wiki but it’s completly unclear when work on 3.0 will be started and what will be the real goals. Nobody knows if 3.0 will come after 2.18, 2.20 or 2.22.
I personally think that Gnome 3.0 should come after 2.18 because the platform is mostly cleaned up and it’s really time for a break!
How I would like to see 3.0
-
Platform: Developers hate platform changes! So little changes here would be great. There are a few things which need integration for example GUniqueApp, a gnome-vfs replacement and of course all the deprecated stuff will disappear. A little API clean-up here and there would be good but I do not think that the changes should be that big as from 1.4 to 2.0.
Imporant for 3.0 is that people get more aware that for usual Desktop applications it’s much easier to use Python, C# or C++ instead of C and that (Gnome == C) != TRUE. That would also mean that really all needed libraries are covered by the language bindings. - Desktop: Most agreement seems to be in using a more document-oriented approach. This does not mean to force the user to use this approach but it should be made easier. There is this very cool gimmie project which might replace the panel somehow.
- Integration: It would be really cool if the user would not know wether an application he uses was made for XFCE, Gnome or KDE. It should simply work and look like any other application on the Desktop. FreeDesktop.org has come a long way but for 3.0 we would have the possibility to throw much incompatible ballast away. Of course this is an not a Gnome-only problem.
These are just my thoughts and don’t give to much about them because I am not a gnome core developer and I may even have missed lots of things that are already planned for 3.0.
BTW (and for me not to miss the link), Maintainer looks really cool!
25. September 2006 at 16:14
Johannes, I think it’s important to note that none of those features really needs a break of API/ABI (except for the obvious module removal). Havoc Pennington wrote up a document on that a while ago. I can’t find the direct link, but he mentions some of that stuff in this email.
In short, we can do most of this in GNOME 2.x, so let’s aim for that. GNOME 3.0 is either a marketing term, or a silly excuse to remove modules from the platform. The second is a poor excuse. It only reduces memory load for those modules that were not yet updated, and for those modules it creates a maintainer burden also. This is not good for a platform, although it will probably look good PR-wise. Modules compiling with *_DISABLE_DEPRECATED have no advantage from this break. This only leaves the PR argument. And really, there is not reason to break API to generate some PR. Just call 2.18 3.0. No breaks, no fuzz, just call it 3.0.
25. September 2006 at 16:36
Good Point!
I just wonder if it is possible to integrate
Glib VFS and supporting it together with gnome-vfs.
There are several thoughts to have something like glade in gtk, which won’t make things much easier, if you have two incompatible xml UI libraries.
BTW, Gnome 2.18 will ship without bonobo, libgnomeui, liborbit, etc. Is this not a API/ABI break?
25. September 2006 at 17:43
I only see API changes as a good reason to switch major version number.
However. Given that a lot libraries are planning to refactor, like take .. gnomevfs .., I don’t think we should try to keep some sort of false promise that we wont break API.
It would simply be lying. It’s not because one library (gtk+ itself) of the stack isn’t going to change a lot, that the GNOME development platform isn’t going to change. It most certainly should and probably will change a lot.
Also note that you make a contradiction:
“Imporant for 3.0 is that people get more aware that for usual Desktop applications it’s much easier to use Python, C# or C++ instead of C and that (Gnome == C) != TRUE. That would also mean that really all needed libraries are covered by the language bindings.”
The problem is that a lot of the current API IS NOT FIT for modern language bindings and modern programming methods. A lot can be fixed by creating adaptors in a new library on top of the existing stack. But some parts will probably have to change (or will or would change after people find-out that it’s not longer interesting to keep maintaining these adaptors).
In my opinion, GNOME 3.0 is so far away that we should not give false ideas or promises about API changes already. For one thing, such promises would basically stop and block young people from trying to envision a better development environment. From trying to experiment with different ideas.
Look at what MacSlow is trying to put together with his lowfat. Sure that’s not yet a GNOME 3.0. But if we are simply going to make a new GNOME 2.x and for some silly marketing reason call it GNOME 3.0, yet don’t innovate a lot (because innovation would simply break API), then such decisions might put a break on peoples ideas. Those people will very simply decide to switch to another technology. And sooner or later, GNOME would be obsoleted.
25. September 2006 at 17:47
If you are planning to support modern programming techniques, look at the lessions of Microsoft with .NET and Sun with Java. They didn’t try to stick to backward API compatibility or whatever. That decision DID NOT make them a lot less popular. They did, however, designed their frameworks in such a way that it would be more flexible and more adaptive to changes and future.
That, they indeed did.
25. September 2006 at 17:53
To give you an example where the gtk+ api isn’t fit for modern programming techniques: a lot gtk-sharp developers are thinking about writing a gtktreeview in .NET to have better integration with the development framework itself. For example databinding a model to a tree view is still a major problem with it. Another big problem is that typical C thingy called doubly linked lists that aren’t easy to support on (the) two (of the) most important modern programming languages: Java and .NET. They also aren’t very easy to support on Python btw. Yet these GList things (because they ARE “things” for most OO developers, who care used to iterators or enumerators and enumeratables, lists, etc etc) are used a lot.
I can give a lot more examples where the GNOME development platform is typically a C development platform with a not-as-good-as-we-think integration with modern programming practises and techniques. And where refactoring and significant changes, also in the API, *are* actually needed .. indeed.
25. September 2006 at 22:11
[…] If we are going to decide now that a GNOME 3.0 should be as API stable with GNOME 2.x as possible, we are going to give them what is current today. Not what will be current when their tomorrow happens. Therefore I disagree with Johannes a little bit that we shouldn’t make (big) API changes. […]