Skip to main content

Baseline API in mustang

28 replies [Last post]
Anonymous

Folks,

I've been working on adding baseline related API to AWT/Swing and
wanted to open the discussion up to the community. This API is
primarily useful to folks writing layout managers that want to align
components along their baseline. The API solves two problems:

Ability to get the baseline for any size.
Ability to determine how the baseline will change with size.

The API is primarily useful to folks writing layout managers. Here's
what the current API looks like (on Component):

<br />
     /**<br />
      * Enumeration of the possible ways the baseline of a component<br />
      * can change as the size changes.  The constants are typically<br />
      * only meaningful for sizes larger than the preferred size.<br />
      *<br />
      * @see #getBaselineResizeBehavior<br />
      * @see #getBaseline(int,int)<br />
      * @since 1.6<br />
      */<br />
     public enum BaselineResizeBehavior {<br />
         /**<br />
          * As the size of the component changes, the baseline remains<br />
          * fixed relative to the y-origin.  That is,<br />
          * getBaseline will return the same value<br />
          * regardless of the height.  For example, a<br />
          * JLabel containing non-empty text with a<br />
          * vertical alignment of TOP should have a<br />
          * baseline resize behavior of CONSTANT_ASCENT.<br />
          */<br />
         CONSTANT_ASCENT,<br />
         /**<br />
          * As the size of the component changes, the baseline remains<br />
          * fixed relative to the height.  That is, for any height X<br />
          * the difference between X and getBaseline(X) is<br />
          * the same.  For example, a JLabel containing<br />
          * non-empty text with a vertical alignment of<br />
          * BOTTOM should have a baseline resize behavior<br />
          * of CONSTANT_DESCENT.<br />
          */<br />
         CONSTANT_DESCENT,<br />
         /**<br />
          * As the size of the component changes, the baseline changes<br />
          * in a non-deterministic way, or is unknown.<br />
          */<br />
         OTHER,<br />
     }</p>
<p>     /**<br />
      * Returns the baseline.  The baseline is measured from the top of<br />
      * the component.  This method is primarily meant for<br />
      * LayoutManagers to align on the baseline.  A return<br />
      * value less than 0 indicates this component does not have a<br />
      * reasonable baseline and that LayoutManagers should<br />
      * not align this component on its baseline.<br />
      *<br />
      * The default implementation returns -1, subclasses that support<br />
      * baseline should override appropriately.<br />
      *<br />
      * @param width the width to get the baseline for<br />
      * @param height the height to get the baseline for<br />
      * @return the baseline or < 0 indicating there is no reasonable<br />
baseline<br />
      * @throws IllegalArgumentException if width or height is < 0<br />
      * @see #getBaselineResizeBehavior<br />
      * @see java.awt.FontMetrics<br />
      * @since 1.6<br />
      */<br />
     public int getBaseline(int width, int height);</p>
<p>     /**<br />
      * Returns an enum indicating how the baseline changes as the<br />
      * component size changes.  This method is primarily meant for<br />
      * layout managers and GUI builders.<br />
      *<br />
      * The default implementation returns<br />
      * BaselineResizeBehavior.OTHER, subclasses that<br />
      * support baseline should override appropriately.<br />
      * Subclasses should never override to return null; if the<br />
      * baseline can not be calculated return<br />
      * BaselineResizeBehavior.OTHER.<br />
      *<br />
      * @return an enum indicating how the baseline changes as the<br />
component is<br />
      *         resized<br />
      * @see #getBaseline(int, int)<br />
      * @see java.awt.FontMetrics<br />
      * @since 1.6<br />
      */<br />
     public BaselineResizeBehavior getBaselineResizeBehavior();<br />

JComponent will override these methods and forward them to the
ComponentUI. Here's the list of classes that will* support this API:
slider, spinner, panel (only when it has a titled border), button,
combobox, label, list (first row), progressbar, scrollpane (delegates
to the viewport view), slider, spinner, tabbedpane, table (first row),
textarea (first row), textfield and tree (first row).
Textpane/Editorpane generally display styled text, so that if we did
implement a baseline for it it would vary depending upon context,
which did not seem like a good idea.

* I've used will in that it' still possible for the list of components
not to have a baseline. For example, a progress bar will only support a
text if it's showing text. Similarly a label will only have a baseline
if it's got text.

I've also extended GridBagLayout and FlowLayout to offer up baseline
layout.

One thing to consider with this API is that a label/button with an
alignment of center would have a baseline resize behavior of
OTHER. This is because label/button will center the center of
the text, so that the baseline (as expressed as a ratio) varies with
height. This means that if a layout manager wanted to allow
vertically aligned labels/buttons to vertically resize it wouldn't
know how to determine what the baseline would be ahead of time. In
general I don't think that's a problem as most users don't expect
their labels/buttons to grow, but it's worth pointing out.

Thoughts?

-Scott

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Scott Violet

swing-feedback@javadesktop.org wrote:
>>It's certainly possible to have getBaseline delegate to
>>the layout manager (with the addition of an interface like
>>LayoutManager3). My rationale for not going this route is
>>that computing a baseline for commonly used layout
>>managers is not clear. For some layout managers
>>it's a bit clearer, like FlowLayout or BoxLayout. But for
>>other commonly used ones, like GridBagLayout it's
>>trickier. Should it be the first row? Last row?
>>What do folks think?
>
>
> I think a container's baseline should be the topmost baseline of any
> component in the container.

I think this depends upon where you want to position components relative
to the container. For example, if you want to position a component
close to the top of the container, than what you are suggesting makes
sense. On the other hand if you want to position a component close to
the bottom than getting the baseline for the last row (assuming a grid
like structure) makes the most sense.

> This seems like a natural choice to me because there is no bottom-up
> component orientation (AFAIK).
> (Assuming, of course, that the container gets its preferred size,
> because the baseline will be queried before the container's children are
> layed out. OTOH the vertical position of the topmost components in a
> layout will rarely change when the container is resized).
>
>
>>I would need to add a LayoutManager3 to solve this. What
>>do others think?
>
> Thomas? Any others?
>
>
> BTW: Have you already decided how to make use the baseline in
> GridBagLayout? Additional anchor values? A general 'honor baseline' setting?

New set of anchor values. Here's the current proposal.
GridBagConstraints will get:

[code]
/**
* Possible value for the anchor field. Specifies
* that the component should be horizontally centered and
* vertically aligned along the baseline of the prevailing row.
* If the component does not have a baseline it will be vertically
* centered.
*
* @since 1.6
*/
public static final int BASELINE = 0x100;

/**
* Possible value for the anchor field. Specifies
* that the component should be horizontally placed along the
* leading edge. For components with a left-to-right orientation,
* the leading edge is the left edge. Vertically the component is
* aligned along the baseline of the prevailing row. If the
* component does not have a baseline it will be vertically
* centered.
*
* @since 1.6
*/
public static final int BASELINE_LEADING = 0x200;

/**
* Possible value for the anchor field. Specifies
* that the component should be horizontally placed along the
* trailing edge. For components with a left-to-right
* orientation, the trailing edge is the right edge. Vertically
* the component is aligned along the baseline of the prevailing
* row. If the component does not have a baseline it will be
* vertically centered.
*
* @since 1.6
*/
public static final int BASELINE_TRAILING = 0x300;

/**
* Possible value for the anchor field. Specifies
* that the component should be horizontally centered. Vertically
* the component is positioned so that its bottom edge touches
* the baseline of the starting row. If the starting row does not
* have a baseline it will be vertically centered.
*
* @since 1.6
*/
public static final int ABOVE_BASELINE = 0x400;

/**
* Possible value for the anchor field. Specifies
* that the component should be horizontally placed along the
* leading edge. For components with a left-to-right orientation,
* the leading edge is the left edge. Vertically the component is
* positioned so that its bottom edge touches the baseline of the
* starting row. If the starting row does not have a baseline it
* will be vertically centered.
*
* @since 1.6
*/
public static final int ABOVE_BASELINE_LEADING = 0x500;

/**
* Possible value for the anchor field. Specifies
* that the component should be horizontally placed along the
* trailing edge. For components with a left-to-right
* orientation, the trailing edge is the right edge. Vertically
* the component is positioned so that its bottom edge touches
* the baseline of the starting row. If the starting row does not
* have a baseline it will be vertically centered.
*
* @since 1.6
*/
public static final int ABOVE_BASELINE_TRAILING = 0x600;

/**
* Possible value for the anchor field. Specifies
* that the component should be horizontally centered. Vertically
* the component is positioned so that its top edge touches the
* baseline of the starting row. If the starting row does not
* have a baseline it will be vertically centered.
*
* @since 1.6
*/
public static final int BELOW_BASELINE = 0x700;

/**
* Possible value for the anchor field. Specifies
* that the component should be horizontally placed along the
* leading edge. For components with a left-to-right orientation,
* the leading edge is the left edge. Vertically the component is
* positioned so that its top edge touches the baseline of the
* starting row. If the starting row does not have a baseline it
* will be vertically centered.
*
* @since 1.6
*/
public static final int BELOW_BASELINE_LEADING = 0x800;

/**
* Possible value for the anchor field. Specifies
* that the component should be horizontally placed along the
* trailing edge. For components with a left-to-right
* orientation, the trailing edge is the right edge. Vertically
* the component is positioned so that its top edge touches the
* baseline of the starting row. If the starting row does not
* have a baseline it will be vertically centered.
*
* @since 1.6
*/
public static final int BELOW_BASELINE_TRAILING = 0x900;
[/code]

And GridBagLayout will get doc something like:
[code]
* Each row may have a baseline; the baseline is determined by the
* components in that row that have a valid baseline and are aligned
* along the baseline (the component's anchor value is one of {@code
* BASELINE}, {@code BASELINE_LEADING} or {@code BASELINE_TRAILING}).
* If none of the components in the row has a valid baseline, the row
* does not have a baseline.
*

* If a component spans rows it is aligned either to the baseline of
* the start row (if the baseline-resize behavior is {@code
* CONSTANT_ASCENT}) or the end row (if the baseline-resize behavior
* is {@code CONSTANT_DESCENT}). The row that the component is
* aligned to is called the prevailing row.
*

* The following figure shows a baseline layout and includes a
* component that spans rows:
*


*
*

*

* * alt="The following text describes this graphic (Figure 1)."
ALIGN=center>
*


* This layout consists of three components:
*
  • A panel that starts in row 0 and ends in row 1. The panel
    * has a baseline-resize behavior of CONSTANT_DESCENT
    and has
    * an anchor of BASELINE. As the baseline-resize behavior
    * is CONSTANT_DESCENT the prevailing row for the panel is
    * row 1.
    *
  • Two buttons, each with a baseline-resize behavior of
    * CENTER_OFFSET and an anchor of BASELINE.
    *

* Because the second button and the panel share the same prevailing row,
* they are both aligned along their baseline.
*

* Components positioned using one of the baseline-relative values resize
* differently than when positioned using an absolute or
orientation-relative
* value. How components change is dictated by how the baseline of the
* prevailing row changes. The baseline is anchored to the
* bottom of the display area if any components with the same
prevailing row
* have a baseline-resize behavior of CONSTANT_DESCENT,
* otherwise the baseline is anchored to the top of the display area.
* The following rules dictate the resize behavior:
*

    *
  • Resizable components positioned above the baseline can only
    * grow as tall as the baseline. For example, if the baseline is at 100
    * and anchored at the top, a resizable component positioned above the
    * baseline can never grow more than 100 units.
    *
  • Similarly, resizable components positioned below the baseline can
    * only grow as high as the difference between the display height and the
    * baseline.
    *
  • Resizable components positioned on the baseline with a
    * baseline-resize behavior of OTHER are only resized if
    * the baseline at the resized size fits within the display area. If
    * the baseline is such that it does not fit within the display area
    * the component is not resized.
    *
  • Components positioned on the baseline that do not have a
    * baseline-resize behavior of OTHER
    * can only grow as tall as {@code display height - baseline + baseline
    of component}.
    *

* If you position a component along the baseline, but the
* component does not have a valid baseline, it will be vertically centered
* in its space. Similarly if you have positioned a component relative
* to the baseline and none of the components in the row have a valid
* baseline the component is vertically centered.

[/code]

-Scott

skelvin
Offline
Joined: 2003-06-11
Points: 0

>> I think a container's baseline should be the topmost baseline of any
>> component in the container.

> I think this depends upon where you want to position components relative
> to the container. For example, if you want to position a component
> close to the top of the container, than what you are suggesting makes
> sense. On the other hand if you want to position a component close to
> the bottom than getting the baseline for the last row (assuming a grid
> like structure) makes the most sense.

Let me se if I understood you correctly: In some cases the layout manager does not position the components so that they fill the container, but rather anchors the whole set of components somewhere. E.g. in a GridBagLayout where no row has any weight, the set of components will be vertically centered. (I think one cannot change this grid alignment?)
I think that's a rather pathological case and the layout should not report any baseline if it has multiple rows or else report the baseline of its single row.
In the more common case that the set of components is aligned at the bottom edge, it should report the baseline of the last row.

> New set of anchor values. Here's the current proposal.
> ...
Oh my, that are quite a number of options - and no chance to use enums unfortunately.

And still I think it's too inflexible, or maybe I just didn't get it.
Is the baseline always anchored relative to the top of its row? Can't I have it at the bottom (if the row expands vertically, but no component has fill style)?

I like the "above" and "below" options, though.

> the baseline is determined by the
> * components in that row that have a valid baseline and are aligned
> * along the baseline

How is it determined if multiple components in that row have different baselines?

Scott Violet

Stephen,

swing-feedback@javadesktop.org wrote:
>>>I think a container's baseline should be the topmost baseline of any
>>>component in the container.
>
>
>>I think this depends upon where you want to position components relative
>>to the container. For example, if you want to position a component
>>close to the top of the container, than what you are suggesting makes
>>sense. On the other hand if you want to position a component close to
>>the bottom than getting the baseline for the last row (assuming a grid
>>like structure) makes the most sense.
>
>
> Let me se if I understood you correctly: In some cases the layout
> manager does not position the components so that they fill the
> container, but rather anchors the whole set of components somewhere.
> E.g. in a GridBagLayout where no row has any weight, the set of
> components will be vertically centered. (I think one cannot change this
> grid alignment?)

Yes, if all components have a weighty of 0 then GridBagLayout will
center vertically center components.

> I think that's a rather pathological case and the layout should not
> report any baseline if it has multiple rows or else report the baseline
> of its single row.
> In the more common case that the set of components is aligned at the
> bottom edge, it should report the baseline of the last row.

My point is that you may want the baseline for the first row, and you
may want the baseline for the last row. It really depends upon how the
external widget is being positioned relative to the container.

>>New set of anchor values. Here's the current proposal.
>>...
>
> Oh my, that are quite a number of options - and no chance to use enums unfortunately.
>
> And still I think it's too inflexible, or maybe I just didn't get it.

Could you specifically say what's too inflexible about the changes to GBL?

> Is the baseline always anchored relative to the top of its row? Can't I
> have it at the bottom (if the row expands vertically, but no component
> has fill style)?

How the baseline is anchored depends upon the baseline resize behavior
of the components in the row. If all components have a baseline resize
behavior of CONSTANT_ASCENT, then the baseline is anchored to the top,
otherwise it's anchored to the bottom.
I've gone with having the baseline determined by the components. It's
conceivable to want the ability to specify a resize behavior for the
baseline and have the components placed around that. This didn't fit
well with GridBagLayout though. That's not to say we can't add it, but
rather I wanted to wait for customers to ask for it first;)

> I like the "above" and "below" options, though.
>
>
>>the baseline is determined by the
>> * components in that row that have a valid baseline and are aligned
>> * along the baseline
>
>
> How is it determined if multiple components in that row have different baselines?

For each row iterate through the components doing something like:

maxBaseline=Math.max(maxBaseline, componentBaseline);
maxDescent=Math.max(maxDescent, componentHeight-maxBaseline);

The baseline for the row is maxBaseline. That's assuming the row
doesn't get more space than requested.

-Scott

skelvin
Offline
Joined: 2003-06-11
Points: 0

> My point is that you may want the baseline for the first row, and you
> may want the baseline for the last row. It really depends upon how the
> external widget is being positioned relative to the container.
Sorry. You lost me. Which external widget?
To recap my proposal:
If there is a single row of components, then use that row's baseline.
If there are multiple rows: If the set of components are anchored at the container's top edge, then use the baseline of the first row.
Else if the set components are anchored at the container's bottom edge, then use the baseline of the last row.
Else the baseline is undefined.

> Could you specifically say what's too inflexible about the changes to GBL?
I was talking about the ability to specifically position the baseline (at top, centered, bottom). I guess it's enough to have the baseline position be determined by the ascent type, like you described, though.

IMHO much of the complexity of GridBagLayout comes from the fact that there is a single anchor value instead of two separate anchor values for horizontal and vertical position. While it might in theory adapt better to component orientation it leads to an exponential growth of possible anchor values.

Scott Violet

swing-feedback@javadesktop.org wrote:
>>My point is that you may want the baseline for the first row, and you
>>may want the baseline for the last row. It really depends upon how the
>>external widget is being positioned relative to the container.
>
> Sorry. You lost me. Which external widget?

Consider the following crude ascii art:
[code]
l1|-----------|
| |
| |
l2|-----------|
[/code]
Where the box represents a container that is being layed out with
GridBagLayout. If the baseline is at the top, then l1 can be aligned
with the baseline, were as if the baseline is at the bottom then l2 can
be aligned with the baseline. It's conceivable where the baseline, for
GBL, should be user configurable. That is, you can have the baseline
correspond to the first row or the last row.

> To recap my proposal:
> If there is a single row of components, then use that row's baseline.
> If there are multiple rows: If the set of components are anchored at the
> container's top edge, then use the baseline of the first row.
> Else if the set components are anchored at the container's bottom edge,
> then use the baseline of the last row.
> Else the baseline is undefined.

>>Could you specifically say what's too inflexible about the changes to GBL?
>
> I was talking about the ability to specifically position the baseline
> (at top, centered, bottom). I guess it's enough to have the baseline
> position be determined by the ascent type, like you described, though.

Ok.

> IMHO much of the complexity of GridBagLayout comes from the fact that
> there is a single anchor value instead of two separate anchor values for
> horizontal and vertical position. While it might in theory adapt better
> to component orientation it leads to an exponential growth of possible
> anchor values.

Good point.
Additionally I think a lot of the complexity (primarily unreadability)
comes from having to specify the constraints for each cell. Many
typical layouts only have a couple of distinct constraints (not
including gridx/gridy) so that if there were an easy way to configure
these, then add all the components it would help readability. I believe
this is the approach taken with Karsten's builders for hist forms layout.

-Scott

skelvin
Offline
Joined: 2003-06-11
Points: 0

> Consider the following crude ascii art:
> ...
I see the point, though I think if the layout always positions a component at the top, then that component should determine the baseline. Only in this case (which isn't possible with GridBagLayout) should it be the last row:
[code]l1|-----------|
| | |
| | |
| |comp1 |
| |comp2 |
l2|-----------|[/code]

In general the conflict is
- if a container cannot determine a baseline, then the whole baseline feature is substantially less useful.
However the introduction of 'container baseline concept'
- requires the burden of introducing a new interface to the JDK
- leaves intricate choices for specific layout managers/configurations

All in all I would still prefer to have the container base line feature.
I see the problems though and personally I can always implement the concept privately in my own layout managers (we use those exclusively here at work).

> Additionally I think a lot of the complexity (primarily unreadability)
> comes from having to specify the constraints for each cell. Many ...
The GridBagLayout is too complicated in a couple ways. I don't really envy you for your task of adding the baseline feature to it ;-)

Slightly off topic:
I remember reading something about a new possibility in Mustang to query preferred gaps between components? Can you point me in the right direction?

Scott Violet

Hi Stephen,

swing-feedback@javadesktop.org wrote:
>>Consider the following crude ascii art:
>>...
>
> I see the point, though I think if the layout always positions a
> component at the top, then that component should determine the baseline.
> Only in this case (which isn't possible with GridBagLayout) should it be
> the last row:
> [code]l1|-----------|
> | | |
> | | |
> | |comp1 |
> | |comp2 |
> l2|-----------|[/code]
>
> In general the conflict is
> - if a container cannot determine a baseline, then the whole baseline
> feature is substantially less useful.

I definitely see your point, but I'm not so convinced that it's
'substantially' less useful. I think future layout managers will try
and avoid nesting that is so common today. Don't get me wrong, nesting
is still needed, but I hope to avoid the nesting that is required for
using BoxLayout and others.

> However the introduction of 'container baseline concept'
> - requires the burden of introducing a new interface to the JDK
> - leaves intricate choices for specific layout managers/configurations
>
> All in all I would still prefer to have the container base line feature.
> I see the problems though and personally I can always implement the
> concept privately in my own layout managers (we use those exclusively
> here at work).

Thanks for the feedback. I'm seriously mulling over adding
LayoutManager3. I think the initial work will not include it, and I may
add it after that. I'll blog again once the API is in a promoted build
and you can then harp on me again to add it;)

>>Additionally I think a lot of the complexity (primarily unreadability)
>>comes from having to specify the constraints for each cell. Many ...
>
> The GridBagLayout is too complicated in a couple ways. I don't really
> envy you for your task of adding the baseline feature to it ;-)
>
>
> Slightly off topic:
> I remember reading something about a new possibility in Mustang to query
> preferred gaps between components? Can you point me in the right direction?

I'm working on that too (and 10 other things!). I'll send around that
API in the next couple of weeks for comments.

-Scott

Scott Violet

Stephen,

swing-feedback@javadesktop.org wrote:
> That looks very promising and I'll integrate it into my layouts
> (xlayouts java.net project) as soon as it is available.
>
> I see an issue though:
> You often use nested panels to help in layout, e.g. a group of buttons
> in a panel with grid layout (to give all buttons the same width).
> Now if you want to 'baseline align' this panel with a label in a parent
> container, how do you do that?

Yes, this API does not address the ability for containers to express a
baseline.
It's certainly possible to have getBaseline delegate to the layout
manager (with the addition of an interface like LayoutManager3). My
rationale for not going this route is that computing a baseline for
commonly used layout managers is not clear. For some layout managers
it's a bit clearer, like FlowLayout or BoxLayout. But for other commonly
used ones, like GridBagLayout it's trickier. Should it be the first
row? Last row?
What do folks think?

> [pre]--------------------------------
> | --------------------- |
> | label | button button button| |
> | --------------------- |
> --------------------------------[/pre]
> The quintessence is that a layout manager should also have a say in
> determining the baseline.
> How about this: Component delegates to UI, if the UI is indeterminate
> (e.g. a JPanel itself does not have any notion of a base line),

Actually, a JPanel with a TitledBorder will have a baseline from the border.

> it
> delegates to the component's layout manager.
> The GridLayout in this case could report the common base line of all its
> contained buttons.

I would need to add a LayoutManager3 to solve this. What do others think?

> P.S. There currently is a similar problem in trying to make use of a
> layout managers minimum/maximum size calculations: The UI for JPanel
> delegates getMinimum/MaximumSize() to getPreferredSize(), so that the
> minimum/maximum sizes from the layout manager are always ignored.

BasicPanelUI.getPreferredSize will return null, which will result in the
getMaximumSize going to the layout manager.

-Scott

skelvin
Offline
Joined: 2003-06-11
Points: 0

> It's certainly possible to have getBaseline delegate to
> the layout manager (with the addition of an interface like
> LayoutManager3). My rationale for not going this route is
> that computing a baseline for commonly used layout
> managers is not clear. For some layout managers
> it's a bit clearer, like FlowLayout or BoxLayout. But for
> other commonly used ones, like GridBagLayout it's
> trickier. Should it be the first row? Last row?
> What do folks think?

I think a container's baseline should be the topmost baseline of any component in the container.
This seems like a natural choice to me because there is no bottom-up component orientation (AFAIK).
(Assuming, of course, that the container gets its preferred size, because the baseline will be queried before the container's children are layed out. OTOH the vertical position of the topmost components in a layout will rarely change when the container is resized).

>I would need to add a LayoutManager3 to solve this. What
> do others think?
Thomas? Any others?

BTW: Have you already decided how to make use the baseline in GridBagLayout? Additional anchor values? A general 'honor baseline' setting?

zander
Offline
Joined: 2003-06-13
Points: 0

> I think a container's baseline should be the topmost
> baseline of any component in the container.
...
> >I would need to add a LayoutManager3 to solve this. What
> > do others think?
> Thomas? Any others?

I certainly agree with this; just like a text area should show only the baseline of the first line, so should a set of widgets.

Or the other way around;
suppose I place a label next to a textfield. The label has quite a big font and I use baseline layouting.
The layout of these is pretty simple if both are in the same layout manager. I would say that if the textfield was somehow grouped in a panel with a layout manager then that should not change anything about the baseline layout between these two objects. They should still look the same even though many more components were used.

This can only be accomplished by asking the panel its baseline which it then redirects to the layout manager, which redirects it to the textfield.

Note that this probably makes hacks in the scrollpane unneeded; as long as that layout manager will support LayoutManager3

karsten
Offline
Joined: 2003-06-11
Points: 0

Hi,

It seems to me, that the API Scott suggested, covers technically
what is necessary to do a baseline oriented layout: where's the
baseline for a given size, and where will it go during a resize.

But I hesitate to confirm that this API is what we need.
Before I published the API of the JGoodies FormLayout
I listened to developers in my layout courses, and tried
to understand what they can use and if the Layout Manager
features can be "driven" by a typical desktop developer.

If the new baseline API is intended to be used by visual builder
tools and even non-visual builders, it'll likely be OK.
If on the other hand, developers will need to understand
how to work with more complex cell constraints, that may fail.

Before I can request API additions, I'd need to experiment
with the new API in the FormLayout and with some developers,
and re-implement a whole bunch of screens.

This whole discussion indicates to me that we all are
just beginning to understand, how we'd like to use the
baseline information. It's not that a couple of layout
manager providers just ask the Swing team to put into
the core, what we've been asking for for a long time.
That's even more true for the baseline alignment with
nested layouts and the consideration to add LayoutManager3.

Regarding the LayoutManager3, I'd like to discuss how
developers can achieve good screen design in Java.
In contrast, I don't ask how I can use baseline information
for nested layouts, if this technique is questionable at all.

My personal preference for Mustang is to get significantly
harmonized component bounds in the Java L&f and Windows L&f,
as well as consistent baseline positions - regardless of
the information where they are. As said to Scott before,
if the component minimum and preferred sizes differ much,
and if the baselines are inconsistent, the new API won't
help. The contrary may be the case: using the baseline
information with inconsistent bounds and baseline positions
will likely end in even worse screens.

Only Werner Randelshofer of the Quaqua L&f has complained
about the lack of an API for perceived bounds. Again,
that indicates to me, that we need more time to find
a stable API that is worth to be published in the Java core.

And so, I'd vote for adding the baseline API as suggested,
but focus on the many component bounds and insets, and
vote against a quick (and maybe dirty) LayoutManager3.

Best regards,
Karsten

P.S.: I'm going to write about perceived bounds here:
http://www.javadesktop.org/forums/thread.jspa?threadID=116766

Scott Violet

Hi Karsten,

Thanks for the feedback.

> If the new baseline API is intended to be used by visual builder
> tools and even non-visual builders, it'll likely be OK.

The baseline API is primarily meant for layout managers and builders.

> If on the other hand, developers will need to understand
> how to work with more complex cell constraints, that may fail.

I hope that we can soon get to a point where developers don't need, or
want to, hand author layout code. That said, I added the new
constraints to GridBagLayout to verify baseline layout could be done
with a grid type layout managers.

-Scott

skelvin
Offline
Joined: 2003-06-11
Points: 0

That looks very promising and I'll integrate it into my layouts (xlayouts java.net project) as soon as it is available.

I see an issue though:
You often use nested panels to help in layout, e.g. a group of buttons in a panel with grid layout (to give all buttons the same width).
Now if you want to 'baseline align' this panel with a label in a parent container, how do you do that?

[pre]--------------------------------
| --------------------- |
| label | button button button| |
| --------------------- |
--------------------------------[/pre]
The quintessence is that a layout manager should also have a say in determining the baseline.
How about this: Component delegates to UI, if the UI is indeterminate (e.g. a JPanel itself does not have any notion of a base line), it delegates to the component's layout manager.
The GridLayout in this case could report the common base line of all its contained buttons.

P.S. There currently is a similar problem in trying to make use of a layout managers minimum/maximum size calculations: The UI for JPanel delegates getMinimum/MaximumSize() to getPreferredSize(), so that the minimum/maximum sizes from the layout manager are always ignored.

zander
Offline
Joined: 2003-06-13
Points: 0

> I see an issue though:
> You often use nested panels to help in layout, e.g. a
> group of buttons in a panel with grid layout (to give
> all buttons the same width).
> Now if you want to 'baseline align' this panel with a
> label in a parent container, how do you do that?

Good point; I would guess an extra Interface BaselineLayoutManager (or LayoutManager3) would be needed so the container can ask the layout manager.
This is definitely needed to solve baselines for nested components!

> P.S. There currently is a similar problem in trying
> to make use of a layout managers minimum/maximum size
> calculations: The UI for JPanel delegates
> getMinimum/MaximumSize() to getPreferredSize(), so
> that the minimum/maximum sizes from the layout
> manager are always ignored.

I think you misdiagnosed the problem here; its that most layout managers shipped with the JDK completely ignore MaximumSize. Ask the max size of a panel with a gridlayout and you get 32k, no matter what is in there.
Use my layout manager (NaturalLayout, liked to in a previous post) and the maximum size of nested components is used correctly.

skelvin
Offline
Joined: 2003-06-11
Points: 0

> Good point; I would guess an extra Interface
> BaselineLayoutManager (or LayoutManager3) would be
> needed so the container can ask the layout manager.
> This is definitely needed to solve baselines for nested
> components!

Right, I haven't really thought about the need for that. Another method in LayoutManager2 would sure break binary compatibility. Sigh, ok let's have LayoutManager3 then, ok?
It would also adhere to the other layout properties, e.g. in determing the maximum size the UI also has the first say and if it cannot determine it, then the layout manager is used.
Strangely here's a case where an abstract class LayoutManager would have been easier to evolve, by just adding a method with default implemenation. I prefer interfaces to abstract classes most of the time myself, because I have a feeling of cleaner design.

> I think you misdiagnosed the problem here; its that most
> layout managers shipped with the JDK completely ignore
> MaximumSize. Ask the max size of a panel with a gridlayout
> and you get 32k, no matter what is in there.
> Use my layout manager (NaturalLayout, liked to in a
> previous post) and the maximum size of nested components
> is used correctly.

Hm, I remembered a problem that I chased down to the fact that ComponentUI.getMaximumSize() and getMinimumSize() delegate to getPreferredSize() of the same class.
I can't remember the exact problem, though, and right now can't reproduce it.

I am well aware that most layout managers completely ignore the maximum size - that was one of the reasons I started XTableLayout (https://xlayouts.dev.java.net/).

So I guess the note on your web site "This feature is unique to NaturalLayout." is a little outdated ;-)

pietschy
Offline
Joined: 2003-06-10
Points: 0

Hi Scott,

I've had a quick think about how I'd integrate this into my library and I think it should work fine.

The real test however will be when I actually start coding it. Do you know at what point this API will available in the Mustang builds? It would be great to give it a whirl and provide some real feedback.

Cheers
Andrew

Scott Violet

swing-feedback@javadesktop.org wrote:
> Hi Scott,
>
> I've had a quick think about how I'd integrate this into my library and
> I think it should work fine.

Excellent.

> The real test however will be when I actually start coding it. Do you
> know at what point this API will available in the Mustang builds? It
> would be great to give it a whirl and provide some real feedback.

I haven't integrated these changes yet, so that it's at least a month
away from appearing in a mustang build. I wanted to make sure the API
satisfied the communities needs before integrating it.

I'll be sure and post a follow up when the API makes it into a mustang
build.

-Scott

swpalmer
Offline
Joined: 2003-06-10
Points: 0

It would be great if the SpringLayout allowed you to anchor components by specifying where the baseline of the component should be, so the y location is computed from it. E.g. set the contraints such that there is a constant Spring of length 0 between the baseline of a JLabel and the baseline of a JTextField. Will that be possible?

Scott Violet

Yes, it would certainly be possible to introduce another anchor point
for SpringLayout.Constraints. How many people are using SpringLayout?

-Scott

zfqjava
Offline
Joined: 2003-09-22
Points: 0

I think the baseline API will help layout the component better.

But I cannot ensure whether the different component have same baseline, for example, in the common form panel,
there are button, spinner, textfield on one row, i want
to layout them to same height, and then adjust their
baseline, the new baseline API seems cannot help a lot.

I know the layout manager should get the baseline behavior
first, and then adjust it's bounds, but after resize it's
bounds, it seems that the different component will have
different location on one row, the panel will not look better.

I think if you can add some api to give the behavior to
component, will help layout the panel a lot. Because
we really want the different component like spinner,
textfield, button on one row have same height and
same baseline.

For example, if a component have a api to ensure all vertical alignment base it's baseline, then the layout
manager will need not changed, i only set a property
such as setAlignBehavior(baseline).

I am not ensure you understand what's i mean.

Scott Violet

swing-feedback@javadesktop.org wrote:
> I think the baseline API will help layout the component better.
>
> But I cannot ensure whether the different component have same baseline,
> for example, in the common form panel,
> there are button, spinner, textfield on one row, i want
> to layout them to same height, and then adjust their
> baseline, the new baseline API seems cannot help a lot.
>
> I know the layout manager should get the baseline behavior
> first, and then adjust it's bounds, but after resize it's
> bounds, it seems that the different component will have
> different location on one row, the panel will not look better.
>
> I think if you can add some api to give the behavior to
> component, will help layout the panel a lot. Because
> we really want the different component like spinner,
> textfield, button on one row have same height and
> same baseline.
>
> For example, if a component have a api to ensure all vertical alignment
> base it's baseline, then the layout
> manager will need not changed, i only set a property
> such as setAlignBehavior(baseline).
>
> I am not ensure you understand what's i mean.

I believe you're asking for a setBaseline method. This method would set
where the text is rendered at. While this would give you baseline
layout I can think of a couple of cases where it's problematic:

1. It may create components that don't look right. Consider if you
specified a baseline for text that was visually on the border. Take a
textfield as an example, if you set the baseline such that the text
appeared over the border decorations it wouldn't look right.
2. It'll conflict with how the component itself tries to align things.
What if you've created a JLabel with an icon and text where they are
both centered. How would JLabel lay things out, and compute a size, if
you specify a baseline other than where JLabel wants to position it?

In an ideal world the size of many widgets would be the same and the
baseline would be same. That way you wouldn't need to do a baseline
layout, it would be free. But that's not the world we live in.

-Scott

zander
Offline
Joined: 2003-06-13
Points: 0

Cool to see this going forward!

Allow me to think out loud with you :)

* BaselineResizeBehavior could have OFFSET_FROM_CENTER with description:
As the size of the component changes the text will stay centered in the component meaning the baseline will be just below the center of the component.
A non empty JLabel with default settings will return this.
Note that this offset from center itself is easy to calculate.
[code]
private int getOffset(JComponent comp) {
assert(comp.getBaselineResizeBehavior() == OFFSET_FROM_CENTER);
int prefHeight comp.getPreferredSize().height;
int center = prefHeight / 2;
return comp.getBaseline(Integer.MAX_VALUE, prefHeight) - center;
}
[/code]

* I'd like to see an enum value that characterizes a widget to not handle baselines. So the layout manager never has to call getBaseline at all (something that is still needed for the OTHER enum-value)

* I can't think of any component that will report back a baseline differently with different widths. Maybe I'm missing one (if so, please ignore this point). If its unlikely; then I suggest to leave the width param out of the getBaseline method since it will make it harder on layout managers, probably making them slower.

* Excuse my ignorance on enums, but won't it break (missing class) in the following case?
I write a class extending JComponent, compile on a new JVM and implement get getBaselineResizeBehavior method.
Then someone tries to use my widget on a 1.4 JVM. My guess is that my class will not initialize due to the missing enum class.

Scott; what about you create some objects that extend JComponent (or jspinner or whatever) with the above mentioned interface added to them. So a TestTextField1 which returns correct data, for example. I'll try to integrate it into my layout manager and get back to you on this.
There is no substitute for experience when creating an API :)

Scott Violet

> * BaselineResizeBehavior could have OFFSET_FROM_CENTER with description:
> As the size of the component changes the text will stay centered in the
> component meaning the baseline will be just below the center of the
> component.
> A non empty JLabel with default settings will return this.
> Note that this offset from center itself is easy to calculate.
> [code]
> private int getOffset(JComponent comp) {
> assert(comp.getBaselineResizeBehavior() == OFFSET_FROM_CENTER);
> int prefHeight comp.getPreferredSize().height;
> int center = prefHeight / 2;
> return comp.getBaseline(Integer.MAX_VALUE, prefHeight) - center;
> }
> [/code]

I think the big question I have is do you really need this? For the
components that would support this (button and label) I don't see them
resized all the often.

Another quirk is that if you do the calculation as you suggest you could
have rounding errors. For example, consider a pref height of 100, a
font height of 13 and a font baseline of 10. For some components that
baseline is calculated as:

(prefHeight - fontHeight) / 2 + fontBaseline

As such the computed baseline would be:

(100 - 13) / 2 + 10 = 53

The offset would be 3. If you tried to calculate where the components
baseline for a size of 101 is you'd end up with 101 / 2 + 3 = 53. Swing
though would calculate it as (101 - 13) / 2 = 10 = 54.

I suppose a layout manager could ask for two consecutive heights to
figure out if needs to do padding on odd/even boundaries like this.

> * I'd like to see an enum value that characterizes a widget to not
> handle baselines. So the layout manager never has to call getBaseline at
> all (something that is still needed for the OTHER enum-value)

In adding support for baseline layout to GridBagLayout and FlowLayout
the use case is typically ask for the baseline, and potentially ask for
the resize behavior. For example, FlowLayout doesn't care about
baseline resize behavior and GridBagLayout asks for the baseline first
too. So I don't see as how asking for the resize behavior first buys
you anything. What's the use case you're thinking of?

> * I can't think of any component that will report back a baseline
> differently with different widths. Maybe I'm missing one (if so, please
> ignore this point). If its unlikely; then I suggest to leave the width
> param out of the getBaseline method since it will make it harder on
> layout managers, probably making them slower.

button/label with html text may report back a different baseline with a
different size. It's questionable if this is a point that we should
care about though.

> * Excuse my ignorance on enums, but won't it break (missing class) in
> the following case?
> I write a class extending JComponent, compile on a new JVM and implement
> get getBaselineResizeBehavior method.
> Then someone tries to use my widget on a 1.4 JVM. My guess is that my
> class will not initialize due to the missing enum class.

Good question. I'm not sure about what point you'll see an error, but
you definitely will.

> Scott; what about you create some objects that extend JComponent (or
> jspinner or whatever) with the above mentioned interface added to them.
> So a TestTextField1 which returns correct data, for example. I'll try to
> integrate it into my layout manager and get back to you on this.
> There is no substitute for experience when creating an API :)

I'm not sure what you're asking?
If we used public static final ints, then there would be no problem for
the case you're mentioning.

-Scott

zander
Offline
Joined: 2003-06-13
Points: 0

> I think the big question I have is do you really need
> this? For the
> components that would support this (button and label)
> I don't see them
> resized all the often.

That kind of depends on the width being removed from the getBaseline call. If it is removed, you are right. Buttons being placed in a grid-based-layout manager and the button getting wider is pretty common. Its ugly and wrong, but people do it anyway.

> > * I'd like to see an enum value that characterizes
> > a widget to not
> > handle baselines. So the layout manager never has
> > to call getBaseline at
> > all (something that is still needed for the OTHER
> > enum-value)
>
> In adding support for baseline layout to
> GridBagLayout and FlowLayout
> the use case is typically ask for the baseline, and
> potentially ask for
> the resize behavior. For example, FlowLayout doesn't
> care about
> baseline resize behavior and GridBagLayout asks for
> the baseline first
> too. So I don't see as how asking for the resize
> behavior first buys
> you anything. What's the use case you're thinking
> of?

Well, those two layout managers don't do much intelligent work at all. The GridBag layout asks the user for so much info that its rules are pretty rigid. So I would be so bold to say that doing it in these is not really a good example of usage. Next, the getting of a baseline requires an object to create a fontmetrics object, most of the time. Which is pretty expensive, which I thought was kind of the idea of the enum, to be able to reuse an older value so you don't have to create loads of tmp objects again for every re-layout.
In fact, what _do_ you use the enum for, if not to limit calls to the getBaseline method? I don't think I would need it if I already know the baseline offset..

> > Scott; what about you create some objects that
> > extend JComponent (or
> > jspinner or whatever) with the above mentioned
> > interface added to them.
> > So a TestTextField1 which returns correct data, for
> > example. I'll try to
> > integrate it into my layout manager and get back to
> > you on this.
> > There is no substitute for experience when creating
> > an API :)
>
> I'm not sure what you're asking?

This is a seperate question altogether.
I wrote and maintain a layout manager that is atleast as, but probably even more advanced then the JGoodies layout manager. (see http://uic.sf.net/ for the NaturaLayout for details).
What I would like to do is implement support in that layout manager for this concept.
If you can publish some example-widgets that implement this concept, and an interface I can cast them to on an older JRE, then I can.
Naturally, I could create my own interface based on the above, but it would be easy to misunderstand stuff you had different ideas on.

Cheers!

Scott Violet

swing-feedback@javadesktop.org wrote:
>>I think the big question I have is do you really need
>>this? For the
>>components that would support this (button and label)
>>I don't see them
>>resized all the often.
>
>
> That kind of depends on the width being removed from the getBaseline
> call. If it is removed, you are right. Buttons being placed in a
> grid-based-layout manager and the button getting wider is pretty common.
> Its ugly and wrong, but people do it anyway.

I think you mean taller here, right?

>>>* I'd like to see an enum value that characterizes
>>>a widget to not
>>>handle baselines. So the layout manager never has
>>>to call getBaseline at
>>>all (something that is still needed for the OTHER
>>>enum-value)
>>
>>In adding support for baseline layout to
>>GridBagLayout and FlowLayout
>>the use case is typically ask for the baseline, and
>>potentially ask for
>>the resize behavior. For example, FlowLayout doesn't
>>care about
>>baseline resize behavior and GridBagLayout asks for
>>the baseline first
>>too. So I don't see as how asking for the resize
>>behavior first buys
>>you anything. What's the use case you're thinking
>>of?
>
>
> Well, those two layout managers don't do much intelligent work at all.
> The GridBag layout asks the user for so much info that its rules are
> pretty rigid. So I would be so bold to say that doing it in these is not
> really a good example of usage.

I agree with you on FlowLayout. Many of the more popular layout
managers are grid based, allowing for cell and row spanning.
GridBagLayout fits this bill as well, so that by adding baseline support
to GridBagLayout I'm pretty confident you could add it to any other grid
based layout managers using the API I've proposed.

> Next, the getting of a baseline requires
> an object to create a fontmetrics object, most of the time. Which is
> pretty expensive, which I thought was kind of the idea of the enum, to
> be able to reuse an older value so you don't have to create loads of tmp
> objects again for every re-layout.
> In fact, what _do_ you use the enum for, if not to limit calls to the
> getBaseline method? I don't think I would need it if I already know the
> baseline offset..

The enum allows for a layout managers to do baseline layout while
allowing for the components to resize. By that I mean the enum allows
for a layout manager to know how the baseline will change without having
to ask for the baseline at various sizes trying to infer the resize
behavior.

Consider a simple grid layout with one row and two components. If the
row is resizable how would you allow the components to resize while
still doing baseline layout?

>>>Scott; what about you create some objects that
>>>extend JComponent (or
>>>jspinner or whatever) with the above mentioned
>>>interface added to them.
>>>So a TestTextField1 which returns correct data, for
>>>example. I'll try to
>>>integrate it into my layout manager and get back to
>>>you on this.
>>>There is no substitute for experience when creating
>>>an API :)
>>
>>I'm not sure what you're asking?
>
>
> This is a seperate question altogether.
> I wrote and maintain a layout manager that is atleast as, but
> probably even more advanced then the JGoodies layout manager. (see
> http://uic.sf.net/ for the NaturaLayout for details).
> What I would like to do is implement support in that layout manager
> for this concept.
> If you can publish some example-widgets that implement this concept,
> and an interface I can cast them to on an older JRE, then I can.
> Naturally, I could create my own interface based on the above, but it
> would be easy to misunderstand stuff you had different ideas on.

A layout manager would be able to work with this API while still running
on older VMs. The layout manager could check for the enum and if it
exists you'ld know you could use the new API.

I'm not positive about the ability to write widgets that use the new API
while running on older vms. This may depend upon the verifier. I did a
simple test case that overrides the new API, compiled with the latest
and also ran with 1.5. I only got an error when I tried to invoke the
new method. If I did not invoke the new method I could still run on 1.5.

-Scott

zander
Offline
Joined: 2003-06-13
Points: 0

> I think you mean taller here, right?

No, I did write my thoughts down correctly :)
Will the width argument be removed from the getBaseline call?
If not, then the user rescaling the JPanel that the layout manager is managing will cause a lot of calls to getBaseline. Your optimalisations appeaar to be limited to the layout manager trying different sizes. This extra enum value will be needed to optimize for re-layouts between user-resizes.

> I agree with you on FlowLayout. Many of the more
> popular layout
> managers are grid based, allowing for cell and row
> spanning.
> GridBagLayout fits this bill as well, so that by
> adding baseline support
> to GridBagLayout I'm pretty confident you could add
> it to any other grid
> based layout managers using the API I've proposed.

Hmm. It would probably work, yes. I'm just concerned that the same optimalisations that I mentioned above will become impossible and that widgets that don't support this will suffer in layout-speed unneeded.
Please don't assume everyone will come up with the same solution as you did :)

> The enum allows for a layout managers to do baseline
> layout while
> allowing for the components to resize. By that I
> mean the enum allows
> for a layout manager to know how the baseline will
> change without having
> to ask for the baseline at various sizes trying to
> infer the resize behavior.

Ah; yes. The layout manager still needs to try different sizes for the widgets to come up with the best size is the widgets are filler widgets.
Check.

> > I wrote and maintain a layout manager that is atleast as, but
> > probably even more advanced then the JGoodies layout manager. (see
> > http://uic.sf.net/ for the NaturaLayout for details).
> > What I would like to do is implement support in that layout manager
> > for this concept.
> > If you can publish some example-widgets that implement this concept,
> > and an interface I can cast them to on an older JRE, then I can.

>
> A layout manager would be able to work with this API
> while still running
> on older VMs. The layout manager could check for the
> enum and if it
> exists you'ld know you could use the new API.

That was not the question; I still want to implement this functionality in my layout manager. Not as a final version, but as a 'kick the tyres' version. I assume you don't want me to wait for Mantis until I can, since feedback would be useless at that point
I'd like to actually program against the API to give better feedback. And I ask you to create some widgets that implement this API (and publish it for these poor layout-manager-authors). Thats all.

> I'm not positive about the ability to write widgets
> that use the new API while running on older This may depend upon the
> verifier. I did a
> simple test case that overrides the new API, compiled
> with the latest
> and also ran with 1.5. I only got an error when I
> tried to invoke the
> new method. If I did not invoke the new method I
> could still run on 1.5.

Ah; so widget providers can implement this without problems in a backwards compatible manner. Thats fine then.
Ps. please try to load a modified widget on a couple of older JVMs as well, just to be sure :-)

Scott Violet

swing-feedback@javadesktop.org wrote:
>>I think you mean taller here, right?
>
>
> No, I did write my thoughts down correctly :)

Ok, I think I misunderstood your point.

> Will the width argument be removed from the getBaseline call?

I, and others, have thought long and hard about this. It's necessary
for html on buttons/labels where the baseline can vary between the min
width and preferred width. So, it'll stay. But I've added another
constant to indicate this case so that a layoutmanager could
conceivablly ignore components where the baseline varies according to width.

> If not, then the user rescaling the JPanel that the layout manager is
> managing will cause a lot of calls to getBaseline. Your optimalisations
> appeaar to be limited to the layout manager trying different sizes. This
> extra enum value will be needed to optimize for re-layouts between
> user-resizes.

I agree it makes the layout more complicated. On the plus side it's not
the common case.

>>I agree with you on FlowLayout. Many of the more
>>popular layout
>>managers are grid based, allowing for cell and row
>>spanning.
>>GridBagLayout fits this bill as well, so that by
>>adding baseline support
>>to GridBagLayout I'm pretty confident you could add
>>it to any other grid
>>based layout managers using the API I've proposed.
>
>
> Hmm. It would probably work, yes. I'm just concerned that the same
> optimalisations that I mentioned above will become impossible and that
> widgets that don't support this will suffer in layout-speed unneeded.

The enum will indicate whether or not you need to call back based on
width, so that you can optimize that out.

>>>I wrote and maintain a layout manager that is atleast as, but
>>>probably even more advanced then the JGoodies layout manager. (see
>>>http://uic.sf.net/ for the NaturaLayout for details).
>>>What I would like to do is implement support in that layout manager
>>>for this concept.
>>>If you can publish some example-widgets that implement this concept,
>>>and an interface I can cast them to on an older JRE, then I can.
>
>
>>A layout manager would be able to work with this API
>>while still running
>>on older VMs. The layout manager could check for the
>>enum and if it
>>exists you'ld know you could use the new API.
>
>
> That was not the question; I still want to implement this functionality
> in my layout manager. Not as a final version, but as a 'kick the tyres'
> version. I assume you don't want me to wait for Mantis until I can,
> since feedback would be useless at that point
> I'd like to actually program against the API to give better feedback.
> And I ask you to create some widgets that implement this API (and
> publish it for these poor layout-manager-authors). Thats all.

Early feedback is definitely desired!
I'll do a blog when the API goes into the build and you can then
download the bits and program to it.

>>I'm not positive about the ability to write widgets
>>that use the new API while running on older This may depend upon the
>>verifier. I did a
>>simple test case that overrides the new API, compiled
>>with the latest
>>and also ran with 1.5. I only got an error when I
>>tried to invoke the
>>new method. If I did not invoke the new method I
>>could still run on 1.5.
>
>
> Ah; so widget providers can implement this without problems in a
> backwards compatible manner. Thats fine then.

[b]WARNING[/b]: I said it worked for me. I don't know enough about
classloaders to know if it will always work.

> Ps. please try to load a modified widget on a couple of older JVMs as
> well, just to be sure :-)

That I did.

-Scott

zander
Offline
Joined: 2003-06-13
Points: 0

> > I still want to implement this functionality
> > in my layout manager. Not as a final version, but as a 'kick the tyres'
> > version. I assume you don't want me to wait for Mantis until I can,
> > since feedback would be useless at that point
> > I'd like to actually program against the API to give better feedback.
> > And I ask you to create some widgets that implement this API (and
> > publish it for these poor layout-manager-authors). Thats all.
>
> Early feedback is definitely desired!
> I'll do a blog when the API goes into the build and
> you can then
> download the bits and program to it.

Sure; I just wanted to suggest you create a couple of objects for experimentation for people that can't agree to the license of the mantis builds. Like me.