java-gnome-developer — For people using the bindings to write their own applications

[Java-gnome-developer] ItemFactory and GtkType and Interning

[Dan B. <da...@mi...>]

I was perusing the Java-Gnome tutorial again today, and found the part
about making menus. I went through the example, and then noticed the bit at
the top about GTK actually providing a bunch of convenient stuff for making
menus, saving one the hardship of "manual" creation. So, I went off and
looked at the GTK tutorial on that topic at:

    <http://www.gtk.org/tutorial/gtk_tut-13.html#ss13.3>

Well, I liked what I saw and wondered if I could do something quick to be
able to use that functionality.

Unfortunately I wasn't able to do that. However, I noticed one thing needed
that's a prerequisite for being able to use the GtkItemFactory class,
namely having the GtkType objects associated with classes in a convenient
form for use in Java. (GtkItemFactory requires a GtkType parameter in its
constructor. GtkType is an integral type, and sort of like an enumerated
type except that the enumeration is built on the fly as GTK classes get
initialized.)

As I dug into the problem, I realized it was actually a more general
issue. Here's what I ended up doing:

* I defined GtkType as an enumerated type with an empty body. I suspect that
  the pre-existing GtkFundamentalType definitions may want to be moved
  here, but I'm not sure about that.

* It seems that all Gnome/GTK classes have a "static method" called
  "<classname>_get_type" but that the gtk.defs file didn't list any of
  them. So, I added them. (I skipped a couple of the ones in gnome.defs
  because of weird capitalization and insufficient cues as to the right
  name--I was feeling too burnt to grovel over all the header files at that
  point.)

* Tricky part #1: The approximately-standard Java way to have a type object
  associated with a class is by having a static variable named TYPE (e.g.,
  java.lang.Integer.TYPE et al). I figured this was the way to go, so I
  added code to MethodDefinition to produce these. What it does is look to
  see if it's about to spit out the method "static GtkType getType ()" and,
  if so, also spits out the declaration "static final GtkType TYPE =
  getType ()". This is the moral equivalent of the CLASS_NAME_GET_TYPE
  macros in the gtk headers.

* Tricky part #2: There was a mismatch in the code generation between C and
  Java when the return type of a method is an enumerated type. In
  particular, the C side returns a raw int value (the value of the enum),
  but the Java side expects an object. This caused a segfault for any such
  method (such as, in particular, all those getType()s I just added, but
  I also noticed a bunch of other places where this problem happened). Since
  getting the right object from the C side is a bit of a monumental task
  involving lots of inefficient JNI calls, I decided to make the Java side
  bend backwards a bit:

    * The native methods that return an enumerated type are now declared from
      Java to return an int. Problem solved as far as crashing the VM is
      concerned. However, that meant that Java code had to just take int
      return values, and that's not very nice in terms of type safety, so...

    * Every method that has this form is now split in two: There is a Java
      method, with the original name (e.g., getCellType) that is declared
      to return an object of the appropriate type (e.g., GtkCellType).
      Then, there is a native method with the original name plus a final
      digit "0" (e.g., getCellType0, patterned after how Sun writes their
      code, to wit, "javap -p java.lang.ClassLoader"). The Java method
      simply wraps the native return value.

    * Since (1) I don't want to spew new wrapped values like there's no
      tomorrow, and (2) since this wrapping has to happen all over the place,
      I added a new standard method to all enumerated types, "intern()",
      patterned after String.intern(). static <EnumType>.intern takes an
      int and returns the canonical instance of that class for the given
      value. 

The native wrapper methods end up looking like this:

    public EnumType methodName (Type arg, ...)
    {
        return EnumType.intern (methodName0 (arg, ...));
    }

Classes for enumerated types end up looking like this (actual output!):

    final public class GtkCellType
    {
      int value_;
    
      public GtkCellType(int value) {
        value_ = value;
      }
    
      public int getValue() {
        return value_;
      }
    
      public int hashCode() {
        return value_;
      }
    
      public boolean equals(Object other) {
        return (other instanceof GtkCellType)
          && (((GtkCellType) other).value_ == value_);
      }
    
      static private HashMap theInternedExtras = null;
      static private GtkCellType theSacrificialOne = new GtkCellType(0);
      static public synchronized GtkCellType intern(int value) {
        if (value < theInterned.length)
          return theInterned[value];
        theSacrificialOne.value_ = value;
        if (theInternedExtras == null)
          theInternedExtras = new HashMap();
        GtkCellType already = (GtkCellType) theInternedExtras.get(theSacrificialOne);
        if (already == null) {
          already = new GtkCellType(value);
          theInternedExtras.put(already, already);
        }
        return already;
      }
      static private GtkCellType[] theInterned = {
        new GtkCellType(0),
        new GtkCellType(1),
        new GtkCellType(2),
        new GtkCellType(3),
        new GtkCellType(4)
      };
      public final static int _GTK_CELL_EMPTY = 0;
      public final static GtkCellType GTK_CELL_EMPTY = theInterned[0];
      public final static int _GTK_CELL_TEXT = 1;
      public final static GtkCellType GTK_CELL_TEXT = theInterned[1];
      public final static int _GTK_CELL_PIXMAP = 2;
      public final static GtkCellType GTK_CELL_PIXMAP = theInterned[2];
      public final static int _GTK_CELL_PIXTEXT = 3;
      public final static GtkCellType GTK_CELL_PIXTEXT = theInterned[3];
      public final static int _GTK_CELL_WIDGET = 4;
      public final static GtkCellType GTK_CELL_WIDGET = theInterned[4];
    }

The dynamic stuff (adding to a HashMap) is to account for classes like
GtkType, whose elements aren't all statically known, and for flag types
(the generated code looks a little different as it's sparsely populated).
If it weren't for that, it could just be simple array lookup. I added
equals() and hashCode() so that the HashMap would work. I added getValue()
because it seems like the sort of thing one ought to have in this situation
(that is, for translation in the other direction). Oh, and in case anyone
is worrying about the efficiency of "synchronized", pretty much all of the
production-quality vms do tricks that make it relatively cheap when there's
no contention for a lock.

With all that done, enumerated return values now work as expected. Those
interested in clean OO programming can use the wrapped interfaces, but
those who need that extra ounce of speed can skip the interning and just
use the native methods directly. This seems like a reasonable tradeoff to
me.

I believe I got this all working (things seem to work as well now as
before), but since (1) I don't know whether you guys think this all is good
or not, (2) since one of you might have already had this in the works in
some other way, and (3) since I don't have write access to the CVS
repository anyway, I'm just providing this stuff as a patch. Assuming
sourceforge is willing, I'll post the patch there, but you can also find it
here:

    http://condensed.milk.com/~danfuzz/java-gnome/interning-diffs.txt

I've tried to be consistent with the spacing/indentation style I found,
although I probably messed up since the Java style we use at work has the
parameters "open curly on its own line" and "space after method name"
turned on.

RE: [Java-gnome-developer] Question 10 In The FAQ (Long story short: got it up and limping)

[Jeff M. <ku...@ne...>]

Dan,

This is great information to know.  The defs have many problems.  I have
been going through the gtk defs file and adding methods and correcting
mistakes.  I will apply your changes and check into CVS tonight.

As far as the error that you are having with TestGNOME, this is caused (as
you might guess) by the grabDefault method which calls the native method
gtk_widget_grab_default.  It is failing on a check to see if the widget
can default.  I notices this as I was working on TestGTK and just
commented it out for the time being hoping to fix it prior to release
0.5.  I will comment this out of the TestGNOME and also check it in tonight.

As you can see, there is still much work to be done on this project.  We
would welcome all the help you can give.

-Jeff

-----Original Message-----
From: jav...@li...
[mailto:jav...@li...]On Behalf Of
Dan Bornstein
Sent: Friday, November 03, 2000 6:49 PM
To: To: Java-Gnome-Developer@Lists. Sourceforge. Net
Subject: [Java-gnome-developer] Question 10 In The FAQ (Long story
short: got it up and limping)


Strangely enough, upon my first attempt to use Java-Gnome, I ran into the
symptom described by question 10 in the FAQ:

    % java TestGNOME
    Exception in thread "main" java.lang.UnsatisfiedLinkError:
/usr/local/lib/libGNOMEJava.so.0.4.5: /usr/local/lib/libGNOMEJava.so.0.4.5:
undefined symbol: gnome_entry_max_saved
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1306)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at gnome.Gnome.<clinit>(Gnome.java:23)
        at TestGNOME.main(TestGNOME.java:410)

The FAQ has this to say:

>The most common error of this type is caused by the fact that your system
>can not find the libraries it needs to load. Try to run make install as
>root and ensure that the directory the two libraries (libGtkJava.so and
>libGNOMEJava.so) end up in is in the dynamic loader's path.

>If you did this and it still gives you the same error message please
>contact us with the version of the JDK, GTK and GNOME that you use and
>detail on the error that you get.

Well, I think I tried every reasonable test. I tried just leaving the libs
in the build location (I have an aversion to installing stuff as root), in
/usr/local/lib, and finally even in /usr/lib, and I still got the error.

So, all the above having failed, I did a little investigation, and, in
fact, near as I can tell, that symbol isn't defined in any of the libs in
/usr/lib on my machine:

    % nm /usr/lib/lib*.so* |& grep 'gnome_entry.*max_saved'
             U gnome_entry_set_max_saved
             U gnome_entry_set_max_saved
    000591f0 T gnome_entry_set_max_saved
    000591f0 T gnome_entry_set_max_saved
    000591f0 T gnome_entry_set_max_saved

There are entries for the notably similar "gnome_entry_set_max_saved",
though. Looking in the Gnome header files, I found this in
libgnomeui/gnome-entry.h:

    void gnome_entry_set_max_saved (GnomeEntry *gentry, guint max_saved);

This looks similar to the definition for gnome_entry_max_saved in
defs/gnome.defs:

    (define-func gnome_entry_max_saved
      none
      ((GnomeEntry gentry)
       (int max_saved)))

I tried replacing "gnome_entry_max_saved" with "gnome_entry_set_max_saved"
in gnome.defs and recompiled, and this *particular* problem went away, but
I got a similar error with a different symbol. I reiterated the process
until I got it working. Here are the changes I ended up making:

    gnome_entry_max_saved               => gnome_entry_set_max_saved
    gnome_icon_entryi_set_pixmap_subdir =>
gnome_icon_entry_set_pixmap_subdir
    gnome_icon_entryi_set_icon          => gnome_icon_entry_set_icon
    gnome_app_dock_item                 => gnome_app_add_dock_item
    gnome_dialog_append_buttonv         => gnome_dialog_append_buttonsv
    gtk_container_need_resize           => (removed)
    gtk_enry_set_max_length             => gtk_entry_set_max_length
    gtk_progress_get_current_percentage_from_value
                                    =>
gtk_progress_get_percentage_from_value
    gtk_widget_restore_state            => gtk_widget_restore_default_style
    gtk_widget_basic                    => (removed)

After making all of these changes, I actually got TestGNOME to run[*]
(yay!),
although, among the output I got this message:

    Gtk-CRITICAL **: file gtkwidget.c: line 3174 (gtk_widget_grab_default):
    assertion `GTK_WIDGET_CAN_DEFAULT (widget)' failed.

Of course, I might not have ended up exercising the method definitions I
changed in a meaningful way, so I don't know if I guessed wrong at the
mappings. My guess is that, if these aren't typos in gnome.defs, then the
Gnome libraries changed from when the defs files were originally made.

Here's the salient version info. Let me know if you'd like to know
something not listed here:

    % rpm --query gnome-libs
    gnome-libs-1.2.4-0_helix_2
    % rpm --query --list gnome-libs |& grep '/usr/lib'
    /usr/lib/libart_lgpl.so.2
    /usr/lib/libart_lgpl.so.2.2.0
    /usr/lib/libgnome.so.32
    /usr/lib/libgnome.so.32.3.11
    /usr/lib/libgnomesupport.so.0
    /usr/lib/libgnomesupport.so.0.0.0
    /usr/lib/libgnomeui.so.32
    /usr/lib/libgnomeui.so.32.11.3
    /usr/lib/libgnorba.so.27
    /usr/lib/libgnorba.so.27.1.8
    /usr/lib/libgnorbagtk.so.0
    /usr/lib/libgnorbagtk.so.0.0.0
    /usr/lib/libgtkxmhtml.so.1
    /usr/lib/libgtkxmhtml.so.1.0.1
    /usr/lib/libzvt.so.2
    /usr/lib/libzvt.so.2.2.7

Hope this helps,

-dan

[*] I'm running Sun's JDK 1.3 for Linux, on RedHat 6.2, with a
relatively up-to-date Helix GNOME installation on top of it. I ran with
a remote (ssh-tunnelled) X display.
_______________________________________________
java-gnome-developer mailing list
jav...@li...
http://lists.sourceforge.net/mailman/listinfo/java-gnome-developer

[Java-gnome-developer] Question 10 In The FAQ (Long story short: got it up and limping)

[Dan B. <da...@mi...>]

Strangely enough, upon my first attempt to use Java-Gnome, I ran into the
symptom described by question 10 in the FAQ:

    % java TestGNOME
    Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/local/lib/libGNOMEJava.so.0.4.5: /usr/local/lib/libGNOMEJava.so.0.4.5: undefined symbol: gnome_entry_max_saved
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1306)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at gnome.Gnome.<clinit>(Gnome.java:23)
        at TestGNOME.main(TestGNOME.java:410)

The FAQ has this to say:

>The most common error of this type is caused by the fact that your system
>can not find the libraries it needs to load. Try to run make install as
>root and ensure that the directory the two libraries (libGtkJava.so and
>libGNOMEJava.so) end up in is in the dynamic loader's path.

>If you did this and it still gives you the same error message please
>contact us with the version of the JDK, GTK and GNOME that you use and
>detail on the error that you get.

Well, I think I tried every reasonable test. I tried just leaving the libs
in the build location (I have an aversion to installing stuff as root), in
/usr/local/lib, and finally even in /usr/lib, and I still got the error.

So, all the above having failed, I did a little investigation, and, in
fact, near as I can tell, that symbol isn't defined in any of the libs in
/usr/lib on my machine:

    % nm /usr/lib/lib*.so* |& grep 'gnome_entry.*max_saved'
             U gnome_entry_set_max_saved
             U gnome_entry_set_max_saved
    000591f0 T gnome_entry_set_max_saved
    000591f0 T gnome_entry_set_max_saved
    000591f0 T gnome_entry_set_max_saved

There are entries for the notably similar "gnome_entry_set_max_saved",
though. Looking in the Gnome header files, I found this in
libgnomeui/gnome-entry.h:

    void gnome_entry_set_max_saved (GnomeEntry *gentry, guint max_saved);

This looks similar to the definition for gnome_entry_max_saved in
defs/gnome.defs:

    (define-func gnome_entry_max_saved
      none
      ((GnomeEntry gentry)
       (int max_saved)))

I tried replacing "gnome_entry_max_saved" with "gnome_entry_set_max_saved"
in gnome.defs and recompiled, and this *particular* problem went away, but
I got a similar error with a different symbol. I reiterated the process
until I got it working. Here are the changes I ended up making:

    gnome_entry_max_saved               => gnome_entry_set_max_saved
    gnome_icon_entryi_set_pixmap_subdir => gnome_icon_entry_set_pixmap_subdir
    gnome_icon_entryi_set_icon          => gnome_icon_entry_set_icon
    gnome_app_dock_item                 => gnome_app_add_dock_item
    gnome_dialog_append_buttonv         => gnome_dialog_append_buttonsv
    gtk_container_need_resize           => (removed)
    gtk_enry_set_max_length             => gtk_entry_set_max_length
    gtk_progress_get_current_percentage_from_value
                                    => gtk_progress_get_percentage_from_value
    gtk_widget_restore_state            => gtk_widget_restore_default_style
    gtk_widget_basic                    => (removed)

After making all of these changes, I actually got TestGNOME to run[*] (yay!),
although, among the output I got this message:

    Gtk-CRITICAL **: file gtkwidget.c: line 3174 (gtk_widget_grab_default): 
    assertion `GTK_WIDGET_CAN_DEFAULT (widget)' failed.

Of course, I might not have ended up exercising the method definitions I
changed in a meaningful way, so I don't know if I guessed wrong at the
mappings. My guess is that, if these aren't typos in gnome.defs, then the
Gnome libraries changed from when the defs files were originally made.

Here's the salient version info. Let me know if you'd like to know
something not listed here:

    % rpm --query gnome-libs
    gnome-libs-1.2.4-0_helix_2
    % rpm --query --list gnome-libs |& grep '/usr/lib'
    /usr/lib/libart_lgpl.so.2
    /usr/lib/libart_lgpl.so.2.2.0
    /usr/lib/libgnome.so.32
    /usr/lib/libgnome.so.32.3.11
    /usr/lib/libgnomesupport.so.0
    /usr/lib/libgnomesupport.so.0.0.0
    /usr/lib/libgnomeui.so.32
    /usr/lib/libgnomeui.so.32.11.3
    /usr/lib/libgnorba.so.27
    /usr/lib/libgnorba.so.27.1.8
    /usr/lib/libgnorbagtk.so.0
    /usr/lib/libgnorbagtk.so.0.0.0
    /usr/lib/libgtkxmhtml.so.1
    /usr/lib/libgtkxmhtml.so.1.0.1
    /usr/lib/libzvt.so.2
    /usr/lib/libzvt.so.2.2.7

Hope this helps,

-dan

[*] I'm running Sun's JDK 1.3 for Linux, on RedHat 6.2, with a
relatively up-to-date Helix GNOME installation on top of it. I ran with
a remote (ssh-tunnelled) X display.

Re: [Java-gnome-developer] db2html

[Matthew H. R. <mr...@co...>]

Dan Bornstein wrote:
> 
> Paul Gear <pau...@bi...> writes:
> >I found docbook and sgmltools on my local Red Hat mirror, but there is
> >no db2html, only sgml2html.  Should i use that instead, or is there
> >another package i am missing?
> 
> I found db2html in the docbook package located here:
> 
>     <ftp://sourceware.cygnus.com/pub/docbook-tools/docware/RPMS/noarch/>
> 
> -dan

Debian users will probably need to "apt-get install sgmltools-2" and use
"sgmltools -b html" to convert the docbook to HTML.

-- 
Matthew H. Ray
Programmer, Coral Technologies, Inc.
mr...@co...

[Java-gnome-developer] I feel useful

[Dan B. <da...@mi...>]

I've been browsing the documentation and came across the part about how
variable arguments are handled (Appendix B in the parser doc). The method
currently used seems to be to make a bunch of methods with 0..N extra
arguments at the end.

For extremely time-critical code, this is definitely the way to go.
However, most of the time, I'd recommend just taking an array of the
appropriate type. Actually, there's a proposed change to the Java language
(well, it's a JSR in-progess, at least, and seems likely to be approved)
which would make it syntactically easy to write an array of type Object,
so, I'd even be willing to forego the compile-time typecheck to get the
better syntax. (After all, it's easy enough to generate the cast.) See this
URL for details on the proposal:

    <http://java.sun.com/aboutJava/communityprocess/jsr/jsr_065_cncsarray.html>

The brief synopsis is that the following two forms would become equivalent:

    foo.bar (a, b, new Object[] { c, d, e })
    foo.bar (a, b, { c, d, e })

If you still have some efficiency concerns, my usual recommendation is
to provide a limited number of separate-arg versions (e.g., for 0 to 2
args) and then provide the array version as a catch-all, e.g.:

    public void meth (String s);
    public void meth (String s, Foo foo1);
    public void meth (String s, Foo foo1, Foo foo2);
    public void meth (String s, Foo[] foos); // or Object[] foos

Hope you find this useful,

-dan

[Java-gnome-developer] db2html

[Dan B. <da...@mi...>]

Paul Gear <pau...@bi...> writes:
>I found docbook and sgmltools on my local Red Hat mirror, but there is
>no db2html, only sgml2html.  Should i use that instead, or is there
>another package i am missing?

I found db2html in the docbook package located here:

    <ftp://sourceware.cygnus.com/pub/docbook-tools/docware/RPMS/noarch/>

-dan

[Java-gnome-developer] java-gnome tutorial

[Jeff M. <ku...@ne...>]

All,

Attached is a tarball containing the java-gnome tutorial in both
html and postscript format.  This document is a work in progress
and will be updated about every other day in CVS so please check
back to get updates.  Also, I would appreciate feedback on the
document. 

Thanks
-Jeff

Re: [Java-gnome-developer] Re: Hello

[Jean v. W. <je...@sm...>]

Hi Paul

On Fri, 3 Nov 2000, Paul Gear wrote:

> The problem seems to be that i had symlinked genunix to linux, since
> v0.4.1 was looking for genunix in $JAVA_HOME/include.  It seems to work
> now.  Dunno what should be done about this - probably nothing, or at
> most documenting it somewhere.

If you run into the problem again please let us know.  We can add it to
the FAQ if necessary but I do not think it should be a problem after the
release of 0.5.0.

> I found docbook and sgmltools on my local Red Hat mirror, but there is
> no db2html, only sgml2html.  Should i use that instead, or is there
> another package i am missing?

The rpm packages that you need (for Redhat 6.2) are something like:

sgml-common-0.1-7
sgml-tools-1.0.9-5
docbook-3.1-3

although newer versions (and some older versions) should work.

Regards
Jean

> Paul
> ---------
> "He must become greater; i must become less." - John 3:30
> http://www.bigfoot.com/~paulgear

Re: [Java-gnome-developer] Re: Hello

[Paul G. <pau...@bi...>]

Jeff Morgan wrote:
> 
> Paul,
> 
> I will look at the autoconf and let you know as soon as possible.

The problem seems to be that i had symlinked genunix to linux, since
v0.4.1 was looking for genunix in $JAVA_HOME/include.  It seems to work
now.  Dunno what should be done about this - probably nothing, or at
most documenting it somewhere.

> As for
> the tutorial, check to see if you have the command "db2html".  This command
> will convert the sgml document into html.  If you don't have it, I will
> email an html copy to you.

I found docbook and sgmltools on my local Red Hat mirror, but there is
no db2html, only sgml2html.  Should i use that instead, or is there
another package i am missing?

Paul
---------
"He must become greater; i must become less." - John 3:30
http://www.bigfoot.com/~paulgear

Re: [Java-gnome-developer] Re: Hello

[Paul G. <pau...@bi...>]

Jean van Wyk wrote:
> ...
> > I can't promise contribution, but i'd like to use the library to write a
> > GNOME application - where is the best place to start?
> 
> The best place to start differs.  If you have GTK+/GNOME experience you
> can just dive in and look at the test examples.  Have a browse through the
> tutorial as well.  For those with no GTK+/GNOME experience start with the
> tutorial, and then look at the examples in test.
> 
> TIP:  If you run "make doc" in the src directory you will get the javadoc
> docmuentation of all the packages and classes plus all the methods that
> was implemented so this is an excelent reference.
> ...
> Paul - please start writing your application.  You will most probably run
> into some trouble.  We will be willing to help and we plan to expand the
> Java-GNOME bindings as fast as we can.

Hi Jean & Jeff,

Thanks for the kind welcome.  Here is my first feedback.  When i
configure from the CVS version, i get this:

creating ./config.status
creating test/Makefile
sed: file conftest.s1 line 36: Unterminated `s' command
creating src/Makefile
sed: file conftest.s1 line 36: Unterminated `s' command
creating src/tools/Makefile
sed: file conftest.s1 line 36: Unterminated `s' command
creating Makefile
sed: file conftest.s1 line 36: Unterminated `s' command
creating java-gnome.spec
sed: file conftest.s1 line 36: Unterminated `s' command

What is likely to be the issue?  (BTW, the Makefiles produced are empty
- understandably enough since the sed failed.)  (P.S.  Debugging
autoconf is awful!  :-)


I found the tutorial file, but how can i use it?  I know nothing about
DocBook - i probably don't even have it installed.


Paul
---------
"He must become greater; i must become less." - John 3:30
http://www.bigfoot.com/~paulgear

RE: [Java-gnome-developer] Hello

[Jeff M. <ku...@ne...>]

Paul,

Lurkers are always welcome here:)  

There is actually a suprising amount of the GNOME bindings complete.
There is still a long ways to go until we are finished but there
is enough to get started with you application.

The best place to start is look at the test applications (TestGNOME
and TestGTK) and read the tutorial.  The tutorial is still a work
in progress but you can find some basic information there.

Another resource is this mailing list.  I and Jean van Wyk are 
on this list and will try to answer any questions you have.

Please don't hesitate to let us know how we can help and as you
start using the library we whould appreciate feedback.

-Jeff

-----Original Message-----
From: jav...@li...
[mailto:jav...@li...]On Behalf Of
Paul Gear
Sent: Friday, November 03, 2000 6:14 AM
To: jav...@li...
Subject: Re: [Java-gnome-developer] Hello


Jeff Morgan wrote:
> 
> Dan,
> 
> About a month ago I joined the project and took over as project leader.
> It had been dormant for about a year.  Since that time much work has
> been completed.  We are shooting for a 0.5 release within the next two
> weeks as well as a formal announcement of the projects resurrection.
> This release has numerous enhancements and bug fixes, documentation
> (including a tutorial) and the ability to create a GTK only binding.
>
> Most of the code is currently in CVS at sourceforge.  I hope to check
> more in this evening.  Your best bet is to checkout from CVS.

Question from another lurker: how complete are the GNOME bindings in
CVS?  They seem to be almost non-existant in 0.4.1 - where can i find
information on how to use them?

> I now have four developers actively working on this project.  I believe
> we are making good progress but additional help is always welcome.  If
> you wish to contribute we would welcome your involvement.

I can't promise contribution, but i'd like to use the library to write a
GNOME application - where is the best place to start?

Paul
---------
"He must become greater; i must become less." - John 3:30
http://www.bigfoot.com/~paulgear
_______________________________________________
java-gnome-developer mailing list
jav...@li...
http://lists.sourceforge.net/mailman/listinfo/java-gnome-developer

[Java-gnome-developer] Re: Hello

[Jean v. W. <je...@sm...>]

Hi,

To all the people lurking and watching on java-gnome-developer:

On Fri, 3 Nov 2000, Paul Gear wrote:

> Question from another lurker: how complete are the GNOME bindings in
> CVS?  They seem to be almost non-existant in 0.4.1 - where can i find
> information on how to use them?

Most of the GNOME bindings is done and even partially tested in the
version in CVS.

Since the 0.4.1 release we have made a lot of changes.  The project was
dormant for a while but is back on the track.  Jeff Morgan is the new
project leader.

We are working towards a 0.5.0 release with the added changes and with
better documentation and a tutorial.  We plan to bring it out as soon as
possible.

For those that are to impatient to wait feel free to check it out from
CVS, but check back regularly to get the aditional changes.

> I can't promise contribution, but i'd like to use the library to write a
> GNOME application - where is the best place to start?

The best place to start differs.  If you have GTK+/GNOME experience you
can just dive in and look at the test examples.  Have a browse through the
tutorial as well.  For those with no GTK+/GNOME experience start with the
tutorial, and then look at the examples in test.

TIP:  If you run "make doc" in the src directory you will get the javadoc
docmuentation of all the packages and classes plus all the methods that
was implemented so this is an excelent reference.

> Paul
> ---------
> "He must become greater; i must become less." - John 3:30
> http://www.bigfoot.com/~paulgear


Paul - please start writing your application.  You will most probably run
into some trouble.  We will be willing to help and we plan to expand the
Java-GNOME bindings as fast as we can.

Yours sincerely
Jean

Re: [Java-gnome-developer] Hello

[Paul G. <pau...@bi...>]

Jeff Morgan wrote:
> 
> Dan,
> 
> About a month ago I joined the project and took over as project leader.
> It had been dormant for about a year.  Since that time much work has
> been completed.  We are shooting for a 0.5 release within the next two
> weeks as well as a formal announcement of the projects resurrection.
> This release has numerous enhancements and bug fixes, documentation
> (including a tutorial) and the ability to create a GTK only binding.
>
> Most of the code is currently in CVS at sourceforge.  I hope to check
> more in this evening.  Your best bet is to checkout from CVS.

Question from another lurker: how complete are the GNOME bindings in
CVS?  They seem to be almost non-existant in 0.4.1 - where can i find
information on how to use them?

> I now have four developers actively working on this project.  I believe
> we are making good progress but additional help is always welcome.  If
> you wish to contribute we would welcome your involvement.

I can't promise contribution, but i'd like to use the library to write a
GNOME application - where is the best place to start?

Paul
---------
"He must become greater; i must become less." - John 3:30
http://www.bigfoot.com/~paulgear

RE: [Java-gnome-developer] Hello

[Dan B. <da...@mi...>]

Jeff writes:
>Most of the code is currently in CVS at sourceforge.  I hope to check
>more in this evening.  Your best bet is to checkout from CVS.

Ah, thanks for the tip. I'll try to do a CVS checkout and attempt to build
it within the next day or two (probably over the weekend, when I get the
most time to work on my project, as it's not something I'm getting paid
for). 

My guess is that I'll probably end up spending a lot of time just figuring
out how to write code to the API before feeling comfortable enough to
contribute back. As I said before, GUI programming is not one of my strong
suits (both in the sense of writing apps with GUIs *and* writing GUI
toolkits); most of my programming time has been in writing compilers,
interpreters, OS and GUIless-server type stuff.

-dan

RE: [Java-gnome-developer] Hello

[Jeff M. <ku...@ne...>]

Dan,

About a month ago I joined the project and took over as project leader.
It had been dormant for about a year.  Since that time much work has
been completed.  We are shooting for a 0.5 release within the next two
weeks as well as a formal announcement of the projects resurrection.  
This release has numerous enhancements and bug fixes, documentation 
(including a tutorial) and the ability to create a GTK only binding.

Most of the code is currently in CVS at sourceforge.  I hope to check
more in this evening.  Your best bet is to checkout from CVS.

I now have four developers actively working on this project.  I believe
we are making good progress but additional help is always welcome.  If
you wish to contribute we would welcome your involvement.

Please let me know if I can be of assistance.

-Jeff

-----Original Message-----
From: jav...@li...
[mailto:jav...@li...]On Behalf Of
Dan Bornstein
Sent: Thursday, November 02, 2000 4:34 PM
To: jav...@li...
Subject: [Java-gnome-developer] Hello


I just wanted to let whoever's listening know that I've recently begun work
on an application, the GUI of which I am now planning to do with the GTK
Java bindings. I notice that there hasn't been a release of it for a while,
and archives of this list don't seem to be available, so I'm not really
sure what the right tack to take is--do I get the year-old 0.4.1? Should I
do a cvs checkout? Has the project been abandoned? Or what? I'm a seasoned
programmer, although I'll freely admit that GUI programming is one of my
weaknesses, but I am willing to help in the process of developing and
debugging the library, to the extent that I can.

Your collective advice is hereby requested.

Thanks,

-dan
<http://www.milk.com/>
_______________________________________________
java-gnome-developer mailing list
jav...@li...
http://lists.sourceforge.net/mailman/listinfo/java-gnome-developer

[Java-gnome-developer] Hello

[Dan B. <da...@mi...>]

I just wanted to let whoever's listening know that I've recently begun work
on an application, the GUI of which I am now planning to do with the GTK
Java bindings. I notice that there hasn't been a release of it for a while,
and archives of this list don't seem to be available, so I'm not really
sure what the right tack to take is--do I get the year-old 0.4.1? Should I
do a cvs checkout? Has the project been abandoned? Or what? I'm a seasoned
programmer, although I'll freely admit that GUI programming is one of my
weaknesses, but I am willing to help in the process of developing and
debugging the library, to the extent that I can.

Your collective advice is hereby requested.

Thanks,

-dan
<http://www.milk.com/>