classpath
[Top][All Lists]
Advanced

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

Re: State of AWT


From: Tom Tromey
Subject: Re: State of AWT
Date: 02 Feb 2002 15:49:20 -0700

>>>>> "Mark" == Mark Wielaard <address@hidden> writes:

[ TestAWT working ]

Mark> What magic do I have to perform to see this working?  I tried
Mark> Orp with the latest Classpath libraries and the latest CVS
Mark> checkout of gcj combined with the Classpath classes and native
Mark> libs but with both I get only the following when trying the
Mark> TestAWT program:

I'm using libgcj, not ORP.  I still haven't built and tried ORP :-(

Here's what I did:

* Build Classpath with jikes (I still haven't tried building it with
  gcj.  I saw your post on the ORP list about ORP-vs-gcj, but I don't
  know anything about what might be wrong -- though I'd be interested
  in you find out).
  Building Classpath gets me the Gtk+ JNI native code in a convenient
  shared library.

* Copied the Classpath Gtk+ peer Java code to a hierarchy in /tmp/.
  This makes the next step simpler.

* Used `find' + a `while' loop to compile each such file like so:

    gcj -fPIC -g -fjni -o <whatever>.o <whatever>.java

* Linked all the resulting .o files into lib-gnu-java-awt.so

* Compiled TestAWT like this:

    gcj -g --main=TestAWT -o T TestAWT.java  -Wl,-rpath,/x1/egcs/install/lib 
-Wl,-rpath,/home/tromey/gnu/egcs/classpath/build/native/jni/gtk-peer/.libs 
-Wl,-rpath,/tmp/Build

  The -rpath stuff makes it possible to find the .so files at runtime.
  Your paths will vary.

* At this point, `./T' runs TestAWT.


I have one hack in my tree, too.  It makes things "work" ok for me,
but I haven't checked it in since I don't know that it is correct, or
even close.

I've appended the hack.  This particular patch affects window layout
(without it the peers get confused and use the window manager frame's
size as the insets, with strange results).  If you don't have this,
you should still get a window though.


In sum, it is a fairly ugly process for now.  Eventually (after gcc
3.1 is released), we can look at importing the Gtk+ peers into the
libgcj tree.  That should make it much simpler to build and test this
stuff.


Mark> returned
Mark> end
Mark> INSET:java.awt.Insets(top=0,bottom=0,left=0,right=0)
Mark> loading gtkpeer
Mark> init

After this I see:

    TRYING TO GET INTO GTKMAIN
    ACQUIRED LOCK TO RUN GTKMAIN
    returned
    end

... and then a bunch more stuff.

I've found I have to use the debugger a lot to make progress.
Luckily, with gcj this isn't too painful (gdb isn't great for Java
right now, but it is manageable).

Tom

Index: native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkEvents.c
===================================================================
RCS file: 
/cvsroot/classpath/classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkEvents.c,v
retrieving revision 1.3
diff -u -r1.3 gnu_java_awt_peer_gtk_GtkEvents.c
--- native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkEvents.c 22 Jan 2002 22:27:02 
-0000 1.3
+++ native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkEvents.c 2 Feb 2002 22:21:05 
-0000
@@ -408,10 +408,14 @@
                gdk_window_get_root_geometry (event->any.window, 
                                              &x, &y, &w, &h, &wb, &d);
 
+#if 0
                top = event->configure.y - y;
                left = event->configure.x - x;
                bottom = h - event->configure.height - top;
                right = w - event->configure.width - left;
+#else
+               top = left = bottom = right = 0;
+#endif
 
                /* configure events are not posted to the AWT event queue,
                   and as such, gdk/gtk will be called back before



reply via email to

[Prev in Thread] Current Thread [Next in Thread]