>Just being in the bindings set doesn't really get app developers anything.
I very much disagree. Being in an official gnome release (even if that's just bindings), it is like Gnome saying to distros and devs out there: "look, here's gtk#, it's now stable, it works well, go ahead, install it and use it". This inclusion alone will bring new devs that will use gtk#, because they will feel more safe regarding using it and making sure that their users won't have major dependencies problems when trying to install their apps. Being part of gnome offers some guarantees to these devs (even if eventually are not always materialized). >And from the earlier discussion, it sure doesn't sound like >there's "consensus" to "bless" Gtk# as a Desktop set dependency. I agree that this is a matter that the Gnome Project should find a solution regarding what's gonna be its next-gen language/environment. But I think you should start with the Bindings. There is a first step for everything. Let the naysers get used of the idea first. Be a bit strategic and diplomatic. While I am personally neither, ask other women. They know all about the art... ;-) >My Gtk#-lite 2.16 binding would be allowed to break API in 2.18 as long as >I make it parallel-installable I agree, this sucks. Other bindings do it like that and they irritate the hell out of me -- at least as just a user. I like compatibility at all levels. That's how MS took over the world, by providing full backwards compatibility with MS-DOS apps of 1981. That's how IBM still services and makes big bucks on programs written in 1965. Well-tested backwards compatibility (at all levels) is one thing that OSS devs don't actively seek. I do hope that this changes at least in Gnome. I personally want bindings to be really compatible with their previous versions, version after version. Miguel wrote: "I would be interested in understanding what the issues of non-splitting are, from the GNOME point of view." For one, if in the future Gnome would like to provide an embedded version (there was some talk about it already), it would be easier to pick and choose components as seen fit. In a 64 MB firmware you can't fit everything, usually... Of course, I don't think that this means that you need 3 different tarballs instead of 1. As long the selective functionality is present in your current tarball (via an autoconf option), I don't see why it should be physically split in different tarballs. But some form of seperation must exist as the rest of the Gnome is very modular in its nature. Another reason is easier testing. If your third party devs get a bug and they can't figure out where it's coming from exactly, by removing components they can easier isolate the problem. Maintaining the bindings will also probably be an easier affair. Lastly, I believe that having a modular GTK# is better for GTK# itself. Think about it: a third party embedded company wants to use it, but it doesn't care about all the gnome libs stuff. It would be easier for them to pick the components they really need rather than having to compile and use everything -- and their deps. Finally, if the XFce guys would wanna use it in their desktop in the future by binding it with libxfce, now they would be able to. Right now, GTK# is so monolithic that they don't even bother. Please refer to the email I sent yesterday. You can still offer a migration path to your existing apps and maintain it as long as you see fit or needed. Not all is lost. Rgds, Eugenia _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
