[Java-gnome-developer] Re: What to do in order to make the gnome development platform rock.

[Havoc P. <hp...@re...>]

Christian Schaller <Ur...@li...> writes:
> Well as someone just begining to meddle in Java I like your ideas, I am
> CC'ing it to the java-gnome list also. 

I'm not sure changing namespaces is really a good idea; for the
forseeable future, most people will be mixing multiple languages
(usually C and another), and having to use docs written for C.  So
changing namespaces around is just extra confusion.  Also, changing
namespaces complicates automated binding generation and may introduce
naming conflicts where none existed in C.

I think the real solution is that the C libs should be more
coherent. ;-) Which we are gradually moving toward. Many of the libs
mentioned are very experimental or beta; really, it is OK for these to
be confusing. People who want a simple straightforward easy-to-learn
API should not be fooling with eel, gal, etc., definitely, and most
likely should start with plain GTK and move to other stuff only as
they feel the need. Since Java itself fills in most of the gaps plain
GTK has (such as a portable file abstraction), I don't think there's
much problem with that.
 
Anyhow: eel, gal and other experimental libs should NOT be
aggressively promoted outside of "GNOME insiders," because they are
neither software-product-system-quality nor particularly API-stable.
These libs are for people who know what they are doing.

I would actually extend this comment to libs other than eel and gal,
but am avoiding flamewars today, and everyone already knows I have
that opinion. ;-)

But, longer-term we need to slowly move our platform into something
more coherent. One of the big barriers is to remove the current
situation with multiple object/type systems (CORBA and GObject), which
is something we discussed with Michael when he visited Red Hat. We
want to do this longish-term, we are talking 2-3 years out probably.
This is the single largest flaw in the coherency of the current devel
platform IMHO.

In the short term, slowly migrating APIs to a position in the
dependency chain where they "make sense" (as gdk-pixbuf moved in GTK
2, and can now be used in GtkImage and other logical places) is
something we can do to make progress.

> I think giving official status of a set of bindings would probably also
> be an idea, for instance there are 3 different Java bindings for GTK+
> and GNOME underway AFAIK and maybe if one of them got recognised as the
> official GNOME bindings the duplication of effort could be minimized.

I don't agree, I don't think we should be in the business of making
decisions like this.

 - redundancy is good; it saves us if one project goes unmaintained
 - who would decide? I don't know Java bindings, only the biased
   authors of the bindings can know this
 - once something is official, it has an annoying inertia, which 
   is hard to overcome when something better comes along

If we were actually going to use Java, it would be different - we
could "endorse" one Java binding by using that one. But in general I
don't think we should "bless" stuff on the net that we don't use. We
have enough trouble getting the set of stuff we _do_ use sorted
out. (*conf controversy, bonobo controversy, etc.)

Once one of the Java bindings is really mature it will become a de
facto standard, the others will fade away, then we can point people to
it. I'm not sure we want to push this sort of thing really hard before
it's mature, anyway.

Havoc