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

[Java-gnome-developer] Question concerning pixel graphics

[Markus F. <mar...@t-...>]

Hi, I'm new to java and java-gnome. I have a question about 
pixelgraphics:

For learning about java-gnome and java, I'm programming a mandelbrot 
generator. So, I'd like to know how I could access single pixels in a 
pixmap or a widget.

Thanks for your help.

RE: [Java-gnome-developer] Patch for GnomeDruid support

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

One other thing - I still need to complete the work for
Gnome 2 at some point.

>  
> > This begs the question of what gnome libraries need to be 
> wrapped, and
> > in what order.  Perhaps a list of targeted gnome libraries 
> > (and they are
> > legion) should be compiled, with completion status for each one.
> 
> My goal for the next release or two (1-2 months) is to focus inward.
> I am trying to resist the temptation of just adding new features and
> am making sure that all of the features the currently exist function
> properly and that the binding are as useful as possible.  To that
> end I am in the middle of a review of most of the visual widgets
> method-by-method to determine what doesn't work.  I am fixing
> what is broken and also adding and enhancing examples along the
> way.  I have also started to add the ability to insert comments
> into the generated code which produces usable javadocs.  I am also
> writing a new chapter for the tutorial.
> 
> I still don't have all of the GDK, GTK, and GNOME (both visual
> and non-visual) objects wrapped at this time.  I would like to
> get as much of this completed as possible before attacking too 
> many additional libraries.  If you have a specific need please
> let me know.
> 
> Going forward I would like to hear from the developers that intend
> to use the bindings.  Please respond to this list with your wish-list.
> 
> > 
> > I don't know how many non-GUI libraries are necessary to wrap, for
> > example libxml.  Java already has these and more.  If all non-gui
> > libraries are skipped, that leaves significantly fewer 
> > libraries.  But a
> > few non-gui libraries that must be dealt with are bonobo, 
> gnome-media,
> > gnome-audio, etc.  I assume that the goal is to be able to 
> > make any type
> > of Gnome app using java-gnome.  Is this the case?
> > 
> 
> There is already an example of a java bonobo implementation in gnome
> cvs.
> 
> -Jeff
> 

RE: [Java-gnome-developer] Patch for GnomeDruid support

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

 
> This begs the question of what gnome libraries need to be wrapped, and
> in what order.  Perhaps a list of targeted gnome libraries 
> (and they are
> legion) should be compiled, with completion status for each one.

My goal for the next release or two (1-2 months) is to focus inward.
I am trying to resist the temptation of just adding new features and
am making sure that all of the features the currently exist function
properly and that the binding are as useful as possible.  To that
end I am in the middle of a review of most of the visual widgets
method-by-method to determine what doesn't work.  I am fixing
what is broken and also adding and enhancing examples along the
way.  I have also started to add the ability to insert comments
into the generated code which produces usable javadocs.  I am also
writing a new chapter for the tutorial.

I still don't have all of the GDK, GTK, and GNOME (both visual
and non-visual) objects wrapped at this time.  I would like to
get as much of this completed as possible before attacking too 
many additional libraries.  If you have a specific need please
let me know.

Going forward I would like to hear from the developers that intend
to use the bindings.  Please respond to this list with your wish-list.

> 
> I don't know how many non-GUI libraries are necessary to wrap, for
> example libxml.  Java already has these and more.  If all non-gui
> libraries are skipped, that leaves significantly fewer 
> libraries.  But a
> few non-gui libraries that must be dealt with are bonobo, gnome-media,
> gnome-audio, etc.  I assume that the goal is to be able to 
> make any type
> of Gnome app using java-gnome.  Is this the case?
> 

There is already an example of a java bonobo implementation in gnome
cvs.

-Jeff

[Java-gnome-developer] Java bindings for GStreamer available

[Christian S. <ur...@li...>]

Hi people,
I thought that I should make you aware that we have a set of Java
bindings for GStreamer available in GStreamer CVS. The module name is 
gst-bind. For those of you who don't know GStreamer so is it a library
for creating multimedia applications like mediaplayers, non-linear video
editors, streaming media server etc. 

GStreamer aims at inclusion in the GNOME 5th toe release for GNOME 2.0
and then becoming the official multimedia API of GNOME for GNOME 2.2.

Info can be found at http://www.gstreamer.net

Sincerely,
Christian Schaller

RE: [Java-gnome-developer] Patch for GnomeDruid support

[John M. <jo...@ma...>]

On Mon, 2001-10-29 at 13:15, Jeffrey Morgan wrote:
> I applied you patch.  There were a few issues.  Java-GNOME
> currently doesn't have support for GdkImlibImage.  This class
> is not part of Gdk, Gtk, or Gnome and we do not check for its'
> existence in the build process.  In order to get it to compile
> for the time being I had to comment out the methods that
> use this type.

This begs the question of what gnome libraries need to be wrapped, and
in what order.  Perhaps a list of targeted gnome libraries (and they are
legion) should be compiled, with completion status for each one.

I don't know how many non-GUI libraries are necessary to wrap, for
example libxml.  Java already has these and more.  If all non-gui
libraries are skipped, that leaves significantly fewer libraries.  But a
few non-gui libraries that must be dealt with are bonobo, gnome-media,
gnome-audio, etc.  I assume that the goal is to be able to make any type
of Gnome app using java-gnome.  Is this the case?

John

RE: [Java-gnome-developer] Patch for GnomeDruid support

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

I applied you patch.  There were a few issues.  Java-GNOME
currently doesn't have support for GdkImlibImage.  This class
is not part of Gdk, Gtk, or Gnome and we do not check for its'
existence in the build process.  In order to get it to compile
for the time being I had to comment out the methods that
use this type.

-Jeff

> 
> This patch adds def's for GnomeDruid, GnomeDruidPage,
> GnomeDruidPageStart, GnomeDruidPageStandard and GnomeDruidPageFinish.
> 
> 
> 
> 
> 

[Java-gnome-developer] Patch for GnomeDruid support

[John M. <jo...@ma...>]

This patch adds def's for GnomeDruid, GnomeDruidPage,
GnomeDruidPageStart, GnomeDruidPageStandard and GnomeDruidPageFinish.

RE: [Java-gnome-developer] Problems using libglade with a GnomeAp p?

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

Sorry about that.  CVS should compile now.  The
problem you were having is that you are using a
widget of type GtkPixmapMenuItem in your glade
file.  Prior to today Java-GNOME did not have this
widget.  I have made the changes and checked into
CVS.  If you get the latest snapshot you should be
able to run.  You will need to define your callback
methods in your class.

Hope this helps

-Jeff

> 
> Jeff,
> 
> I can't compile the CVS code.  Here is my error:
> 
> make gtk_jarfile gtk_nativelib
> make[2]: Entering directory `/usr/src/other/java-gnome/src'
> /usr/local/java/jdk/bin/javac -d . other/BaseBoxed.java
> --snip--
> /usr/local/java/jdk/bin/javac -d . gnu/gtk/GtkTooltips.java
> /usr/local/java/jdk/bin/javac -d . gnu/gtk/GtkCTree.java
> /usr/local/java/jdk/bin/javac -d . gnu/gtk/GtkProgressBar.java
> /usr/local/java/jdk/bin/javac -d . gnu/gtk/GtkCheckMenuItem.java
> ./gnu/gtk/GtkMenuItem.java:147: activate() in 
> gnu.gtk.GtkMenuItem cannot
> override activate() in gnu.gtk.GtkWidget; attempting to use 
> incompatible
> return type
> found   : void
> required: boolean
>     native public void activate ();
>                        ^
> 1 error
> make[2]: *** [gnu/gtk/GtkCheckMenuItem.class] Error 1
> make[2]: Leaving directory `/usr/src/other/java-gnome/src'
> make[1]: *** [gtk] Error 2
> make[1]: Leaving directory `/usr/src/other/java-gnome/src'
> make: *** [distro] Error 2
> 
> 
> On Mon, 2001-10-22 at 08:47, Jeffrey Morgan wrote:
> > I believe I might be on to the problem.  Can I
> > get you to try one more thing?  Can you please
> > get the code from CVS and see if the problem
> > exists?
> 

RE: [Java-gnome-developer] Problems using libglade with a GnomeAp p?

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

I don't believe this problem has been reported before. 
Can you give me some more information such as what
JVM, which version of java-gnome, what version of
gcc, etc.

-Jeff

> 
> When I try to load a .glade file using the libglade test 
> program, I get
> an error if I use GnomeApp.  GtkWindow-based forms work fine.
> 
> Running in gdb I get:
> 
> 0x4038f1e1 in _Jv_JNI_AllocObject(_Jv_JNIEnv*, 
> java::lang::Class*) () at
> eval.c:41
> 41	eval.c: No such file or directory.
> 	in eval.c
> 
> Anyone else seen this problem, or is this a known problem?
> 
> John
> 
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> 

[Java-gnome-developer] Problems using libglade with a GnomeApp?

[John M. <jo...@ma...>]

When I try to load a .glade file using the libglade test program, I get
an error if I use GnomeApp.  GtkWindow-based forms work fine.

Running in gdb I get:

0x4038f1e1 in _Jv_JNI_AllocObject(_Jv_JNIEnv*, java::lang::Class*) () at
eval.c:41
41	eval.c: No such file or directory.
	in eval.c

Anyone else seen this problem, or is this a known problem?

John

[Java-gnome-developer] RE: howto compile on RH7.1?

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

I compile the project daily using gcc 3.0.0 on rh 7.1.

>=20
> RE: [Java-gnome-developer] howto compile on RH7.1?I have=20
> tried compiling it
> several times but it consistently fails
> when it reaches TestGTK. Before "make" reaches TestGTK,
> it succesfully compiles a bunch of other javasources with gcj. The
> gcj "classpath=3D" argument is used for theese. It is not used
> for compiling TestGTK.
>=20
> Has anyone succesfully compiled java-gnome 0.7 on RedHat 7.1?
> (with gcc 3.0.2)
>=20
> S=F8ren
>=20
> >----- Original Message -----
> >From: Jeffrey Morgan
> >To: 'S=F8ren'
> >Sent: Tuesday, October 16, 2001 12:27 PM
> >Subject: RE: [Java-gnome-developer] howto compile on RH7.1?
> >
> >
> >This is a strange behavior that happens fairly frequently.
> >Typically if you just type make immediately after getting
> >this error you will compile fine.  I haven't been able
> >to determine the cause.
> >>
> >> I am trying to compile java-gnome for use with native gcj:
> >>
> >> ./configure --libdir=3D/usr/lib --with-gcj-compile
> >> make
> >>
> >> ... then when its about finished it tries to compile
> >> TestGTK with gcj, but gets a lot of undefined references
> >> for gnu.gtk methods. Do I need to set the classpath before
> >> using "make"? and where should it point?
> >>
> >> S=F8ren
>=20
>=20

[Java-gnome-developer] Re: howto compile on RH7.1?

[<bi...@ma...>]

RE: [Java-gnome-developer] howto compile on RH7.1?I have tried compiling it
several times but it consistently fails
when it reaches TestGTK. Before "make" reaches TestGTK,
it succesfully compiles a bunch of other javasources with gcj. The
gcj "classpath=" argument is used for theese. It is not used
for compiling TestGTK.

Has anyone succesfully compiled java-gnome 0.7 on RedHat 7.1?
(with gcc 3.0.2)

Søren

>----- Original Message -----
>From: Jeffrey Morgan
>To: 'Søren'
>Sent: Tuesday, October 16, 2001 12:27 PM
>Subject: RE: [Java-gnome-developer] howto compile on RH7.1?
>
>
>This is a strange behavior that happens fairly frequently.
>Typically if you just type make immediately after getting
>this error you will compile fine.  I haven't been able
>to determine the cause.
>>
>> I am trying to compile java-gnome for use with native gcj:
>>
>> ./configure --libdir=/usr/lib --with-gcj-compile
>> make
>>
>> ... then when its about finished it tries to compile
>> TestGTK with gcj, but gets a lot of undefined references
>> for gnu.gtk methods. Do I need to set the classpath before
>> using "make"? and where should it point?
>>
>> Søren

[Java-gnome-developer] Re.: UnsatisfiedLinkError

[Peter D. M. <pe...@ma...>]

In September someone posted the 2 posts I have included below, and I would
just like to follow up on this. I'm running Red Hat 7.1 and a regular J2SDK
1.3.1, and I had the same UnsatisfiedLinkError, but i had it both with GNOME
and GTK. The same solution worked, just add the links as described below.

Sorry for the spam, but I just think this is such a cool lib that I had to
make sure others with 1.3.1 make sure to try this before they give up. :)

Oh and btw, watch out for kaffe (jvm) which you might have installed from
Red Hat.

/Mains

> Hi again,
>
> Following up from my message yesterday -
>
> It looks like you can solve the problem with the v1.4 JVM by
> sym linking
> the two shared libraries into the $JAVAROOT/jre/lib/i386 (for i386
> linux). Despite having both libraries in my LD_LIBRARY_PATH the JVM
> only seems to work when this is done.
>
> Hope this is useful.
>
> Java-gnome is excellent btw!
>
>  -Dan
>
>



>Hi,
>
>I've just been trying out Sun's JVM 1.4 (Beta 2) and am getting the
>following error when trying to run any application that uses the
>libGNOMEJava.so library. (interestingly, the problem does not
>occur with libGTKJava.so lib).
>
>Exception in thread
>"main" java.lang.UnsatisfiedLinkError: /share/Profile/lib/libGNOMEJava.so:
>/share/Profile/lib/libGNOMEJava.so: undefined
>symbol: makeBaseObjectClass
>	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1440)
>	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1364)
>	at java.lang.Runtime.loadLibrary0(Runtime.java:773)
>	at java.lang.System.loadLibrary(System.java:835)
>	at gnu.gnome.Gnome.<clinit>(Gnome.java:33)
>	at TestGNOME.main(TestGNOME.java:397)
>
>As the new JVM is still beta software, I'm not expecting you to change
>anything - but wondered if you had an idea on what might be causing this.
>
>Thanks,
> -Daniel.

Re: [Java-gnome-developer] Testing

[John L. <je...@pi...>]

On Mon, Oct 08, 2001 at 07:20:51AM -0400, Jeffrey Morgan wrote:
> Thanks for the input and feedback.  I have never seen the
> problem you describe on the clist.  When it crashes does it
> produce a core? What additional information can you provide?

It may/may not be useful, but when I run clist and click "Add 1000 rows" with my JVM, I get the following backtrace:

The line in gnu_gtk_GtkClist.c (frame 6) is:

1110                jint result_j = (jint) (gtk_clist_append (cptr, text_g));


(gdb) bt
#0  0x40e72995 in gtk_signal_remove_emission_hook () from /usr/lib/libgtk-1.2.so.0
#1  0x40e71d15 in gtk_signal_set_funcs () from /usr/lib/libgtk-1.2.so.0
#2  0x40e6fdf3 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#3  0x40df0488 in gtk_clist_select_row () from /usr/lib/libgtk-1.2.so.0
#4  0x40dee7ed in gtk_clist_clear () from /usr/lib/libgtk-1.2.so.0
#5  0x40dee3c6 in gtk_clist_append () from /usr/lib/libgtk-1.2.so.0
#6  0x40da3d90 in Java_gnu_gtk_GtkCList_append0 (env=0x80e6330, obj=0x40c101dc, text=0x40c13490)
    at gnu/jni/gnu_gtk_GtkCList.c:1110
#7  0x8066171 in JNI_CallNativeMethod (pstFrame=0x82c4e28, pstMethod=0x82a514c) at ./vm/jni_native_call.c:707
#8  0x805367c in Interpret (env=0x80e6330, pstInitFrame=0x82c4db8, iMultiThread=1)
    at vm/interp/method_invocation.h:797
#9  0x804c4c6 in INTERP_RunVirtualMethodFromPtr (env=0x80e6330, pstMethod=0x81b7984, pi32Args=0x82c44b8)
    at ./vm/interp/interp.c:1194
#10 0x8069968 in CallVoidMethodA (env=0x80e6330, obj=0x40bfb238, methodID=0x81b7984, args=0xbfffea14)
    at ./vm/jni.c:1181
#11 0x40d8e917 in jobject_signal_cb (object=0x8274e00, data=0x82835e8, n_args=0, args=0xbfffeb3c)
    at other/callback_dispatcher.c:242
#12 0x40e72885 in gtk_signal_remove_emission_hook () from /usr/lib/libgtk-1.2.so.0
#13 0x40e71d15 in gtk_signal_set_funcs () from /usr/lib/libgtk-1.2.so.0
#14 0x40e6fdf3 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#15 0x40de10a8 in gtk_button_clicked () from /usr/lib/libgtk-1.2.so.0
#16 0x40de262d in gtk_button_get_relief () from /usr/lib/libgtk-1.2.so.0
#17 0x40e43035 in gtk_marshal_NONE__NONE () from /usr/lib/libgtk-1.2.so.0
#18 0x40e71baf in gtk_signal_set_funcs () from /usr/lib/libgtk-1.2.so.0
#19 0x40e6fdf3 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#20 0x40de0fe8 in gtk_button_released () from /usr/lib/libgtk-1.2.so.0
#21 0x40de1f98 in gtk_button_get_relief () from /usr/lib/libgtk-1.2.so.0
#22 0x40e42cbf in gtk_marshal_BOOL__POINTER () from /usr/lib/libgtk-1.2.so.0
---Type <return> to continue, or q <return> to quit---
#23 0x40e71d53 in gtk_signal_set_funcs () from /usr/lib/libgtk-1.2.so.0
#24 0x40e6fdf3 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#25 0x40ea6a0b in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0
#26 0x40e42c05 in gtk_propagate_event () from /usr/lib/libgtk-1.2.so.0
#27 0x40e41d6e in gtk_main_do_event () from /usr/lib/libgtk-1.2.so.0
#28 0x40ef04b7 in gdk_wm_protocols_filter () from /usr/lib/libgdk-1.2.so.0
#29 0x40f1d308 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#30 0x40f1d913 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#31 0x40f1daac in g_main_run () from /usr/lib/libglib-1.2.so.0
#32 0x40e41667 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#33 0x40d99a4c in Java_gnu_gtk_Gtk_main (env=0x80e6330, cls=0x40bfb234) at gnu/jni/gnu_gtk_Gtk.c:51
#34 0x8065b8a in JNI_CallNativeMethod (pstFrame=0x81ab990, pstMethod=0x81b2574) at ./vm/jni_native_call.c:502
#35 0x8053b23 in Interpret (env=0x80e6330, pstInitFrame=0x81ab990, iMultiThread=1)
    at vm/interp/method_invocation.h:1181
#36 0x8073342 in STARTUP_startup (pszMainClass=0xbffffd34 "TestGTK", pszStoreName=0x80980d5 "persistent_store", 
    argc=4, argv=0xbffffbc4, argsused=4) at ./vm/startup.c:409
#37 0x806f69e in main (argc=4, argv=0xbffffbc4, c_env=0xbffffbd8) at ./vm/kissme_main.c:457


The cptr looks like this:

 p *cptr 
$4 = {container = {widget = {object = {klass = 0x82a61f8, flags = 69580, ref_count = 2, object_data = 0x823e680}, 
      private_flags = 0, state = 0 '\000', saved_state = 0 '\000', name = 0x0, style = 0x823c8d8, requisition = {
        width = 634, height = 27}, allocation = {x = 10, y = 94, width = 373, height = 42}, window = 0x82c46a8, 
      parent = 0x82c41c8}, focus_child = 0x0, border_width = 0, need_resize = 0, resize_mode = 0, 
    reallocate_redraws = 0, resize_widgets = 0x0}, flags = 782, row_mem_chunk = 0x82a7c88, 
  cell_mem_chunk = 0x82a7cd0, freeze_count = 1, internal_allocation = {x = 0, y = 0, width = 373, height = 42}, 
  rows = 1, row_center_offset = 12, row_height = 20, row_list = 0x8273c90, row_list_end = 0x8273c90, columns = 7, 
  column_title_area = {x = 2, y = 2, width = 369, height = 22}, title_window = 0x82c46e0, column = 0x82a7d18, 
  clist_window = 0x82c4718, clist_window_width = 369, clist_window_height = 16, hoffset = 0, voffset = 0, 
  shadow_type = GTK_SHADOW_IN, selection_mode = GTK_SELECTION_BROWSE, selection = 0x8273c9c, 
  selection_end = 0x8273c9c, undo_selection = 0x0, undo_unselection = 0x0, undo_anchor = -1, 
  button_actions = "\003\000\000\000", drag_button = 0 '\000', click_cell = {row = -1, column = -1}, 
  hadjustment = 0x82b7b90, vadjustment = 0x82c4258, xor_gc = 0x82c4a08, fg_gc = 0x82c48e8, bg_gc = 0x82c4978, 
  cursor_drag = 0x82c4750, x_drag = 0, focus_row = 0, anchor = -1, anchor_state = GTK_STATE_SELECTED, 
  drag_pos = -1, htimer = 0, vtimer = 0, sort_type = GTK_SORT_ASCENDING, 
  compare = 0x40df909c <gtk_clist_set_sort_column+164>, sort_column = 0}

And text_g is:

p text_g
$5 = (gchar **) 0x406cd67c

p *text_g
$6 = (gchar *) 0x2 <Address 0x2 out of bounds>


John Leuner

Re: [Java-gnome-developer] Testing

[John L. <je...@pi...>]

On Mon, Oct 08, 2001 at 07:20:51AM -0400, Jeffrey Morgan wrote:
> Thanks for the input and feedback.  I have never seen the
> problem you describe on the clist.  When it crashes does it
> produce a core? What additional information can you provide?

Hello Jeffrey

I run TestGTK and click clist. Then I click "Add 10000 rows".

Here is the output:

bapli% /usr/local/jdk1.3/bin/java -cp lib/gtk.jar:lib/gnome.jar:test TestGTK                   ~/dev/java-gnome-0.7
SIGSEGV 11 (*) segmentation violation
    si_signo [11]: SIGSEGV: (*) segmentation violation
    si_errno [0]: Success
    si_code [1]: SEGV_MAPERR [addr: 0x4]

        stackpointer=0xbffc1ae4
Writing java dump to javacore5845.1003088919.txt ...  OK
SIGABRT 6 (*) abort process
        stackpointer=0xbffc1508
zsh: abort      /usr/local/jdk1.3/bin/java -cp lib/gtk.jar:lib/gnome.jar:test TestGTK

I will also attach the core .txt file. This is IBM's 1.3 JDK for Linux.

This happens with or without my patch that I mentioned earlier:

Index: src/other/callback_dispatcher.c
===================================================================
RCS file: /cvsroot/java-gnome/java-gnome/src/other/callback_dispatcher.c,v
retrieving revision 1.17
diff -r1.17 callback_dispatcher.c
31c31
<     obj_pointer = (*env)->GetIntField(env, obj, gtkobj_fieldID);
---
>     obj_pointer = (*env)->GetLongField(env, obj, gtkobj_fieldID);

John Leuner

[Java-gnome-developer] howto compile on RH7.1?

[<bi...@ma...>]

I am trying to compile java-gnome for use with native gcj:

./configure --libdir=3D/usr/lib --with-gcj-compile
make

... then when its about finished it tries to compile=20
TestGTK with gcj, but gets a lot of undefined references=20
for gnu.gtk methods. Do I need to set the classpath before
using "make"? and where should it point?

S=F8ren

RE: [Java-gnome-developer] CVS: Problem with gdk_BaseObject.c and GTK_IS_OBJECT()

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

What I ultimately did to resolve this was change all of the GDK types
in gdk.defs to be of type define-boxed which creates the shell java
class with the appropriate accessors and methods but initializes the
object without a check for the GTK type.  This update is in CVS if
you want to check it out.  Let me know if this works for you.
 
-Jeff

This seems like a simple approach that will work.  I 
think I will try it this evening.  Wow - thanks!! 

-Jeff 

> 
> Of course there is no generic way to test that -- we could put all GTK 
> objects into a hashtable and check them from there.. but 
> that's not really 
> an option. 
> 
> However, the caller to makeBaseObjectSubclass routine always knows the 
> type of the 'peer' argument, eg. whether it is a GTK or 
> non-GTK object. 
> Thus, we could remove the GTK_IS_OBJECT test from 
> makeBaseObjectSubclass, 
> add a new routine makeGtkBaseObjectSubclass, which would have the 
> GTK_IS_OBJECT test, and modify the code generator to use the 
> GTK routine 
> version when it knows that the underlying object (for which 
> it is being 
> called) is a GTK (or Gnome) object, and not some other (glib, gdk). 
> 
> -- 
> sa...@ik...                    I have become death, 
> destroyer of the worlds. 
> 
> 
> 

RE: [Java-gnome-developer] CVS: Problem with gdk_BaseObject.c and GTK_IS_OBJECT()

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

This seems like a simple approach that will work.  I
think I will try it this evening.  Wow - thanks!!

-Jeff

> 
> Of course there is no generic way to test that -- we could put all GTK
> objects into a hashtable and check them from there.. but 
> that's not really
> an option.
> 
> However, the caller to makeBaseObjectSubclass routine always knows the
> type of the 'peer' argument, eg. whether it is a GTK or 
> non-GTK object.
> Thus, we could remove the GTK_IS_OBJECT test from 
> makeBaseObjectSubclass,
> add a new routine makeGtkBaseObjectSubclass, which would have the
> GTK_IS_OBJECT test, and modify the code generator to use the 
> GTK routine
> version when it knows that the underlying object (for which 
> it is being
> called) is a GTK (or Gnome) object, and not some other (glib, gdk).
> 
> --
> sa...@ik...                    I have become death, 
> destroyer of the worlds.
> 
> 
> 

RE: [Java-gnome-developer] CVS: Problem with gdk_BaseObject.c and GTK_IS_OBJECT()

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

What I have is a pointer to the underlying peer which
could be a GTK type, a GNOME type or a GDK type.  Since
the pointer to the peer is stored the same in each
case it is stored as a void pointer.

> Do you really need to pass void pointers around?
> 
> John Leuner
> 

Re: [Java-gnome-developer] CVS: Problem with gdk_BaseObject.c and GTK_IS_OBJECT()

[John L. <je...@pi...>]

> I have struggled with this issue for some time and as
> yet haven't found a solution.  I need to determine if
> a void pointer is actually pointing to a GTK type.  All
> macros and methods in GTK assume this is the case
> (like the GTK_IS_OBJECT macro below).  Does anybody
> have a suggestion?

Do you really need to pass void pointers around?

John Leuner


> > 
> > In CVS version, in other/gdk_BaseObject.c:
> > 
> > jobject makeBaseObjectSubclass (JNIEnv *env, jclass cls, void *peer)
> > {
> >   if (peer == NULL)
> >     return NULL;
> >   else if (GTK_IS_OBJECT(peer))
> >     return makeBaseObjectClass(env, peer);
> >   else {
> >     jobject result = (*env)->AllocObject (env, cls);
> >     jlong result_jl;
> > 
> >     *(void **) &result_jl = peer;
> >     (*env)->SetLongField (env, result, nativepeerFid, result_jl);
> >     return result;
> >   }
> > }
> > 
> > The GTK_IS_OBJECT is a problem, if you try to create any 
> > object not based
> > on Gtk, like GdkGC:
> > 
> > 	xx = new GdkGC(yy);
> > 
> > leads to:
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x41383ed6 in makeBaseObjectSubclass (env=0x400887d4, cls=0x6,
> > peer=0x81244f8)
> >     at other/gdk_BaseObject.c:70
> > 70        else if (GTK_IS_OBJECT(peer))
> > 
> > This, of course happens because "peer" in this context is not a Gtk
> > object, but instead a GdkWindow, which isn't representable in the Gtk
> > object system:
> > 
> > (gdb) p *(GdkGC*)peer
> > $14 = {dummy_var = 1701080693}
> > (gdb) p *((GtkObject*)peer)
> > $15 = {klass = 0x65646e75, flags = 135415064, ref_count = 135220712,
> >   object_data = 0x1}
> > (gdb) p *((GtkObject*)peer)->klass
> > Cannot access memory at address 0x65646e75
> > 
> > In noticed the GTK_IS_OBJECT was added in version 1.5 (of that file).
> > Apparently this hasn't been noticed since the test and sample programs
> > don't use GdkGC directly at all..
> > 
> > --
> > sa...@ik...                    I have become death, 
> > destroyer of the worlds.
> > 
> > 
> > _______________________________________________
> > java-gnome-developer mailing list
> > jav...@li...
> > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> > 

RE: [Java-gnome-developer] CVS: Problem with gdk_BaseObject.c and GTK_IS_OBJECT()

[Santeri P. <sa...@ik...>]

On Tue, 9 Oct 2001, Jeffrey Morgan wrote:
> I have struggled with this issue for some time and as yet haven't
> found a solution.  I need to determine if a void pointer is actually
> pointing to a GTK type.  All macros and methods in GTK assume this is
> the case (like the GTK_IS_OBJECT macro below).  Does anybody have a
> suggestion?

Of course there is no generic way to test that -- we could put all GTK
objects into a hashtable and check them from there.. but that's not really
an option.

However, the caller to makeBaseObjectSubclass routine always knows the
type of the 'peer' argument, eg. whether it is a GTK or non-GTK object.
Thus, we could remove the GTK_IS_OBJECT test from makeBaseObjectSubclass,
add a new routine makeGtkBaseObjectSubclass, which would have the
GTK_IS_OBJECT test, and modify the code generator to use the GTK routine
version when it knows that the underlying object (for which it is being
called) is a GTK (or Gnome) object, and not some other (glib, gdk).

--
sa...@ik...                    I have become death, destroyer of the worlds.

RE: [Java-gnome-developer] CVS: Problem with gdk_BaseObject.c and GTK_IS_OBJECT()

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

I have struggled with this issue for some time and as
yet haven't found a solution.  I need to determine if
a void pointer is actually pointing to a GTK type.  All
macros and methods in GTK assume this is the case
(like the GTK_IS_OBJECT macro below).  Does anybody
have a suggestion?

-Jeff

> 
> In CVS version, in other/gdk_BaseObject.c:
> 
> jobject makeBaseObjectSubclass (JNIEnv *env, jclass cls, void *peer)
> {
>   if (peer == NULL)
>     return NULL;
>   else if (GTK_IS_OBJECT(peer))
>     return makeBaseObjectClass(env, peer);
>   else {
>     jobject result = (*env)->AllocObject (env, cls);
>     jlong result_jl;
> 
>     *(void **) &result_jl = peer;
>     (*env)->SetLongField (env, result, nativepeerFid, result_jl);
>     return result;
>   }
> }
> 
> The GTK_IS_OBJECT is a problem, if you try to create any 
> object not based
> on Gtk, like GdkGC:
> 
> 	xx = new GdkGC(yy);
> 
> leads to:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x41383ed6 in makeBaseObjectSubclass (env=0x400887d4, cls=0x6,
> peer=0x81244f8)
>     at other/gdk_BaseObject.c:70
> 70        else if (GTK_IS_OBJECT(peer))
> 
> This, of course happens because "peer" in this context is not a Gtk
> object, but instead a GdkWindow, which isn't representable in the Gtk
> object system:
> 
> (gdb) p *(GdkGC*)peer
> $14 = {dummy_var = 1701080693}
> (gdb) p *((GtkObject*)peer)
> $15 = {klass = 0x65646e75, flags = 135415064, ref_count = 135220712,
>   object_data = 0x1}
> (gdb) p *((GtkObject*)peer)->klass
> Cannot access memory at address 0x65646e75
> 
> In noticed the GTK_IS_OBJECT was added in version 1.5 (of that file).
> Apparently this hasn't been noticed since the test and sample programs
> don't use GdkGC directly at all..
> 
> --
> sa...@ik...                    I have become death, 
> destroyer of the worlds.
> 
> 
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> 

[Java-gnome-developer] CVS: Problem with gdk_BaseObject.c and GTK_IS_OBJECT()

[Santeri P. <sa...@ik...>]

In CVS version, in other/gdk_BaseObject.c:

jobject makeBaseObjectSubclass (JNIEnv *env, jclass cls, void *peer)
{
  if (peer == NULL)
    return NULL;
  else if (GTK_IS_OBJECT(peer))
    return makeBaseObjectClass(env, peer);
  else {
    jobject result = (*env)->AllocObject (env, cls);
    jlong result_jl;

    *(void **) &result_jl = peer;
    (*env)->SetLongField (env, result, nativepeerFid, result_jl);
    return result;
  }
}

The GTK_IS_OBJECT is a problem, if you try to create any object not based
on Gtk, like GdkGC:

	xx = new GdkGC(yy);

leads to:

Program received signal SIGSEGV, Segmentation fault.
0x41383ed6 in makeBaseObjectSubclass (env=0x400887d4, cls=0x6,
peer=0x81244f8)
    at other/gdk_BaseObject.c:70
70        else if (GTK_IS_OBJECT(peer))

This, of course happens because "peer" in this context is not a Gtk
object, but instead a GdkWindow, which isn't representable in the Gtk
object system:

(gdb) p *(GdkGC*)peer
$14 = {dummy_var = 1701080693}
(gdb) p *((GtkObject*)peer)
$15 = {klass = 0x65646e75, flags = 135415064, ref_count = 135220712,
  object_data = 0x1}
(gdb) p *((GtkObject*)peer)->klass
Cannot access memory at address 0x65646e75

In noticed the GTK_IS_OBJECT was added in version 1.5 (of that file).
Apparently this hasn't been noticed since the test and sample programs
don't use GdkGC directly at all..

--
sa...@ik...                    I have become death, destroyer of the worlds.

RE: [Java-gnome-developer] Error recompiling Java-GTK+

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

Thanks for the info.  I will try to generate new
rpms sometime today.

-Jeff

> 
> Hi Jeffrey,
> I think your RPM setup is made for confusion currently. I 
> downloaded the
> src.rpm with java-gnome thinking it contained all I needed. 
> After it had
> built I tried installing it, but it complained about java-gtk 
> missing so
> I tried building that, which failed with the message I sent earlier.
> 
> After recieving your reply I saw that the gnome src.rpm contained all
> the code I needed but the spec file was only made to create the GNOME
> part of the RPM. I suggest having the GNOME SPEC file create both the
> GTK+ and the GNOME package. Anyway I just built the whole thing from
> source like I did with the last version and it worked well.
> 
> Christian
> 
> On Mon, 2001-10-08 at 17:26, Jeffrey Morgan wrote:
> > This is a problem with the GTK only build.  I used to have
> > access to a system that only had GTK on which I could test.
> > I believe a short-term fix would be to edit the
> > src/other/gtk_wrappers.h file adding :
> > 
> > #ifdef GTK
> > #include <gtk/gtk.h>
> > #endif
> > 
> > after the check for GNOME.  Could you please let me know if
> > this fixes the problem.  If it does, I'll update the file
> > in CVS.
> > 
> > Thanks
> > -Jeff
> > 
> > > 
> > > Hi,
> > > Trying to compile using the SRPM Java-GTK 0.7 releae I get 
> > > the following
> > > compile error, any suggestions?
> > > 
> > > RPM build errors:
> > >     Bad exit status from /var/tmp/rpm-tmp.7354 
> (%build)gcc -c -g -O2
> > > -fPIC -Iother other/gnu_gtk_GtkCell.c -o 
> other/gnu_gtk_GtkCell.o -I
> > > /usr/java/jdk1.3.1/include -I /usr/java/jdk1.3.1/include/linux
> > > -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 
> -I/usr/lib/glib/include
> > > -I/usr/X11R6/include \
> > >      -I/usr/include/gnome-xml -I/usr/include/gtk-1.2
> > > -I/usr/include/glib-1.2 -I/usr/lib/glib/include 
> -I/usr/X11R6/include
> > > -DGTK
> > > In file included from other/gnu_gtk_GtkCell.c:11:
> > > other/gtk_wrappers.h:15: parse error before `jobject_to_gpointer'
> > > other/gtk_wrappers.h:15: warning: data definition has no type 
> > > or storage
> > > class
> > > make[2]: *** [other/gnu_gtk_GtkCell.o] Error 1
> > > make[2]: Leaving directory 
> `/usr/src/redhat/BUILD/java-gtk-0.7/src'
> > > make[1]: *** [gtk] Error 2
> > > make[1]: Leaving directory 
> `/usr/src/redhat/BUILD/java-gtk-0.7/src'
> > > make: *** [distro] Error 2
> > > error: Bad exit status from /var/tmp/rpm-tmp.7354 (%build)
> > > 
> > > 
> > > RPM build errors:
> > >     Bad exit status from /var/tmp/rpm-tmp.7354 (%build
> > > 
> > > Christian
> > > 
> > > 
> > > _______________________________________________
> > > java-gnome-developer mailing list
> > > jav...@li...
> > > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> > > 
> 
> 

RE: [Java-gnome-developer] Error recompiling Java-GTK+

[Christian S. <ur...@li...>]

Hi Jeffrey,
I think your RPM setup is made for confusion currently. I downloaded the
src.rpm with java-gnome thinking it contained all I needed. After it had
built I tried installing it, but it complained about java-gtk missing so
I tried building that, which failed with the message I sent earlier.

After recieving your reply I saw that the gnome src.rpm contained all
the code I needed but the spec file was only made to create the GNOME
part of the RPM. I suggest having the GNOME SPEC file create both the
GTK+ and the GNOME package. Anyway I just built the whole thing from
source like I did with the last version and it worked well.

Christian

On Mon, 2001-10-08 at 17:26, Jeffrey Morgan wrote:
> This is a problem with the GTK only build.  I used to have
> access to a system that only had GTK on which I could test.
> I believe a short-term fix would be to edit the
> src/other/gtk_wrappers.h file adding :
> 
> #ifdef GTK
> #include <gtk/gtk.h>
> #endif
> 
> after the check for GNOME.  Could you please let me know if
> this fixes the problem.  If it does, I'll update the file
> in CVS.
> 
> Thanks
> -Jeff
> 
> > 
> > Hi,
> > Trying to compile using the SRPM Java-GTK 0.7 releae I get 
> > the following
> > compile error, any suggestions?
> > 
> > RPM build errors:
> >     Bad exit status from /var/tmp/rpm-tmp.7354 (%build)gcc -c -g -O2
> > -fPIC -Iother other/gnu_gtk_GtkCell.c -o other/gnu_gtk_GtkCell.o -I
> > /usr/java/jdk1.3.1/include -I /usr/java/jdk1.3.1/include/linux
> > -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
> > -I/usr/X11R6/include \
> >      -I/usr/include/gnome-xml -I/usr/include/gtk-1.2
> > -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include
> > -DGTK
> > In file included from other/gnu_gtk_GtkCell.c:11:
> > other/gtk_wrappers.h:15: parse error before `jobject_to_gpointer'
> > other/gtk_wrappers.h:15: warning: data definition has no type 
> > or storage
> > class
> > make[2]: *** [other/gnu_gtk_GtkCell.o] Error 1
> > make[2]: Leaving directory `/usr/src/redhat/BUILD/java-gtk-0.7/src'
> > make[1]: *** [gtk] Error 2
> > make[1]: Leaving directory `/usr/src/redhat/BUILD/java-gtk-0.7/src'
> > make: *** [distro] Error 2
> > error: Bad exit status from /var/tmp/rpm-tmp.7354 (%build)
> > 
> > 
> > RPM build errors:
> >     Bad exit status from /var/tmp/rpm-tmp.7354 (%build
> > 
> > Christian
> > 
> > 
> > _______________________________________________
> > java-gnome-developer mailing list
> > jav...@li...
> > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> >