Re: Putting the 'Mono debate' back on the rails

["Eugenia Loli-Queru" <eloli hotmail com>]

> 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