java-gnome-developer

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

[Christian S. <Ur...@li...>]

Hi Kenneth,
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 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.

One thing I do think however is that we should demand that any language
bindings that are to become/get approved as the official GNOME and GTK+
language bindings are that they move into GNOME CVS.

Christian

On Sat, 2001-09-15 at 19:17, Kenneth Rohde Christiansen wrote:
> Some thoughs of mine, please read:
> 
> By attending the university you often hear non-gnome and non-kde
> developers discuss different platforms, technologies, kde and gnome.   
> While listening to this I have a bigger understanding why these people  
> don't join our project.
> 
> One of the reasons is that many people actually don't like C very much,
> and when these people want to code Gnome they go look for bindings.   
> Many Gnome developers think that Gnome is very cool with all it's
> binding,
> but this thought is not shared with the whole world outside out
> community.
> 
> Many people think that the Gnome development platform is difficult to
> understand. There are lots of libraries, and they are not organized in a
> nice class library. This is possible to do with bindings to OO
> languages, but is as far as I know, not done.
> 
> For instance, Java-GNOME has the following "namespaces"/"packages":
> 
> gnu.gdk, gnu.gtk, gnu.glade, gnu.gnome
> 
> This is very close to the C libs, so it would be easy to switch to Java
> from programming Gnome in C. But almost noone does this. People who want
> to use the Java bindings is often people who don't like C.
> 
> Now the naming is also very unlucky for Java-GNOME as gnu.gnome is
> actually gnome-libs, but for people from the outside Gnome consists of
> gtk, gdk, glade, gnome-libs, etc, so the class library seems weird to
> these people. Also the class library for a binding doesn't have to
> reflect that it is made by using gdk, gtk or whatever.
> 
> If we want people to use these bindings we have to make them easy and
> hide implimentation/bindings details.
> 
> An idea for Java-GNOME could be like this:
> 
> org.gnome.drawing                       - gdk
> org.gnome.ui                            - gtk
> org.gnome.ui.extra                      - libgnomeui + bonoboui
> org.gnome.ui.glade                      - glade
> org.gnome.accessibility                 - atk
> org.gnome.containers (or .utils)        - glib containers wrappers    
> org.gnome.canvas                        - libgnomecanvas
> org.gnome.vfs                           - gnome-vfs
> org.gnome.config                        - gconf or bonobo-conf
> org.gnome.bonobo                        - bonobo
> org.gnome.bonobo.activation             - bonobo-activation
> org.gnome.xml                           - libxml (if it makes sence to
> bind)
> org.gnome.print                         - libgnomeprint
> --
> org.gnome.misc.eel                      - eel
> org.gnome.misc.gal                      - gal
> org.gnome.misc.panel                    - panel applets
> ...etc.
> 
> 
> This doesn't confuse people with the difference with gtk, gdk and gnome,
> and it integrates well with the Java language. All not well integrated
> things have been put in org.gnome.misc and might be moved elsewhere
> later.
> 
> A similar hierachy can be used for C++ bindings.
> 
> Also, something people don't like about the Gnome bindings is that none
> are OFFICIAL. For people outside our community it seems that the
> bindings 
> are made by people with no connection to the Gnome Community, and they
> then fear the quality of the bindings, and goes elsewhere.
> 
> What can we do to make this better? Should we decide on a class library
> that should be followed by binders if they want their bindings to be
> official. Do we need some kind of quality control?
> 
> I really think that we should get some good Java bindings. Both Sun and
> IBM said that they support Gnome, and they both have a strong Java    
> commitment. Cooperation with Sun and IBM about this would really rock.
> Maybe something for the Gnome Foundation?.
> 
> Also the development pages really scare people away.
> 
> Take a look at these two pages:
> 
> http://developer.apple.com/techpubs/macosx/Cocoa/CocoaTopics.html
> http://developer.apple.com/macosx/architecture/
> 
> We really need something like this. And we need to group our
> technologies,
> maybe something like this could be an idea?
> 
> GNOME System Architecture
> -------------------------
> 
> GNOME User Experience (libgnome, glade, gtk, gdk)
> --
> Bonobo Component System
> GNOME Language Framework (Java-GNOME, python, etc)
> GNOME Multimedia Framework (gstreamer)
> --
> Linux/UNIX Kernel
> UNIX into the future. GNOME expands on many open souce
> and industry standards towards providing UNIX users and
> developers with a userfriendly and powerful desktop and
> development platform.
> 
> Anyway, it's just some ideas. Please comment
> 
> Cheers, Kenneth
> 
> 
> 
> _______________________________________________
> gnome-hackers mailing list
> gno...@gn...
> http://mail.gnome.org/mailman/listinfo/gnome-hackers
> 
> 
> 

[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

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

[Sander V. <San...@Su...>]

On 15 Sep 2001, Havoc Pennington wrote:

[snip]

> 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.
> 

The other thing here is (which also is totally separate from any kind of
set of "official" or "non-official" bindings) is that the most 'natural'
way of accessing a large part of gnome will be via CORBA, which means we
have to make sure we are interoperable.

> Havoc
> 

	Sander

I haven't been vampired. You've been Weatherwaxed.