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

Tue Jun 15 18:04:00 GMT 2004

On Jun 15, 2004, at 11:20 AM, Bryce McKinlay wrote:
> [snip] Although not having to worry about platform look & feel 
> differences may be nice for developers, its the major reasons users 
> tend to dislike Swing applications.

As a user, I gotta disagree with you there. I really like the way Swing 
looks,
it's just that it's so darn slow. GTK+ looks nice too.
I think that "look-and-feel" is a bit of a misnomer here, since, 
although Swing
does *look* different than other native widget sets, it *feels* pretty 
much like
all the rest of 'em. Menus, buttons, sliders, tabs work the same as 
everywhere
else. Of course, it also *feels* slow (not sure what the "feel" in LAF 
is actually
referring to).
> Without real native widgets, they are inconsistent at best and ugly 
> at worst.

If I'm understanding this discussion correctly, it's at least partially 
about
lightweight/peerless vs. heavyweight/peer implementation. Personally, I 
like the
idea of Classpath Swing using the GTK+ peer -- for execution speed, 
simplicity,
and I'd guess it'd be much more easily/quickly implemented.
After all, wasn't the whole point of Swing was to provide widgets that 
lowest-
common-denominator peers didn't have? Doesn't GTK+ have everything Swing
would need?
Also, didn't IBM develop SWT for the same reasons mentioned above?
>> Of course, the initial implementation of swing will likely use a 
> simple, non-native PLAF since that is likely going to be the most 
> simple to implement, however we would welcome anyone who wants to work 
> on native-toolkit PLAFs.
>
Wait. If GTK+ runs on, say, Mac OS X. And it is implemented in terms of 
Carbon
(the older Mac toolkit -- which looks "Mac-like" of course), and if 
CP's Swing
uses the GTK+ peer, that's a "native-LAF", right?
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?
Thanks.