| Layout Constraints [message #1381] |
Tue, 28 August 2007 12:16  |
Eclipse User |
|
|
|
Hi all,
Layout issues were not really mentioned in the article, and I wonder if
there are any unique problems when mixing SWT and Swing layout
algorithms in the same Shell.
Here's the motivating problem: I have found that I often want a mix of
top-down constraints (e.g. fit everything within my Shell) and bottom-up
constraints (e.g. this Text should be at least 50 pixels wide). The
minimum/hint mechanism in SWT's GridLayout and the layouts in the
Eclipse Forms package let me gracefully fall back on scrolling when the
bottom-up constraints cannot be satisfied, while still making a "best
effort" to adjust to the bounds of the Shell when that is possible.
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()?
I don't have answers to these issues, but I'm curious to hear your ideas.
--
Peter Centgraf
Eclipse Nebula Committer
RJ Lee Group, Inc.
|
|
|
| Re: Layout Constraints [message #1387 is a reply to message #1381] |
Tue, 28 August 2007 18:59  |
| Eclipse User |
|
|
|
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 18:59 |
| Eclipse User |
|
|
|
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.05437 seconds
Home