This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]