[albireo-dev] Initial Check-in

[Gordon Hirsch <gordon.hirsch@xxxxxxx>]

As we discussed, I've created and checked in some initial code 
(org.eclipse.albireo.core) to handle building the proper Swing 
containment hierarchy. I started with the SAS contribution and stripped 
out most of the code, leaving the basic containment hierarchy and a few 
other minor features.

This means the checked in code does *not* do:

* Focus handling/Keyboard navigation
* Swing modal dialog handling
* Propagation of SWT size, color, fonts to embedded Swing components
* Any sort of flicker reduction (aside from sun.awt.noerasebackground)
* probably a lot of other things :-).

Unfortunately, my Linux box is temporarily unavailable, so this code has 
been tried only under Windows.

org.eclipse.albireo.core is a plug-in project that when built as a jar 
should be usable from standalone applications (just like SWT).

I also checked in separate CVS example projects that use this new code. 
org.eclipse.albireo.examples is a regular java project that contains a 
standalone example application. org.eclipse.albireo.examples.plugin is a 
simple RCP application/plug-in that has a simple example view that 
embeds a swing control. We'll add to these examples over time, of course.

Some notes on the main code:

* I used the name "SwingControl", not EmbeddedSwingComposite

* As in the SAS contribution, there is a separate AwtEnvironment class 
that can be used (eventually) for RCP/SWT applications that launch Swing 
dialogs without embedding Swing controls. At the moment it may seem 
pointless, but it will have value as we continue.

* As in the SAS contribution, to use SwingControl, you must construct it 
and then call the populate() method. The Swing components are not 
created until populate() is called. This may seem like a pain, but there 
are two advantages:

1) if we want to add methods to configure SwingControl, they can be 
called before all of the Swing components are created (after the 
constructor and before populate()).

2) we don't do as much work in the constructor. If there is a lot of 
code in the constructor, there's a danger of passing around a partially 
initialized SwingControl. I think it is a good idea to avoid this.

* Unlike the SAS contribution, there is no ability to repopulate the 
control by calling populate() a second time. This caused more complexity 
than it was worth in my initial implementation. In contrast, the ILOG 
contribution has a setSwingComponent() method. I've left that method out 
for now too. If we need the ability to change the embedded Swing 
component, the ILOG approach is better, but it would be easier if we 
don't allow it at all. Thoughts?

All three of these new projects are under 
/cvsroot/technology/org.eclipse.albireo