Lots of discussion about Gtk+ 3.0 lately, unfortunately there's no real discussion going on (heh).
There's the camp that is excited about API/ABI breakage and there's the camp that isn't so enthused.
I have to take the side of the "not so enthused", alongside Miguel de Icaza[1][2], Havoc Pennington and Morten Welinder: it's crazy insane to go breaking API/ABI for the sake of cleaning up the API without adding new functionality that could not be achieved by simply extending the current 2.x series.
There are definitely things that can be done to the current gtk code base without having to break the current API/ABI to achieve them, so in my humble opinion that's what should be done. Granted, eventually there will have to be a Gtk+ 3.0 which breaks API/ABI in order to add some new functionality that isn't possible to implement in 2.x, but that road can be crossed when we get there. No sense breaking it now if it isn't absolutely needed.
Even more worrying is the lack of promise to not break API/ABI again after 3.0. In fact, I've read on one of the mailing lists or somewhere that they plan on breaking API/ABI every 4-5 years after 3.0, ripping out any API's they marked as deprecated in the meantime. This is crazy. One-Flew-Over-the-Cukoo's-Nest crazy (or, if you prefer, I'm-Cukoo-For-Cocoa-Puffs crazy).
For large applications (Gnumeric, Evolution, Mozilla, Eclipse, etc), porting from 1.2 to 2.0 was a huge PITA but we all did it because (besides being young and stupid) 2.0 made a long-term commitment to maintain API/ABI compatibility going forward in addition to the fact that it added a ton of much-needed functionality (accessibility, UTF-8, model/view, and really good text layout w/ support for RTL and CJK).
If 2.0 was just 1.2 + sealed structs and the removal of some deprecated APIs, no one would have bothered with 2.0.
To respond to a point on Tim Janik's blog:
3.0 will ABI-incompatibly remove all deprecated and private APIs. Of course, the above described deprecation scheme only scales well if deprecated APIs are really removed from the code base at some point.
One reason that ISV's are typically on-board with Microsoft is that Microsoft has gone to great lengths to maintain backward compatibility with their old APIs. Joel Spolsky talks about it a bit in How Microsoft Lost the API War (specifically, the section The Two Forces at Microsoft).
The Windows testing team is huge and one of their most important responsibilities is guaranteeing that everyone can safely upgrade their operating system, no matter what applications they have installed, and those applications will continue to run, even if those applications do bad things or use undocumented functions or rely on buggy behavior that happens to be buggy in Windows n but is no longer buggy in Windows n+1.
I'm not going to argue that Gtk/GNOME should go to these extensive lengths to make sure buggy apps continue to work, but there's no reason that G*_DISABLE_DEPRECATED can't simply mean "we're not going to bugfix these anymore, what you see is what you get". You don't have to ever remove them, especially since it likely doesn't require much maintenance to keep them around. The port to Gtk+ 3.0 would require some work to make sure all the internals of things like GtkCList use accessor methods to anything that they use internally, but after that the job should be done and over with.
(ABI might not be a bit hard, but you could maintain API - thus meaning a simple recompile would work)
On the *giggle* *giggle* You should be using Mono/Gtk# *giggle* *giggle*-side, any application built against Gtk# 2.x will still work with Gtk# 3.x w/o any changes :-)
Oh, and Gtk# has DataBinding support (which, btw, does not require API/ABI breakage to Gtk+ nor sealed structs like some people seem to think on this morning's #gnome-hacker's discussion *cough* *cough*).
8 comments:
I'm glad to hear that Gtk# isn't going down road. I cannot help but think this kind of shit is why Linux never seems to stabilize. Even Microsoft lets us get off the tread me and catch our breath once in awhile.
Jonathan Allen
InfoQ
I have to point out that there are still apps that use GTK+ 1 and there are some that will never be ported to GTK+ 2 (or 3).
You make it sound as if GTK 3.0 can exist easily as "natural" evolution from 2.0.
So why is there any discussion at all for a GTK 3.0 if there are no problems in GTK 2.0?
I for one see web apps being developed in an awesome AND easy fashion, and I must tell you that I think there are problems with the graphical toolkits. Most specifically they require WAY too much effort to create EASY and nice applications, even if one uses to rely ruby or python instead of C... ;-)
Not just that. They are going to break the ABI without knowing what features they want to add, or what those features will need in their new interface. It's like they are shooting in the dark at a mob of brain-eating zombies, but only managing to shoot the ground, and hoping not to hit their collective feet.
Of course there are projects, wich are and will not be ported to a newer platform. Have always been.
Now, I think, not matter people whine and bitch about it, that it is now important to break the api/abi and let gtk+2 and gtk+3 coexist. Making gtk+3 is a rare possibility to do some refactoring to make it possible to add new functionality in the future while maintaining a clean api.
In other words, break it now so you don't have to break in the near future.
Stubbornly hanging on to the gtk+2 is just not healthy for the toolkit and making 3.0 doesn't render the programs made for 2.0 unusable.
One reason that ISV's are typically on-board with Microsoft is that Microsoft has gone to great lengths to maintain backward compatibility with their old APIs.
This strikes me as a reason to keep gtk+-2.0 libraries in the distros; not an argument against making an ABI incompatible gtk+-3.0.
I've only been marginally following this discussion, but what I understand of the plan is reasonable enough. The proposal is to just drop deprecated features and close off private interfaces people largely shouldn't have used in the first place, right? So porting should be nothing like the 1.2 -> 2.0 transition.
Of course my view may be tainted by how much time I've spent this week trying to migrate a tangle of legacy services that rely on abandoned interfaces noone supports or fully understands any more.
wdomburg: well, sort of...
The problem is also that some of the features they plan on adding post-3.0 (because, let's face it, no one is going to port to 3.0 just for sealed structs) can be added now, w/o API/ABI breakage to 2.x.
Adding them to 2.x means that application developers can get more features w/o having to port their code again.
The other problem with the 3.0 proposal so far is that no one has taken the time to figure out what the API should look like for the only new feature that has been hinted at that will require API/ABI breakage (scene graph) and so it's impossible to guarantee that sealing the structs is all the API/ABI breakage that is required to add this new feature.
The fear is that the Scene Graph functionality that is being considered will require yet another API/ABI break after 3.0 which just means app developers will again need to spend time porting their apps (to Gtk 4.0) just a few short years after 3.0.
It's best to minimize API/ABI breakage to as few times as possible (to minimize wasted time/effort porting, aggravation of application developers/ISVs, etc). If there is a good chance that Gtk will have to break API/ABI /again/ in just a few years, why break it now? It'd be better to wait a few more years and only break it when it is absolutely needed.
@markus
>> I for one see web apps being developed in an awesome AND easy fashion
Huh? Awesome and easy? You must have never done a web app before. Web apps are awful and mind numbingly stupid compared to building desktop apps. Unless you're just targeting one browser, that is.
Post a Comment