gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to set fixed culmn width in NSTableVeiw?


From: Nicola Pero
Subject: Re: How to set fixed culmn width in NSTableVeiw?
Date: Tue, 5 Mar 2002 08:41:11 +0000 (GMT)

> 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 ?

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


> > 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, 

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.



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

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.

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.

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]