[Java-gnome-developer] Re: [Help] CustomEvents refresh problem

[Jonas B. <jb...@ni...>]

On Thu, 11 Sep 2003 21:25:47 +0100, Mark Howard <mh...@ti...> wrote:

> Thanks. Are you developing an application with java-gnome? I've not see=
n
> you on the list before. It's great to see new people working with
> java-gnome, especially people who aren't afraid to write patches :)

Yes, I am trying to write some basic tool to receive & display data from =
a=20
java profiler a friend of mine wrote. It sends the data over UDP and I=20
then parse it & display it somehow, don't know exactly how yet.

I kindof like the gtk interface, but I think it's a bit too=20
object-oriented to be elegant to code with in pure C. Otoh, I pretty much=
=20
don't want to touch C++, so if I would have to choose, I would go with C=20
anyway. I have been coding a lot with java, but I think both awt & swing=20
sucks, both graphically and program-wise. I haven't tried SWT, but anyway=
=20
I like gtk. So this Java-gtk binding is indeed interesting, and seems=20
quite promising I think. I understand it's still not finalized and that=20
interfaces might change, but I definately want to give it a try. Although=
=20
I'm no expert on how object-oriented interfaces for GUIs should be=20
implemented, I think the current 0.8 version looks pretty much like java,=
=20
which I like.

And yep, I've not written to the list before. No problems writing patches=
=20
here. I don't have that much experience in gtk2 and glib2 however, but if=
=20
I run into a bug, I will probably gain more =3D)

> Looks good to me too. Works wonderfully. I've not checked with other
> bindings to see if it's the proper way yet, but it works well so I've
> committed to cvs.

Actually, when I looked at it again, I found that the read() call (in the=
=20
native code) should be done from within the synchronized block that=20
executes the events. I didn't actually check the java right now, but I=20
think the write() call is called from within a synchronized block already=
=20
(if it isn't, it should be too). This will add some minor overhead, but I=
=20
tend to prefer correct operation to minimal performance gain =3D)

> perhaps. I don't think any glib developers are on this list. Please try
> sending you patch to a glib list.

Well I don't have a patch for glib yet.. And I don't have that much time=20
to spend now..

BTW, I succeeded with my simple test program which receives approx 5 line=
s=20
of text every second to jam the gtk thread. I append the text received to=
=20
a TextView, and after appending text some 300-305 times, it just stops. I=
=20
investigated a bit into this, and it seemed that the java native code=20
handling signals was receiving an internal event sent by the TextView to=20
its TextBuffer to perform the insertion of the text. And after this=20
300-305 times it jammed in the java native handler while trying to=20
allocate memory for the string argument. It always jammed after around=20
300-305 times. I didn't invent any good fix for this as I really didn't=20
know what was to blame.. I could write a simpler program for this to=20
illustrate how to reproduce the problem. I also succeeded in attaching=20
with gdb to the java thread that was jamming, and got a 45-line backtrace=
.=20
I don't have it now, but I can try to get it when I get to making this=20
simple bug-reproducing program.

Anyway, the TextView was just a test arena for showing the incoming data,=
=20
so it's not a showstopper for me. I just hope the problem won't pop up=20
with other components :)

BTW, what's your role in java-gnome? Are you a main developer or?

--=20
:::  Jonas Berlin   :::  +358-40-5884454  :::
:::                                       :::
:::  http://xkr47.outerspace.dyndns.org/  :::