|
| Re: Layout Constraints [message #1387 is a reply to message #1381] |
Tue, 28 August 2007 22:59  |
 Gordon Hirsch
Messages: 100
Registered: July 2009 |
Senior Member |
|
|
Hi Peter,
Peter Centgraf wrote:
> ...
> How would a Swing component communicate its bottom-up constraints to an
> SWT GridLayout? Clearly, it needs some help. Swing has its own
> mechanism for computing minimum, preferred, and maximum sizes. Would it
> be possible to bridge these values from the Swing component to the SWT
> min/hint API? Is it possible to make Swing's layouts respect the hints
> provided in SWT's Layout.computeSize()?
Interesting questions. I'll think out loud here a bit...
The first step is to implement computeSize() and setBounds() on the
custom SWT Composite that embeds the AWT Frame (see note below). Neither
is implemented in the code included with the article, but I have seen it
done elsewhere. In particular the upcoming ILOG contribution to Albireo
does it, and perhaps Bruno can correct me if I make any mistakes here.
computeSize would delegate to the embedded frame.
This communicates the entire embedded frame's constraints as the
constraints of a single control on the SWT side, so it should work
reasonably well if, say, the embedded Swing stuff maps to a single cell
in an SWT GridLayout. In effect, there would be a Swing layout nested in
an SWT layout.
Since the entire AWT frame is seen as a single SWT control, I can't
think of any way to have more "fine grained" participation in SWT
layouts. Of course, you might subdivide the Swing components into
multiple frames, each embedded in a different SWT Composite.
Perhaps all this is another reason to consider embedding as most
effective at the high end of a containment hierarchy rather than the low
end. Mixing individual Swing/SWT widgets is going to be more trouble
than it's worth.
How well/badly does all this address your concerns?
Note: the tricky part about implementing computeSize is that it should
hop over to the Swing thread to get size information from the embedded
frame while the SWT thread waits for the returned value. This is a
deadlock risk, and some have reported deadlocks in this actual case.
|
|
|
| Re: Layout Constraints [message #572229 is a reply to message #1381] |
Tue, 28 August 2007 22:59 |
Gordon Hirsch
Messages: 100
Registered: July 2009 |
Senior Member |
|
|
Hi Peter,
Peter Centgraf wrote:
> ...
> How would a Swing component communicate its bottom-up constraints to an
> SWT GridLayout? Clearly, it needs some help. Swing has its own
> mechanism for computing minimum, preferred, and maximum sizes. Would it
> be possible to bridge these values from the Swing component to the SWT
> min/hint API? Is it possible to make Swing's layouts respect the hints
> provided in SWT's Layout.computeSize()?
Interesting questions. I'll think out loud here a bit...
The first step is to implement computeSize() and setBounds() on the
custom SWT Composite that embeds the AWT Frame (see note below). Neither
is implemented in the code included with the article, but I have seen it
done elsewhere. In particular the upcoming ILOG contribution to Albireo
does it, and perhaps Bruno can correct me if I make any mistakes here.
computeSize would delegate to the embedded frame.
This communicates the entire embedded frame's constraints as the
constraints of a single control on the SWT side, so it should work
reasonably well if, say, the embedded Swing stuff maps to a single cell
in an SWT GridLayout. In effect, there would be a Swing layout nested in
an SWT layout.
Since the entire AWT frame is seen as a single SWT control, I can't
think of any way to have more "fine grained" participation in SWT
layouts. Of course, you might subdivide the Swing components into
multiple frames, each embedded in a different SWT Composite.
Perhaps all this is another reason to consider embedding as most
effective at the high end of a containment hierarchy rather than the low
end. Mixing individual Swing/SWT widgets is going to be more trouble
than it's worth.
How well/badly does all this address your concerns?
Note: the tricky part about implementing computeSize is that it should
hop over to the Swing thread to get size information from the embedded
frame while the SWT thread waits for the returned value. This is a
deadlock risk, and some have reported deadlocks in this actual case.
|
|
|
Powered by
FUDForum. Page generated in 0.03338 seconds
] 
Search
Help
Register
Login
Home
