Re: ANN: Gorm Version 0.1.0

[Nicola Pero]

> Hi,
> 
> I tried to make the resizing behave like it does on MOSX and OS4.2.
> On those two systems, sizeToFit does not resize the column so that the
> header titles fit, it justs make all the headers the same size, so that's
> what I tried to implement in GNUstep (with a few enhancements)

Ok - I don't have an apple system to test - I was assuming the contrary,
since their documentation says that they resize the columns so that they
are enough big to display both headers and values in the columns (but it
then maybe contradicts itself in the next sentence :-).

In general, the idea of -sizeToFit is that it sizes the object so that it
can display comfortably its contents (it changes the size so that it fits
the contents).  This is the general idea of the method at least.  It's
very useful when you build GUIs from source code, because you create an
object (a button, a textfield, a matrix, a table) with zero size, put some
contents into it, then call -sizeToFit and the object sizes itself to
enough big to display comfortably the contents, but not more.  You then
pile up objects using boxes, and get the final GUI without having
hardcoded a single size in the original source - everything is dynamically
computed.  Which is also nice because if you just translate the strings,
the stuff sizes itself automatically according to the language.  This is
how gtk and qt work by the way - it's nice to have the option of using
gnustep-gui this way as well, for people so inclined.

I know, if you do things using Gorm, you rarely use -sizeToFit (unless
Gorm itself use it ... I suppose there is already an option to do that -
you put a matrix somewhere, then write into it, then call sizeToFit and
the matrix is resized to exactly fit the contents).

Anyway in brief, I think all this general idea applies to table views as
well.  If you use Gorm, you probably never call -sizeToFit anyway in your
user code.  If you build interfaces by hand instead, you want -sizeToFit
to size the table so that it can display it contents comfortably.

So - yes - even if they don't size the columns to fit the headers, I think
we should.  I'm not sure about the values in the columns ... just because
if the table reprensents for example a database result set, the set might
be huge, and iterating over the set might be awfully slow.  I suppose in
that case the programmer should simply avoid calling -sizeToFit :-) or
call it before attaching the data source to the table.

Hmmm - yes - perhaps we should consider also the values in the columns.


> Although I am not opposed to Nicola's idea, i believe it won't be very
> useful once NSTableView is perfectly integrated in Gorm.app.

As you explained in the other email, it probably won't make any difference
to the problem that Nicolas Roard is having :-)

But ... sooner or later we might try to add support for boxes in Gorm ...
the gtk builder (glade or whatever the name) supports that ... and build
stuff using Gorm, but have it all autosize when the .gorm is loaded. at
that point, having a good -sizeToFit for all gui elements might be useful.  
I still see as an advantage that if you build GUIs using boxes and
-sizeToFit, translating the Localizable.strings file translates the whole
app, without having to build new .gorm files for each language (which is
by the way how gtk, qt and everything translates their GUI programs - they
only translate the strings, since the actual sizes of all GUI objects is
dynamically computed and can dynamically accomodate different strings).