Re: Putting the 'Mono debate' back on the rails
- From: "Eugenia Loli-Queru" <eloli hotmail com>
- To: "Miguel de Icaza" <miguel ximian com>, <mkestner novell com>, <desktop-devel-list gnome org>
- Subject: Re: Putting the 'Mono debate' back on the rails
- Date: Sun, 23 Jul 2006 15:53:55 -0700
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
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
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
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.
] [Thread Prev