This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: GTK+ peer for Swing. -WAS- Re: Making shared objects with GCJ
On Jun 20, 2004, at 5:15 PM, S. Meslin-Weber wrote:
Hi John,
Also, one last question: Does "GTK+ peer" just mean wrapping GTK+
calls
with Java code using something like JNI/CNI? Or is it more complicated
than
that?
Unfortunately writing peers is more complicated than that. What you
describe is usually referred to as a binding, where you have an almost
1-to-1 relationship between your native widget set and Java. These are
typically easier to write than peers as there are few legacy issues
with
old applications.
Peers are more of a many-to-many type of binding, a translation of your
native widget set to Java so that existing Java applications use
these new peers transparently and usually without needing code changes.
The transparency is the point where the difficulties come in; you need
to make your peers as compatible as others (bugs and all) otherwise
you'll find some badly behaved application won't work because it
depends
on those bugs. In short, writing peers is a headache for all concerned
and don't get me started on the pain that JNI adds to this :)
Cheers,
Steph
Thanks for the informative repyl Steph.
It sounds like pefecting the GTK+ peer is a long thorny road to go down.
How does the alternative approach work? That is, instead of using GTK+
widgets, do you just use GTK+ to open up an empty window and then use
GCJ's/CP's Swing implementation to draw everything?