Want to help integrating swing. Is already someone working on it?

Dhek Bhun Kho bhun@chello.nl
Tue Mar 4 12:12:00 GMT 2003


Hi there back!

> Hmm, i would say definitive no. 
Ok.

> SWT doesnt support Garbage-Collection
Please state the relevance of this? Is the garbage collecting in gcj
implemented as such that the finalize() method is called? This should
enable garbage collecting of the native widgets peers shouldn't it? 

> , has a terrible api (for me as a swing-programmer ;-) ), 
:D Sure, but it is one time effort and you learn a lot from it: Swing
was implemented on top of AWT, and you're not going to insist that AWT
is very friendly whatsoever. If it's impossible to implement: how did
they implement it in the first place? From what I read the Swing set
does not contain any native methods, so it should be realisable from a
java library that is interfacing to native peers. (Not saying it is
easy.. it's going to be 'moeilijk' )

> and that in general when you use native widgets you'll loose fully
> api-compytiblility.
Full API compatibility ?? I what sense? I say: implement the JComponent
first, that's all we need to get things going, surely SWT must have a
counterport to the java.awt.Container (which is the base of the
JComponent, all other Swing components are derived from JComponent and
do custom drawing in the paintComponent() paintBorder etc. methods)

> Many parts are missing, and the missing GC alone is a big problem
Is that bad? If you / we / somebody else is going to implement Swing,
they shouldn't make it heavy weight, and it's not going to be finished
in a a week.

> O.K., it would work to produce a C-Widget-Set which exactly is equal
> to swing, 
> but I think this isnt really a good idea.
C-Widget-Set?

> Thats general a problem, swing is absolutly was not designed to be
> based on native widgets.
Isn't Swing based on native peers?????? 

If you draw a JButton on screen what you are actually doing
is creating a single native peer that is the container and is 
used for all contained components. 

(I hope I get this right) When the os(?) is drawing the component, it
calls the paint method, 
then it passes the graphics object to all children in the container 
to draw in, thus it is 'light weight' and you can do the stuff like
Z-ordering as the child components are never set to visible status but
remaining somewhere in memory just containing the properties so they can
draw themselves in the (visible) context of the container instead of
their own (now invisible) context. Instead the container's graphics
object visualises the non-visible contained components. 

Indeed if you were to implement each Swing widget as real native
component you would get a tremendous life long headache. If you
implement the Swing widgets as royalty graphics routines with behaviours
expected from real native peers you get less headaches.








More information about the Java mailing list