java-gnome-developer

RE: [Java-gnome-developer] Which libraries are used?

[Jeffrey M. <Jef...@Br...>]

> 
> In about 14days a freind of my and i'll port java-gnome 0.7 
> to windows.

This is great news.  I have started to look into this myself.
Once you get started let's stay in close contact.  I will be
very interested in your progress.

There are a few things you should consider.  If you have checked
cvs lately you will notice that there are a tremendous number
of adds and updates taking place.  This is because I am in the
process of completely restructuring the java-gnome bindings.  This
restructuring is going to address three areas in the project that
have needed significant work.  They are (in order of importance):

1) Simplifying the public interface of the library.  In the past
the java-gnome public interface provided a one-for-one mapping to
the methods of the native libraries.  This was a bad design decision
for two reasons.  First, it made the libraries very large and 
difficult for a new developer to grasp.  Second, the public interface
did not feel very java-like.  It did not leverage the existing classes
from the JDK and did not follow the patterns that are common to
java class libraries.  In the simplified version currently under
development the classes will still have access to all of the 
methods of the native libraries via protected methods in the classes.
A public interface will be built on top of that to provide a robust
class library.

2) Simplify the bindings themselves to make it easier for developers
to contribute the project.  Time and time again developers have joined
the project only to find out how complex the project is and eventually
leave the project altogether.  If this project is to be a success I
am going to need help.  Most people that want to contribute come from
a Java background and know little about C or even JNI.  As a result I
am restructuring the bindings by moving more of the code from the
C/JNI layer up into the Java layer.  In fact, the C/JNI layer and the
Java methods that will provide access to them will be fixed and in
place.  All that will be necessary for most developers is to help
design the public interface and write Java code that calls the native
methods to implement that interface.  Unless the native access layer
changes (which I hope will not happen often) there will be no need
for the majority of developers to even compile the native libs more
than once.  I have also added the files necessary to work in the
eclipse IDE to cvs.  Eclipse will work on Linux and Windows.  If 
there is a Windows port of the bindings developers should be able 
to contribute from either platform.

3) Simplify the build process.  When I first got started with java-gnome
about two years ago I knew nothing about the GNU build tools.  As the
project grew I continued to hack my way through the build process and
managed to create a "beast of burden".  In this new version the generator
will not be part of the build process.  The new build will provide
four targets.  They will be jar, native, test, and all (the default).
By default it will build all of the wrappers (libglade, libgladegnome,
gtk, libgnome, and libgnomeui) but there will be configure options that 
will allow you to exclude parts of the bindings.  The test target needs
a little more explanation.  I intend to build up a testing framework
that will be based on JUnit to provide tests for all methods in the
public interface.  This will help us ensure that we are producing a
quality product.

So the next question is "Where am I in this process?".  I have completed
and checked into cvs the java and native code for glib, pango, atk, 
and gdk.  I have not provided the public interface for these libs yet.
I hope to check in the java and native code for gtk today and the same
for gnome and glade tomorrow.  Over the weekend I will complete the new 
build files.  At that point I need to start writing the public interface
and tests for the bindings.  This will go much faster if I have help.  
I have started an object model that is in cvs.  I would like to find 
somebody that would be willing to maintain this model.

I think it would be very simple to compile the new version of the
bindings on Windows.  I have already downloaded the Windows version
of GTK2 and the associated libraries with the intention of trying
to get this to work.  If you could do this that would be great.  Once
you complete the compilation of the native layer you could help with
the definition and coding of the public interface.

> We need to know the following things:
> 
> 1.) Will it build with gtk1.3, which should be very identical to 1.2.7

I know it worked with 1.2.7. You should have no problems with this.

> 2.) Wich Libraries are used by the bindings?

I use the config programs (gtk-config for GTK1 or pkg-config for GTK2) 
to determine the necessary libraries for the native layer.  Other than 
that I just use the JNI library that is provided by the JDK.

> 3.) Is the code portable? -Or do we need cygwin and gcc to compile it?

The code should be completely portable if the necessary glib/gtk/gnome 
libs are present.  The JNI code is not platform specific.


-Jeff

Re: [Java-gnome-developer] Which libraries are used?

[Clemens E. <Lin...@we...>]

Thank you for your interresting response!

> I agree that swing is quite difficult.  At the same time I think
> I can make java-gnome even simpler that it currently is.  I want
> to make the event handling very clear (not guess work like what
> currently exists).  I want to remove methods from the public
> interface that were only intended for internal development in the
> native libraries.  I want to make higher-level abstractions that
> simplify the creation of menus, etc.  I want to have more control
> over the API than I have with the generator.  If there are multiple
> methods that perform the same task I want to remove one of them.  If
> there are methods that are confusing I want to provide a simpler
> wrapper over them.
>
That would be a quite difficult and time-intesive thing, but I think it 
would be great for all the java-gtk developers!
There are very much funktions in 0.7.1 which arent really needed

. 

 >When developers want to write apps for GTK/GNOME
 >they should be able to use Java.  That is my goal. If there is the

> added benefit of using those apps on the Windows platform this is
>
> a great bonus. 
>
You're probably right. GNU-developers develop there aps most time with 
low-level languages like C....

 >Again, the swing interfaces would be a very large undertaking.
O.K, I unserstand....It was only an altanativ proposal


Yeah, I said taht I'm willed to help you. I think its better for my to 
write dokus or to design a better Homepage.

I've currently two projects that I must finish: The vocab-trainer and a 
politic-game written in C++.

Thanks for developing such great Software!!!

Re: [Java-gnome-developer] Which libraries are used?

[Clemens E. <Lin...@we...>]

Hello Jeff!

> 1) Simplifying the public interface of the library.  In the past
> the java-gnome public interface provided a one-for-one mapping to
> the methods of the native libraries.  This was a bad design decision
> for two reasons.  First, it made the libraries very large and
> difficult for a new developer to grasp.  Second, the public interface
> did not feel very java-like.  It did not leverage the existing classes
> from the JDK and did not follow the patterns that are common to
> java class libraries.  In the simplified version currently under
> development the classes will still have access to all of the
> methods of the native libraries via protected methods in the classes.
> A public interface will be built on top of that to provide a robust
> class library.
>
Hmm. I think the public interface of java-gtk0.7.1 is very clear and 
very simple. I started to learn swing these days, because I decided tow 
rite my vocab-programm in SWING (I'm really sorry, but thats the best 
solution I think), and I really wondered how complex swing is. I worked 
4 hours on an JTable and there arent any methods for asking the value...
So, I liked it very much that all java-gtk widgets are static and I dont 
think that they need to be more java-like.

> 2) Simplify the bindings themselves to make it easier for developers
> to contribute the project.  Time and time again developers have joined
> the project only to find out how complex the project is and eventually
> leave the project altogether.  If this project is to be a success I
> am going to need help.  Most people that want to contribute come from
> a Java background and know little about C or even JNI.  As a result I
> am restructuring the bindings by moving more of the code from the
> C/JNI layer up into the Java layer.  In fact, the C/JNI layer and the
> Java methods that will provide access to them will be fixed and in
> place.  All that will be necessary for most developers is to help
> design the public interface and write Java code that calls the native
> methods to implement that interface.  Unless the native access layer
> changes (which I hope will not happen often) there will be no need
> for the majority of developers to even compile the native libs more
> than once.  I have also added the files necessary to work in the
> eclipse IDE to cvs.  Eclipse will work on Linux and Windows.  If
> there is a Windows port of the bindings developers should be able
> to contribute from either platform.
>
Hmm, this semms to be a pretty solution. To make more things in Java 
will make the bindings smaller.

> 3) Simplify the build process.  When I first got started with java-gnome
> about two years ago I knew nothing about the GNU build tools.  As the
> project grew I continued to hack my way through the build process and
> managed to create a "beast of burden".  In this new version the generator
> will not be part of the build process.  The new build will provide
> four targets.  They will be jar, native, test, and all (the default).
> By default it will build all of the wrappers (libglade, libgladegnome,
> gtk, libgnome, and libgnomeui) but there will be configure options that
> will allow you to exclude parts of the bindings.  The test target needs
> a little more explanation.  I intend to build up a testing framework
> that will be based on JUnit to provide tests for all methods in the
> public interface.  This will help us ensure that we are producing a
> quality product.
>
Good idea! I had to build my libjavagtk.so myself because the 
build-scripts where broken.

> So the next question is "Where am I in this process?".  I have completed
> and checked into cvs the java and native code for glib, pango, atk,
> and gdk.  I have not provided the public interface for these libs yet.
> I hope to check in the java and native code for gtk today and the same
> for gnome and glade tomorrow.  Over the weekend I will complete the new
> build files.  At that point I need to start writing the public interface
> and tests for the bindings.  This will go much faster if I have help. 
> I have started an object model that is in cvs.  I would like to find
> somebody that would be willing to maintain this model.
>
> I think it would be very simple to compile the new version of the
> bindings on Windows.  I have already downloaded the Windows version
> of GTK2 and the associated libraries with the intention of trying
> to get this to work.  If you could do this that would be great.  Once
> you complete the compilation of the native layer you could help with
> the definition and coding of the public interface.
>
Of course I'm willed to help you!
But there are several problems:
1. I dont understand much C, nothing JNI, and my java isnt the best.
2. Time: I've to produce moch other apps for my school, and everybody I 
asked said to me, that I should do it with swing ;-((
3. Not sure about the future of java-gtk:
I came to the java-gtk project because I liked to produce compiled apps 
with gcj. But now gcj supports awt and I'm sure that a 
swing-implemetaion will follow in the next 1-2 years. The swing-part 
will be also built on the top of gtk.
So if I use swing I'll be compatible to all VMs and maybe soon the gcj, 
which would be also native.

What do you think about a swing-implementationon the top of gtk and how 
complex would that be?
What do you think of two possible java-gtk interfaces? the original and 
the swing....?
I also belive that that solution will strongly increase the number of 
java-gtk programms, because now many coders dont want to learn a new api.
I hope you are not angry because I said my thoughts, you're still the 
best developer I've ever seen.