Re: How to set fixed culmn width in NSTableVeiw?

[Nicola Pero]

Sorry Stefan, I'm not really answering to you, rather reading your email
made me remember I need to say my opinion on the current table view
resizing code.

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

Hi thanks - 

I 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.

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.  

The 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.  
The 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 ?  
There 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.

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.