This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
GTK+ peer for Swing. -WAS- Re: Making shared objects with GCJ
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.