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

[John Gabriele]

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?