ListGridField.setAutoFitWidth(false) has no impact on ListGrid context menu's autofit

[Blama]

Hi Isomorphic,

please see the attached test case ( + screenshots). I'm expecting the last columns to stay constant in width, which does not happen here (FF26, v10.0p_2015-04-23).

package com.smartgwt.sample.client;

import com.google.gwt.core.client.EntryPoint;
import com.smartgwt.client.core.KeyIdentifier;
import com.smartgwt.client.data.DataSource;
import com.smartgwt.client.types.AutoFitWidthApproach;
import com.smartgwt.client.util.PageKeyHandler;
import com.smartgwt.client.util.Page;
import com.smartgwt.client.util.SC;
import com.smartgwt.client.widgets.grid.ListGrid;
import com.smartgwt.client.widgets.grid.ListGridField;
import com.smartgwt.client.widgets.layout.VStack;

public class BuiltInDS implements EntryPoint {
	private ListGrid boundList;
	private ListGridField scientificName;
	private ListGridField commonName;
	private ListGridField status;
	private ListGridField status2;
	private ListGridField lifeSpan;
	private ListGridField information;

	public void onModuleLoad() {
		KeyIdentifier debugKey = new KeyIdentifier();
		debugKey.setCtrlKey(true);
		debugKey.setKeyName("D");

		Page.registerKey(debugKey, new PageKeyHandler() {
			public void execute(String keyName) {
				SC.showConsole();
			}
		});

		VStack vStack = new VStack();
		vStack.setLeft(20);
		vStack.setTop(20);
		vStack.setWidth("95%");
		vStack.setHeight("95%");
		vStack.setMembersMargin(20);

		boundList = new ListGrid() {
			{
				setDataSource(DataSource.get("animals"));

				commonName = new ListGridField("commonName");
				commonName.setAutoFitWidthApproach(AutoFitWidthApproach.BOTH);

				scientificName = new ListGridField("scientificName");
				scientificName.setAutoFitWidthApproach(AutoFitWidthApproach.TITLE);

				status = new ListGridField("status");
				status.setAutoFitWidthApproach(AutoFitWidthApproach.VALUE);

				status2 = new ListGridField("status");
				status2.setWidth(50);
				status2.setAutoFitWidth(false);

				lifeSpan = new ListGridField("lifeSpan");
				lifeSpan.setWidth(50);
				lifeSpan.setAutoFitWidth(false);

				information = new ListGridField("information");
				information.setWidth(50);
				information.setAutoFitWidth(false);
				
				setFields(commonName, scientificName, status, status2, lifeSpan, information);
			}
		};
		vStack.addMember(boundList);
		vStack.draw();
		boundList.fetchData();
	}
}

Best regards,
Blama

[Isomorphic]

Presumably, the second screenshot is the result of picking "Auto Fit all Columns" from the header context menu? If so, please state this explicitly next time.

As far as the behavior, it's doing what the docs tell you. The listGridField.autoFitWidthApproach settings affects what will happen if the user uses the UI to autofit just that one field. Whole-grid auto-fitting is a separate behavior which the user uses for different purposes.

To avoid undesirable results like what you're seeing (extreme horizontal scrolling) what you would typically want to do is disable autofitting entirely for extremely long fields, since neither auto-fitting to value nor auto-fitting to title is desirable in the context of whole-grid autofitting.

[Blama]

Hi Isomorphic,

yes, I was refering to "Auto Fit all Columns" and the screenshots show the testcase before and after "Auto Fit all Columns".

To avoid undesirable results like what you're seeing (extreme horizontal scrolling) what you would typically want to do is disable autofitting entirely for extremely long fields, since neither auto-fitting to value nor auto-fitting to title is desirable in the context of whole-grid autofitting.

I think I am doing exactly this in the code shown (three fields with setAutoFitWidth(false)).



As a second point: My problem in my application is not with very long fields, but with createRecordComponent-fields, which are resized to an almost-0 width. Having a setting (enhancement) like setAutoFitMinWidth(int width) and setAutoFitMaxWidth(int width) would be great.

Best regards
Blama

[Isomorphic]

We'll take a second look at autoFitWidth:false, however on revisiting, it's a little unclear that there *should* be a property that causes the end user's attempt to autofit to be ignored. We'll let you know.

As far as your recordComponent issue, when auto-fitting, the listGridField.width setting serves as a minimum. Also consider setting listGrid.minFieldWidth higher to create a grid-wide minimum.

It's too soon to start using it, but 6.0 also features listGridField.minWidth and maxWidth settings that would address this.

[Blama]

Hi Isomorphic,

thanks for all the information. I'll wait for your second look. Please note that ListGridField.setWidth() is also used in the testcase and that the lifeSpan field seems to become smaller nevertheless in the screenshots (I'm at home and can't verify).

EDIT: If you meant that ListGridField.setWidth() defines a min-width for recordComponents fields, I'm very sure that this does not happen for me in my application.

Best regards
Blama

[Blama]

If you meant that ListGridField.setWidth() defines a min-width for recordComponents fields, I'm very sure that this does not happen for me in my application.

This is not the case, ListGridField.setWidth() does not define a minimum width for recordComponents fields, see the grid_cell_widgets sample and apply "Auto Fit All Columns".
the iconField, which has setWidth(100), is resized to a very small size, too.

Best regards
Blama

[Blama]

Hi Isomorphic,

any updates on this one?

Best regards
Blama

[Isomorphic]

Hi Blama
There are several points to discuss here:

- firstly - listGridField.autoFitWidth being set to false does not cause the field to be excluded from auto-fit when the user uses the context menu to "auto fit all" fields.
This is intended behavior - the autoFitWidth property is used in conjunction with the listGrid.autoFitFieldWidths behavior - when true it implies the width is currently being driven by the fields content (or title). This kind of autofitting is "ongoing" (it will react to data changing, etc), and it would be confusing to have this property double as a flag indicating the separate user-driven "one time auto fit" available via the menu option should not apply to this field.
We are looking into providing a separate property (listGridField.canAutoFitWidth) to govern whether a user can perform one time autoFit of specific fields. This is not currently available in 10.0, but you could roll your own behavior via a custom header menu item which programatically calls "listGrid.autoFitFields(...)" and passes in just the array of fields you want to apply auto-fit to.

- In SmartGWT 6.0 we are introducing new properties for minimum / maximum field widths. These will be respected when the user attempts to auto-fit a field via the menu options. We are not planning to attempt to backport this to earlier SmartGWT versions.

- ListGridField.autoFitWidthApproach: This property is currently respected for both ongoing autofit enabled programmatically via listGrid.autoFitFieldWidths, and for one-time autofit achieved via the header menu item (or via a call to listGrid.autoFitFields()). We've tested this and it is behaving as expected for us, so do let us know if you have a case where this does not appear to be true.

- The interaction of listGrid autofit and record-components is indeed somewhat confusing - we're looking at how to improve this.

- Our documentation is currently unclear about whether the one-time auto fit of all fields achieved via the menu item will respect the autoFitFieldsFillViewport and autoFitClipColumns properties -- in other words whether we'll handle filling the viewport and clipping overly long fields.
This needs to be improved and is something we're working on internally. FYI - you should currently see the autoFitFieldsFillViewport behavior being respected on a one-time autoFit

- In SmartClient (Javascript) we also do have support for customizing how the "auto fit width" of a field is determined via an override to the getDefaultFieldWidth() method.
This has not yet been wrapped as an override point for SmartGWT, meaning there is no way for an external developer to customize this, but we're looking at providing an easy way for developers to specify a custom "auto fit width" for fields.

We'll keep you posted on the various "in progress" issues here as we proceed.
Hope this helps

Regards
Isomorphic Software

[Blama]

Hello Isomorphic,

that's a lot of information to understand. Thanks for writing it down.

- firstly - listGridField.autoFitWidth being set to false does not cause the field to be excluded from auto-fit when the user uses the context menu to "auto fit all" fields. This is intended behavior.....
....
We are looking into providing a separate property (listGridField.canAutoFitWidth) to govern whether a user can perform one time autoFit of specific fields.

Great, thank you.

the autoFitWidth property is used in conjunction with the listGrid.autoFitFieldWidths behavior - when true it implies the width is currently being driven by the fields content (or title). This kind of autofitting is "ongoing" (it will react to data changing, etc)

This is pretty amazing! I did not see it in action, though. Could you add a showcase sample showing this? Most likely another USP of your product.
The javadocs for ListGrid.setAutoFitWidth() could advertise this more - besides the word "dynamic" there is nothing that could possibly tell the user that the resizing is ongoing. Only the docs for autoFitField() and autoFitFields() tell this as opposed to ListGrid.setAutoFitWidth() ("Does not establish permanent auto-fitting - use ListGrid.setAutoFitWidth() to do so.").
Interesting information for the docs might also be what is used to calculate the resulting width:

• All loaded data (meaning that scrolling down changes width, while scrolling up doesn't);
• Current viewport (meaning that scrolling down and up changes width)
• Current viewport, but also influenced by ListGrid.setDrawAheadRatio()

In SmartGWT 6.0 we are introducing new properties for minimum / maximum field widths. These will be respected when the user attempts to auto-fit a field via the menu options. We are not planning to attempt to backport this to earlier SmartGWT versions.

That sounds good as well!

ListGridField.autoFitWidthApproach: This property is currently respected for both ongoing autofit enabled programmatically via listGrid.autoFitFieldWidths, and for one-time autofit achieved via the header menu item (or via a call to listGrid.autoFitFields()). We've tested this and it is behaving as expected for us, so do let us know if you have a case where this does not appear to be true.

I'm not sure if I can provide one and will look if the behaviour I'm seeing is opposing the docs with the new information I have.

The interaction of listGrid autofit and record-components is indeed somewhat confusing - we're looking at how to improve this.

That would be great (and is the most important for me). Especially you mentioned that ListGridField.setWidth() will prevent the width from being changed. This is not the case (see post #6)

In SmartClient (Javascript) we also do have support for customizing how the "auto fit width" of a field is determined via an override to the getDefaultFieldWidth() method.
This has not yet been wrapped as an override point for SmartGWT, meaning there is no way for an external developer to customize this, but we're looking at providing an easy way for developers to specify a custom "auto fit width" for fields.

This would be an alternative solution to the ListGridField.setWidth()-problem from above, correct? This should also solve the RecordComponent case IMHO.
I'd would also work with ListGrid.setFieldState(), correct? I'm asking because I have a default setup for each ListGrid, but persist the configuration on user change and re-apply it on destroy+new.

We'll keep you posted on the various "in progress" issues here as we proceed.
Hope this helps

It sure does help.

Best regards
Blama

[Isomorphic]

Hi Blama,

RE this:

Originally Posted by Isomorphic View Post
the autoFitWidth property is used in conjunction with the listGrid.autoFitFieldWidths behavior - when true it implies the width is currently being driven by the fields content (or title). This kind of autofitting is "ongoing" (it will react to data changing, etc)

This is pretty amazing! I did not see it in action, though. Could you add a showcase sample showing this? Most likely another USP of your product.
The javadocs for ListGrid.setAutoFitWidth() could advertise this more - besides the word "dynamic" there is nothing that could possibly tell the user that the resizing is ongoing. Only the docs for autoFitField() and autoFitFields() tell this as opposed to ListGrid.setAutoFitWidth() ("Does not establish permanent auto-fitting - use ListGrid.setAutoFitWidth() to do so.").

The javadoc for listGrid.setAutoFitFieldWidths() do actually indicate that things are dynamic with the following text:

Autofitting will be performed:

* whenever the dataset is completely changed or rows are added or removed
* whenever a field which is autofitting is changed
* on a manual call to ListGrid.autoFitField() or ListGrid.autoFitFields()

Auto-fitting behavior continues until the user resizes the field manually, at which point it stops. The user can also perform a one-time auto-fit of fields via the header context menu if canAutoFitFields is enabled.

But we'll make sure this information is also mentioned in the per-field property (ListGridField.autoFitWidth).

We realize this isn't demonstred directly in the showcase but you can easily experiment yourself. One thing to try would be creating a databound ListGrid with a visible filterEditor and autoFitFieldWidths set to true. To make things really obvious you may want to also turn off autoFitFieldsFillViewport so the size is driven directly by the content.
As you filter the data you'll see the field widths change to fit things.

To flesh out the points you raise below:

... what is used to calculate the resulting width:

All loaded data (meaning that scrolling down changes width, while scrolling up doesn't);
Current viewport (meaning that scrolling down and up changes width)
Current viewport, but also influenced by ListGrid.setDrawAheadRatio()

The width is calculated based on the drawn data (so the current viewport plus drawAheadRatio). This is a requirement since we have to actually measure drawn HTML and we don't want to render more than expected.
We do not change the widths as the user scrolls - if there's a very wide value which is initially outside the viewport and it gets scrolled into view, it will be clipped.
We realize this behavior could be considered incorrect but from a user-experience standpoint we believe it is better than the alternative of having the grid geometry change as the user scrolls.


With respect to explicitly specified field.width:

The field.width is treated as a minimum for autoFit in the case where ongoing autoFit is enabled via a call to setAutoFitWidth() / setAutoFitFieldWidths().
It is not treated as a minimum for one-time autoFit achieved via the user clicking the 'auto fit' menu option.
This is again something we consider the best user experience - it is useful for a programmer to be able to provide a minimum for the setAutoFitFieldWidths() case.
But if a field has a width (either provided by the application code, or possibly applied via a drag-resize), and the user then clicks the "auto fit" menu item to perform a one-time auto fit, the field should ignore the current width and shrink down to fit content (if appropriate).

On the record-components side of things: We've now added support for a simple property, listGridField.defaultWidth which allows developers to specify an explicit auto-fit width.
This is available in both 5.0 and 5.1.

In 5.1 we've also added a SmartGWT customizer to allow application code to dynamically come up with an auto-fit width for a field, as well as adding support for a listGridField.canAutoFitWidth flag which essentially disables the "auto fit" menu option for that field.
We've also expanded the documentation a little to indicate how auto-fit to content does not take RecordComponents into account, and referring developers to these properties to customize what should happen if a user attempts to autoFit all columns and some columns show record-components.


... and that's about it for now!
Let us know if you have more questions in this area / if there's anything you think we've missed, or if things don't behave as expected.

Regards
Isomorphic Software

[Blama]

Hi Isomorphic,

wow, thank you. I did not expect this that fast. For me listGridField.defaultWidth you added to 5.0 should be enough for now.
I'll try tomorrow and give feedback here.

Regarding the ongoing resize:

We realize this behavior could be considered incorrect but from a user-experience standpoint we believe it is better than the alternative of having the grid geometry change as the user scrolls.

I agree with that. The other would look impressive the first time but definitely not be better to use.

Best regards
Blama

[Blama]

Hi Isomorphic,

ListGridField.setDefaultWidth() works for me as expected in combination with RecordComponents.

For the rest I'll revisit when they are available (especially 6.0's minimum / maximum field widths).

Thank you very much
Blama

[Blama]

Hi Isomorphic,

I saw that you already have ListGrid.setMinFieldWidth().

Could you add ListGrid-level ListGrid.setMaxFieldWidth() as well before 6.0 where you plan the new properties for minimum / maximum ListGridField-widths (best in 5.0)?

Best regards
Blama

[Isomorphic]

We've taken a note to consider this for 6.0.

[Blama]

Hi Isomorphic,

I just noted that this did not make it to 6.0. I think this would be a really good enhancement.

Best regards
Blama