Re: Question about gorm and Multi language support in Gnustep

[Nicola Pero]

> > The rope/spring model of determining how views resize themselves, which is
> > implemented in Gorm, should be enough to prevent the overlapping you're
> > referring to. 
> > 
> > I've never had an issue with preventing buttons or views from overlapping 
> > when
> > resizing.
> > 
> 
> You are missing the point - we are not talking about arranging subviews as
> a consequence of a change in the superview size - which is covered by
> OpenStep, even if in a very simple/primitive form (only simple
> arrangements can be configured using the springs).
> 
> We are talking about resizing superviews and readjusting subviews
> positions when the *subviews* size change.  There is simply no API to do
> that in OpenStep, and there is no support for it unless you write it
> yourself.

Sorry - I guess I have been obscure - which is not something to be proud
of - I'll try explaining more clearly with an example.  :-)

Say that you have a window.  At the bottom you've got two buttons: 'Start'
and 'Stop'.  That might be what your Gorm file creates when you load it.

Now at runtime you change the string of the first button translating it
into some weird language, and it becomes "Ausrejwsllllwmwppdkcm", and you
call [firstButton sizeToFit]; to make sure the button is big enough to
display the whole string.  Unfortunately, the first button now becomes so
big that it going over/overlapping the second button - not a pretty view.

So, you want to fix that ... but there is no API to fix that automatically
in OpenStep, except yourself writing code to manually reading the button
coordinates, and manually moving the buttons into the right position, and
probably resizing the whole window to fit the bigger space now taken by
the buttons.

There is no API because the OpenStep subview autoresizing machinery works
top-to-bottom: when the user resizes the window, the subview autoresizing
machinery trasmits this change from superview to subview (top to bottom),
rearranging everything.

If you translate the string in a button, instead, you are in a completely
different situation - you would like a bottom-to-top autoresizing: you
would like the change to trasmit from subview to superview (bottom to top)  
up to the window, rearranging everything.  In OpenStep this case is 
completely ignored.

I suppose you could attempt to extend OpenStep and the spring system with
an additional API which works bottom-to-top.

But I think, given that the spring system is not that advanced (complex
cases can't be managed with it), and IMO is only friendly/intuitive when
you have a single subview, because the spring system is really
establishing a relationship between a subview and its direct superview,
and that's not quite the way you think when you are organizing many views
- in that case you tend to think in terms of relationships between the
sibling views (eg, the buttons must be in a row at equal distance) rather
than between each view and its direct superview, so using springs becomes
sort of a mental game as you need to translate your own idea of what you
want (a row of buttons) into spring relationships between each button and
the superview.

Anyway, given all those, if we need to extend the API to support
bottom-to-top, it really seems a good idea just to rewrite the whole lot
differently, stressing the coupling of siblings in containers (rows or
columns) rather than just sibling/superview, and then adding general
bottom-to-top APIs in that framework - which is what Renaissance does.