Add a function to auto-size a column to it's widest member. This can be used when double-clicking the column header or when pressing ctrl-+ (bug 135749).

From bug 135749: ------- Additional Comment #3 From Kyle Yuan 2002-04-08 01:36 ------- There isn't any functions that can adjust the width of all columns to fit their contents. right? ------- Additional Comment #4 From Jan Varga 2002-04-08 01:47 ------- No, but there's an internal method GetCellWidth() which is used for example in CalcMaxRowWidth()

Dean, could you give me a proposal of this function? If hewitt has no time, I can have a try.

This bug should probably be about auto-sizing a specific column, like double-clicking the column splitter in the list header does in Windows explorer. We should implement a double-click on the column splitter in the header to auto-size as well. Then bug 135749 can take care of calling this function for all columns when Ctrl-+ is pressed.

Keep in mind that native Windows trees allow the total width of all columns to be different from the width of the tree. Double-clicking on the right edge of a column title in a native Windows tree makes that column big enough to contain all of its contents. We can do that if the user double-clicks on one column, but autosizing all columns at once will need different logic.

Jan, I found some problems in nsTreeBodyFrame::GetCellWidth(): 1) It doesn't count image margin of nsXULAtoms::moztreeimage; 2) Sometimes, it can't get image, i.e. GetImageSize() return 0 for width. I tried to find the answer, but it's too complex.

> 1) It doesn't count image margin of nsXULAtoms::moztreeimage; I have no idea why it is not there, please fix it and make sure that XBL select works right. > 2) Sometimes, it can't get image, i.e. GetImageSize() return 0 for width. I tried to find the answer, but it's too complex. This can be the case when image has not been loaded yet.

I filed bug 155510 for the autosizing function for tree column.

taking

I'm changing the summary to make this bug easier to find. Kyle Yuan, do you have any update on the progress of this bug? Thanks, Prog.

No, I haven't worked on this for years. Reassigning to the default owner.

Is this and the dependent bug on anybody's radar?

I don't think anyone is going to work on this given the plan to remove the XUL "tree" widget (bug 1446335).