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

[S. Meslin-Weber]

> Thanks for the informative repyl Steph.

My pleasure entirely!

> It sounds like pefecting the GTK+ peer is a long thorny road to go down.

Writing peers in general is like that, in fact writing any native code
for use with Java ends up being difficult.

> 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?

In a way, this is the way Kaffe's unpeered AWT works. Take qtawt for
Kaffe for instance, it has hooks into Qt for toplevel windows, events
and image handling (plus a few miscellaneous items); everything else is
'lightweight' and draws into those toplevel windows. Problem is that you
automatically lose the native look unless you emulate it.

I believe that doing this with Swing && GTK+ is possible and I'm almost
certain it's been suggested on the GNU Classpath mailing list. I don't
know nearly enough about Swing internals to say wether it would be
easier than the current approach.

We'd also have to consider performance. In the end we have to evaluate
the ease of implementation against the implementation performance; doing
all the drawing in Java code could be one of the reasons Swing is
perceived to be slow. Additionally, I don't know what our resource pool
is but I'd be willing to bet that we have more GTK+/native developers
than Swing/Java developers available for the job.

Steph

P.S. obvious plug: I work on a set of AWT peers[1] (GPL'd) and I chose
     to implement all the peers rather than just the toplevel ones. To
		 me it seemed a more elegant way of doing things[2].

[1] Odonata peers for Java AWT, http://odonata.tangency.co.uk
[2] I'm always willing to reconsider though :)