GTK+ peer for Swing. -WAS- Re: Making shared objects with GCJ

Mon Jun 21 06:40:00 GMT 2004

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?