What to do in order to make the gnome development platform rock.

[Kenneth Rohde Christiansen <kenneth gnu org>]

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
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers