Re: SWT and AWT

[chris burdess <dog at bluezoo dot org>]

Stanley Brown wrote:
> >as i understand it there are some insurmountable problems required to
> >implement the awt interface using swt. one of these is the fact that
> >swt
> >widgets cannot be reparented,
> >
> You are correct that you cannot directly subclass a SWT widget.  The
> AWT
> classes would have to be thin "interface" like classes that wrap the
> actual SWT control:

yes; this is the way awt works in any case, as proxies for "peers". one
would create an SWTButtonPeer that references the swt.Button.

> >and must be constructed in the context of
> >their parent (presumably "because this is the way windows does it").
> >
> Think of SWT composites as AWT containers.  You dont actually create
> an
> instance of the SWT object (swtButton above) until you "add" it to the
> AWT container.  So, the AWT Component class would probably have
> something as such:

so, when i have created the swt.Button in the context of its parent, how
do i then remove it from its parent's list of children? unless
isReparentable returns true for the widget (there is "platform support"
for the reparent operation), i can't even call setParent to add it to an
offscreen composite.

the only answer i can think of is to destroy the entire tree of swt
peers and rebuild it without the button. in a large ui, this nasty hack
becomes a serious performance problem.

frankly i think this is all a bit of a non sequitur. swt was designed as
a replacement for awt, and its design goals are different. and just
using it as a bridge doesn't resolve the licensing issues regarding
linking to mfc/cocoa.  if it's possible to resolve those issues, we
should write proper mfc and cocoa awt implementations.
--
chris burdess