Re: How to set fixed culmn width in NSTableVeiw?

[Pierre-Yves Rivaille]

Hi Nicola,

> >       /* Fix Gorm autoresizing */
> >       [[[table superview] superview]            setAutoresizingMask:[table
> > autoresizingMask]];

> Hi thanks -
> don't understand this kind of stuff.  The table autoresizing mask has no
> importance if it's in a scrollview, since the table is always the same
> size.  If the table is not in a scrollview, then I don't understand why
> you are touching the super-super autoresizing mask in that way.

This code is due to a bug in Gorm : when you are selecting a NSScrollView 
containing an NSTableView, you can only set the NSTableView's 
autoresizingMask, not the NSScrollView's autoresizingMask. So the previous 
code is a run-time work-around for this Gorm problem.

> As far as I understand, a scrollview is meant to decouple the size of what
> is displayed inside the scrollview from the actual size of the scrollview.
> he two things can be varied in complete independence, with the visible
> area in the scrollview only showing a part of the view which is inside the
> scrollview, and the user deciding which area to show by moving the
> scrollers, and making the area bigger or smaller by changing the
> scrollview size.

> This is an extremely general UI design - a decorator pattern if I remember
> correctly.  The scrollview is a very general object.  It behaves in the
> same way regardless of what is inside.  What is inside can then forget
> about resizing and just size everything to full size from the very
> beginning.  The user can move with the scrollers, and make the visible
> area bigger or smaller by resizing the scrollview - again consistently
> independently of what is inside.  The views which are put inside the
> scrollview don't need to know they are inside a scrollview.

> If you make the scrollview bigger or smaller to see more or less of what's
> inside, and that action implicitly changes what is inside, I think that is
> against both object orientated design and user interface design concepts.  
user
> interface is automatically changing sizes of objects without the
> user asking for it, and outside user control.  Example - to make the point
> - if the scrollview is displaying an object containing 10 buttons of a
> certain size, and the visible area contains only 4 of them.  The user
> thinks - I want to see more of them - so he enlarges the scrollview,
> thinking that this will enlarge the visible area (in the same way as when
> you edit text and only see 4 lines, and you want to see more, you enlarge
> the scrollview).  But the object inside the scrollview has hacked the
> clipview machinery to get informed when it's changed, and decides
> arbitrarily to make the buttons bigger.  After the resizing the user ...
> still sees only 4 buttons, but bigger!  Damn machine.  This is as if the
> NSTextView was changing the fonts when the user resized the scrollview
> enclosing the textview.  How do you just make the visible area bigger ?  is 
no
> way.  But ... but with any other view it works in that way !  Sure it
> does.  Apparently the implementation of this widget is not only
> autosizing stuff against and oustide the user control, it's not only
> autosizing the widget differently if it is inside a scrollview or not,
> it's also completely inconsistent with the behaviour of other widgets.

NSTableView's autoresizing mechanism is meant to address those problems:
- it won't resize any column when the tableview is strictly bigger than the
  clipview (i.e. when all the rows can't be seen).
- it won't resize any column when the tableview is strictly smaller than the
  clipview (i.e. when there is empty space on the right of the last column).
- it will only resize columns when the tableview is exactly filling the
  clipview, in this case it will either resize the last column or all the 
columns
  so that the tableview still fits perfecly within the clipview.

So I think it does not go against the user ui experience because, whenever the 
user changes a column size, NSTableView stops autoresizing the columns, hence 
it "respects" the user's choices.

(there was on small bug, that I have just fixed in CVS, this bug led
to NSTableView not "respecting" the user choice when setAutoresizesAllColumns 
was set to YES, I guess you encountered it)


> Now - just imagine that I changed the textview to make the fonts bigger
> when the user makes the scrollview bigger.  Why not ?  if the user makes
> the scrollview bigger, then there is more space, so we can make the fonts
> bigger.  This is wrong - but making the tableview columns bigger just
> because the user has made the scrollview bigger (Why not ? there is more
> space) is exactly the same sort of error.

> What is inside can always be made big enough to display everything
> comfortably from the very beginning - the user has got the scrollbars to
> go to the interesting point.  If the user makes the scrollview bigger, the
> visible area is bigger.

> The current tableview implementation seems completely broken to me in this
> respect.  I see not only columns resizing themselves, but even *appearing*
> and *disappearing* when I resize the scrollview containing the tableview
> in the GSTest NSTableView demo/example.  The ChangeLog entry says that
> this is what happens on OS 4.2 ... I seriously doubt that on OS 4.2
> columns appear and disappear when you resize the scrollview; I also
> seriously doubt - no matter what OS 4.2. does - that we should resize the
> columns when the enclosing scrollview is resized - the reason for which I
> explained above.

I believe it is the current GSTest example that is not well designed for the 
current NSTableView implementation : it does not set any width for the columns 
named "Column {0,1,2,3,4}" (so their width are 0, i.e. the default 
NSTableColumn width), nor does it set a minimum width for those columns. It 
still relies on the sizeToFit: method to set the initial size of the columns, 
but I have changed this method to behave as it does on MOSX/OS42 (resizing all 
the columns to have the same width, it will gently handle the 
minWidth/maxWidth cases and will try to use only integers if it is possible), 
consequently it shows a very strange initial state. But in most applications, 
minWidth and width are never both set to 0, and sizeToFit is not called.
I will update the current GSTest example so that it sets the minWidth for the 
columns.

The current autoresizing mechanism of NSTableView does behave as it does on 
MOSX/OS42 as far as I can tell (except for sizeToFit, where GNUstep uses a 
more precise algorithm to deal with minWidth and maxWidth values :-) ).

        Pierre-Yves