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

[Murray Cumming <Murray_Cumming betaresearch de>]

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

GDK and GTK+ are not necessarily part of gnome. Many people use them
separately. It is also nice to have them separate because it is much
easier to say that your bindings for GTK+ are complete than to say that
your bindings for GNOME are complete. I guess that libxml is also widely
used outside of GNOME. I don't think it really complicates things to
have these outside of the GNOME namespace.

> org.gnome.ui.extra                      - libgnomeui + bonoboui
> org.gnome.ui.glade                      - glade
> org.gnome.accessibility                 - atk
> org.gnome.containers (or .utils)        - glib containers wrappers

When would you ever need to bind glib containers? You should use the
language containers, such as perl lists or C++ std::list<>, or
java.util.LinkedList. However, there may be a need for some languages
(such as C++, but not Java) to create a string implementation that wraps
glib_uf8*_ if utf8 is not supported by the language.


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

Probably not. We shouldn't force the use of any particular parser,
particularly when the language may have it's own parsers. I find it very
annoying that QT (a GUI toolkit) contains an XML parser and a database
API.

> org.gnome.print                         - libgnomeprint
> --
> org.gnome.misc.eel                      - eel
> org.gnome.misc.gal                      - gal

By the time eel and gal are mature enough to be wrapped, they will
probably be in one of the other parts of GNOME.

> 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

-- 
Murray Cumming
www.murrayc.com
murrayc usa net

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers