First, I am not a GTK+ contributor and so it isn't my intention to try to force my will upon people that actually do great work on it. But since I may be looking into using GTK+ for a new scientific simulation application I though I'd pitch in.
I had actually written a fairly lengthy piece on why I was against a 'Deprecation 3.0' when I realised that it really doesn't matter. What matters is that the two prevalent agendas of 'new, fun and exciting' and 'stable and productive' are actually quite mutually exclusive when it comes to a toolkit library such as GTK+. Thus this discussion could actually go on forever with no agreement whatsoever. ISVs that care about 'stable and productive' are going to be upset about moving to a new GTK+ with no new features. Keeping cruft on the other hand, and forcing API/ABI stability on the other hand, is going to make it much harder to attract people to help with the fun and exciting bit and it is going to upset people that want to create new things requiring API changes. Since it is almost impossible to please both camps with one path, the longer the community argues and drags its feet, the bigger the chance of a fork is, and the later this fork happens, the more resentment it is going to cause. There is no need for bad vibes, there is room for both luddites and freaks. So, why not start a friendly fork right now, it is well overdue. I suggest people that want to create exciting stuff just do it without further politics and discussion. Just create a new GTK+ 'next generation' branch and knock yourself out, you can even call it '3.x', if the understanding is that the next stable GTK+ will be 4.x. Let this be a blessed fork, with the understanding that exciting stuff is carried out in the fork. This doesn't even mean they will end up being completely separate. There is every chance some people may be working on both branches, i.e the 2.x one for their dayjob and the development one for fun. Some people may even start porting their apps straight away because they want cool and fun new features. Finally, when the new branch is interesting enough, start working towards getting this blessed as the new and official GTK+ (3.0, 4.0, whatever). If the API changes are too big for people to swallow, a libgtk-legacy to help porting sounds like a good idea. In the end, the only thing that matters is code (and love). -- Gaute Lindkvist
_______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
