Re: Resizing of subviews

[nicola]

> While digging into a problem with the resizing of a text view inside a
> scroll view, I did get the impression that our current implementation of
> the resizing of sub views works only for a single sub view, that fills
> out
> all of its super view.

Ahm - the current implementation of autoresizing is pretty well tested,
and it does precisely what the OPENSTEP doc says it should do.

The advantage of the OPENSTEP autoresizing is that it is quite simple, and
doesn't require additional objects (the traditional hboxes and vboxes) to
manage the position of views.  But - being so simple, this autoresizing
mechanism is not suited to complex windows and/or complex autoresizing
behaviours.  Probably I might suggest that the idea of OPENSTEP is also
that - contrary to the habit of the toolkits which are fashionable
nowadays - windows should not be crowded with tons of widgets and so
extremely complex autoresizing stuff should not be needed at all.

Anyway, I implemented a full set of classes for GNUstep - GSHbox, GSVbox,
GSTable - which provides a complete autosizing/autoresizing engine which
can work with arbitrary complex autoresizing stuff.  It should be pretty
easy to use if you have ever used hboxes and vboxes in some other toolkit.
It is heavier than the traditional OPENSTEP stuff (it will probably nearly
double the number of view objects in your window) of course, but it
shouldn't make much of a difference nowadays.

It is also very useful if you are building window layouts without an
interface builder.  A GSHbox will put its views in a line, and a GSVbox
its views in a row, automatically managing borders computing resulting
sizes autoresizing etc so that you can build window layouts in the way you
do with gtk, without hard-coding anything in the source code, and if you
change the size or the font of your labels (or translate your app in
another language), everything will automatically be adjusted to the new
sizes.

The other amazing feature of the GSHbox, GSVbox and GSTable is that they
are finished and have no known bugs, a thing which I am very proud of. :-)

I have documented everything in
core/gui/Documentation/gnustep-gui.tmpl.texi.


> When a view gets its frame changed, all the sub views get a call to the
> method resizeWithOldSuperviewSize: with the old size of the super view.
> Now every sub view tries to resize itself to the full change of the
> super view.

That's correct.

> If there are more than one sub view or if the sub view does not
> fill up the full size of its super view, that resizing will be to much.

Make sure you set correctly the autoresizingMask of each view which is
involved in autoresizing.

> (As can be seen by make a text view with restricted width inside of a
> scroll view and making that scroll view first wide and than small
> again.)

This is a completely different case.

Roughly - you wouldn't use a scrollview if you wanted what is inside the
scrollview to resize when the scrollview is resized.

What is inside the scrollview should not be resized at all when you resize
the scrollview.  Instead, more (or less) of what is inside should be
shown, and the scrollbars adjusted accordingly.

If you are trying to make a text view with a restricted width inside of a
scrollview, I think what you need to do is: put inside the scrollview a
simple view covering as much space as you want to cover, then put inside
this view your text view, with the origin shifted and the size you want it
to have (the text view will then not cover the whole of the standard
view).  And again, when you resize the scrollview, nothing should happen
to the size of the normal view, and consequently nothing should happen to
the size of the text view.

Hope my comments help.