The Swing/AWT API over SWT library
A. Yes, I'm afraid so. I no longer need it. Hopefully it's still useful to someone.
A. Yes and No. Yes, technically it can be done, but it requires deployment to
jre/lib/endorsed for javax.* packages (making it tougher to deploy apps).
Other disadvantages are that the default Sun classloader will refuse to load
anything starting with java.* (so you need to override the classloader),
and the big worry that classes might get merged from the real AWT/Swing.
You can also use various Java pre-processors or Ant to change your code
at build time for you.
If you are using a free virtual machine (such as Kaffe, SableVM, GIJ or
IKVM), the SwingWT build script allows you to build it with
java.awt/javax.swing packages by specifying "ant -Dsun=no" at build time.
You can then use the -bootclasspath parameter to load SwingWT prior to your
VM's class libraries to have it override any existing AWT/Swing
implementation.
If you are a Win32 developer, the ThisIsCool MingW GCJ project supplies you a complete GCJ
toolchain for Windows using SwingWT as the AWT/Swing implementation - just
compile your code with that and go!
SwingWT now includes a classloader (borrowed from the WebOnSwing project
at http://webonswing.sf.net
) which will dynamically switch Swing for
SwingWT on existing programs. See the swingwtbootstrap and
linux_replaceswing_runswingdemo.sh scripts in the bin directory for a
working example with a swing demo that uses SwingWT at runtime.
A. I have to admit to not being enough of an expert to know if this is possible
for sure. As long as you can abstract away the rendering of a component as
part of an L&F (which I assume you can), then yes, it's possible.
The reason I didn't even consider it is that I wanted this for building apps
with GCJ (which lacks a complete Swing implementation) - I therefore had to
assume that I had nothing and was basically reimplementing Swing from
scratch.
This does have the other rather nice side-effect that SWT is currently making
waves in the mobile device world, and using SwingWT means you can port your
Swing apps to mobile devices easily!
A. Yes you can - although SwingWT closely resembles the Swing/AWT APIs, you can
access the SWT widgets with a call to getSWTPeer() for any component and
getComposite() for any container. This works two ways, and you can wrap
up an existing SWT widget with a SwingWT one.
To add a SwingWT container (eg: JPanel) to an SWT container, simply
create the SWT container, then create a new swingwt.awt.Container object
and assign the SWT container to it. You can then treat it like any
other Swing container. Eg:
// If this is an Eclipse plugin, tell SwingWT to use the // already existing SWT event dispatcher instead of creating // it's own: SwingWTUtils.setEclipsePlugin(true); // Create a new SWT shell to use as a container // ------- Shell shell = new Shell(); shell.setLayout(new org.eclipse.swt.layout.FillLayout()); // Map it to a SwingWT container so we can use our Swing-like // components with it // ------- swingwt.awt.Container container = new swingwt.awt.Container(); container.composite = shell; // Add components to it as normal // ------- container.add()
A. The SWT browser kit requires the following:
A. Yes (from v0.77), as long as you have the source for the layout manager you want to use and you can change the java.awt imports to swingwt.awt and recompile it.
A. Before you do anything with SwingWT in your code, do: swingwtx.swing.SwingWTUtils.setShowSwingWTInfoOnStartup(false) to turn it off.
A. That's great! However please don't do the following:
A Makefile for GCJ is supplied in the root folder of the SwingWT
distribution. Note that you will need the "unzip" and GNU find
utilities (and of course GCJ) for it to work.
Win32 users can either use Cygwin
to run a modified version of the Linux
build script with MingW, or use the MingW build at
ThisIsCool for a
pre-built SwingWT/SWT.
A. I assume you are talking about the CPL. With SWT:
That's good enough for me. SwingWT is LGPLd so it's super-free :-)
A. The Java threading model is fundamentally broken in MacOSX and it requires
the SWT event loop to run on the main thread (SwingWT spawns a new dispatch
thread on other platforms).
You can get around this by:
public static void main(String[] args) {
if (SwingWTUtils.isMacOSX()) {
SwingWTUtils.initialiseMacOSX(new Runnable() {
public void run() {
runMyStartupCode();
}
});
}
else
runMyStartupCode();
}
Copyright(c)2003-2012, R. Rawson-Tetley