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



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

I believe there are three factors that are critical for the
success of this effort/review.  They are:

1) The language bindings projects need to be strongly
represented.  As Kenneth stated, many developers don't want
to use C.  For GNOME to be a successful development platform
we need to offer the developers the choice of several languages.

2) The development community (not just GNOME hackers, but
application developers as well) need to be able to voice their
ideas.  More than anyone else, they can tell us what would make
their development efforts simpler.  Perhaps one of the GNOME
websites could be setup to accept input.

3) Very clear goals and objectives should be defined prior to
the start of the effort.  Also, all parties should agree to the
goals and objectives and should be committed to implementing
the final recommendations of the review.

-Jeff


>
> Why don't we hand it down to the sub-comittee on technical affairs who
> can convene a pow-wow to hammer this issue out and finalize an initial
> proposal on deliverables to be ratified by the working group on
> technical affairs within a three week timeframe?
>
> ;-)
>
> -Seth
> On 16 Sep 2001 11:27:29 -0400, Jeffrey Morgan wrote:
> > I am in total support for standardizing on a common
> > namespace packaging across language bindings or whatever
> > it takes to lower the entry barrier for new developers. 
> > Kenneth, you definitely seem to have a passion for this
> > and have given it some thought.  I propose you organize
> > and facilitate a working group comprised of one
> > representative from each language binding project that
> > wants to participate.  The goal of this working group is
> > to deliver recommendations on how we can simplify the
> > learning curve new developers face when coming to GNOME.
> > I would hope the initial proposal could be delivered
> > within a few weeks. 
> >
> > -Jeffrey Morgan
> >
> > >
> > > 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
> > >



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]