Re: How to set fixed culmn width in NSTableVeiw?

[Pierre-Yves Rivaille]

> > 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.
> 
> Ok - thanks for answering - I think the fact that
> NSTableView stops
> autoresizing the columns when the user changes a column
> size is pretty
> against ui concepts but anyway :-) - because 1. the user
> didn't really ask
> for stopping autoresizing, he only asked for resizing a
> column - it's the
> library implicit assumption that the user wants to stop
> autoresizing as
> well; 2. there is no visible change in the display to
> represent the fact
> that the behaviour is substantially changed; 3. there is
> no simple way for
> the user to revert back to the previous behaviour - how
> does the user undo
> his change and start autoresizing of the columns again ?
> (pretty difficult
> for the user to guess how to change the behaviour back
> since he didn't ask
> the behaviour to be changed in the first place)
> 
> (3. is typically microsoftish - you experiment with the
> different options
> of a widget soon to find out that after you've tried the
> different options
> and decided the original one was the best one, you can't
> actually get back
> to the original one)
> 
> I think there are really three different wanted behaviours
> from the
> tableview -
> 
>  1. tableview with few rows and columns. the tableview is
> not put into
>  a scrollview. it should have a
> resizeWithOldSuperviewSize:
>  implementation which resizes the columns depending on
> the new size.
>  (if the appropriate autoresizingMask is set, the table
> gets bigger
>  to fill all the space allocated to it).
> 
>  2. tableview with many rows and columns. the tableview
> is put into a
>  scrollview. it should resize nothing where the
> scrollview is resized.
> 
>  3. tableview with many rows but few columns. in this
> case you want
>  behaviour 2 vertically (a vertical scroller to browse
> the rows), but
>  behaviour 1 horizontally (no horizontal scroller to
> browse the
>  columns, and - if the tableview should resize,
> resizing of columns
>  to fit the available space) [I think it would be cool
> to have built-in
>  support in the scrollview for such cases]
> 
> this would be Ok - but the mess appears because (according
> to what you
> say) you/OS42 wants the program to automatically switch
> from behaviour 1.
> to behaviour 2. horizontally, without any change in the
> visible UI, and
> without any clear request. I don't like that. If you put
> the tableview
> inside a scrollview and are in behaviour 1. horizontally,
> if I understand
> you correctly, as soon as you touch a column width and
> resize the
> scrollview, you drop into behaviour 2. horizontally, and
> there is no easy
> way to undo the change! In other words, if your tableview
> exactly fits
> the clipview, then whenever you resize the scrollview, the
> tableview is
> resized to exactly fit the clipview; suppose you like that
> a lot. but
> then, you make a mistake while dragging a column around,
> and resize a
> column slightly (and you don't notice) [or just, you are
> experimenting and
> try to resize a column]. then, you resize the scrollview.
>  well the
> tableview is no longer resized to fit, so as soon as you
> resize, the
> scrollview becomes much bigger than the tableview, and the
> tableview
> doesn't change a single bit when you resize the scrollview
> again. you
> really loved how it behaved before but ... there is no way
> back ...
> <possibly the way back is to resize the window so as to
> try make the
> scrollview visible area exactly match the tableview frame
> ... oh so
> perverse and so windowish, having to resize ten or twenty
> times a window
> trying to make the clipview frame exactly match the
> enclosing the
> tableview ...
> Since both table column widths and window
> widths are saved
> to disk, I suppose closing and reopening the application
> will not undo the
> change.
> 
> Is this correct ?

Not really, I over simplified the things. I'll try to be more precise :
- as long as the tableview fits perfectly, the tableview is resized
- as soon as the tableview doesn't fit anymore, the tableview isn't
    resized anymore
- as soon as the tableview fits the clipview again, the tableview is
    resized again. When I say "fits the clipview again", it means even in
    a transition state : when you resize the scrollview
    from being too narrow to being too wide (or the other way around), it
    (implicitly) passes thru a certain state where the tableview
    exactly fits the clipview, so autoresizing is back at this time.

Although this description may seem very weird and unintuitive, it seems
pretty natural when you play with it (I guess the guys at NeXT had a hard
time finding this behaviour). There may be some drawbacks with this
behaviour, but the user will easily size the column the way he/she wants
and still takes full benefit of the autoresizing mechanism.

> 
> I don't want to blaim you for mistakes in the OS42 user
> interface design,
> but I consider this horribly wrong - very microsoftish -
> difficult-to-undo
> changes made automatically by the program - outside your
> control - are
> very microsoftish ...
> 
> 
> > 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,
> 
> Why 'still' ?
> 
> It builds the table exactly how any autosizing/autolayout
> UI mechanism
> must do. It builds the table putting inside all
> information, then calls
> 'sizeToFit' to get the proper minimum size to display the
> table. Setting
> a hardcoded minimum width in point/pixel size is not an
> autosizing
> mechanism. The minimum size should always be determined
> from the actual
> contents of the UI object in an autosizing engine.
> 
> You call sizeToFit precisely because you don't know the
> minimum width of
> the columns.

We already talked about this, and I believe we should create a method
that has the behaviour you describe, however we should give it another
name because sizeToFit: has a specific behaviour on OSX/OS42 and I
believe we should maintain compatibility. I'm just not very good at
finding method's name, give me a name and I'll put the old code back in. 

> 
> 
> > 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.
> 
> sizeToFit should be implemented for the benefit of
> applications which use
> it, not for applications which don't use it.
> 
> 
> > I will update the current GSTest example so that it sets
> the minWidth for the
> > columns.
> 
> Please don't do this.

Oops, too late. (I am at work so I can't do anything right now).

> 
> Well - you already did, and in the wrong way - calling
> setMinWidth: with
> an arbitrary number (50 as you did) is meaningless. I
> suppose there is a
> culture problem here.

I prefer using nib/gorm files than using hard-coded UI. I know everyone
don't feel the same, so having the methods I've just talked about would
solve those issues. However I don't like adding new GNUstep specific
methods for general use, because it just makes porting to OSX more
difficult, so we should try to make this method compatible with
MOSX NSTableView and add it as a category.

Let me elaborate on why we should not replace the current sizeToFit but
rather create a new method. sizeToFit: is supposed to be the counterpart
of sizeLastColumnToFit:, of course it would have been better to name it
sizeAllCoolumnsToFit, but I guess the NeXT's guys were not sleeping
enough... So sizeToFit is called during the autoresizing mechanism when
the sizeAllColumnsToFit option is set to YES, redefining it would lead to
a *very* strange autoresizing mechanism (of course this could be worked
out on GNUstep, but not on OSX).

> sizeToFit resizes the widget to *fit its contents*. In an
> autosizing
> engine, widgets should be resized to *fit their contents*.
>  Setting
> arbitrary numbers as widths does not make any sense. 50
> might be enough
> in English but not in Italian. If you change the column
> name, 50 might no
> longer be enough, or might become too much.
> 
> If sizeToFit in the library is not using the size of the
> contents of the
> column, then that code should be in the application - the
> application
> should then loop on all the column row, determine the size
> of each, then
> build the minimum size of the column as the maximum of all
> the sizes of
> all the rows. Do that for all columns. Every
> autosizing-based
> application displaying a tableview must do that for all
> tableviews it
> displays. It should also manage the thing with the user
> autosaved column
> widths, since those should take precedence over the
> computed sizes ... all
> hopeless I see since we can't even have a sizeToFit which
> actually sizes
> to fit the contents.
> 
> 
> > 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 :-) ).
> 
> So MOSX/OS42 doesn't support autosizing of tables. We
> must address this
> instead.

see previous comment.

> 
> Uff.
> 
> A portable XML UI autolayout which works on MOSX should
> then provide its
> own implementation of NSTableView sizeToFit to address
> this (and work with
> column autosaving). But it would have been good if it
> worked natively at
> least on GNUstep, so you wouldn't have to write the
> porting sizeToFit code
> from the very beginning, but could add it later on to help
> with porting.
see previous comment (but i want to say it again, use a different name for
the new sizing method).


To conclude :
I firmly believe the current NSTableView is the right one, and that we
should keep the current autoresizing mechanism.
I also support your UI autolayout feature, but I disagree to having it as
the default GNUstep's behaviour (porting between OSX and GNUstep would be
a nightmare), it should only be an extension provided for people who don't
like nibs/gorms.


        Pierre-Yves


PS: btw, did you numerize the photos you took at FOSDEM ? I think we
should make a page with the photo we took for people that couldn't come.