discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Question about gorm and Multi language support in Gnustep


From: Nicola Pero
Subject: Re: Question about gorm and Multi language support in Gnustep
Date: Fri, 30 May 2003 15:33:15 +0100 (BST)

> > > > > But, no, there really is no need to create one .gorm per language.
> > > > >[...]
> > > > >     [applyButton setTitle: Localize(@"Apply", nil)];
> > > > >     [closeButton setTitle: Localize(@"OK", nil)];
> > > 
> > > Add:   
> > >         [applyButton sizeToFit:self];
> > >         [closeButton sizeToFit:self];
> > > 
> > > (and perhaps sending sizeToFit: to all super views and window...)
> > 
> > Yes - that would be possibly better ... but still not completely
> > satisfying unless the super views are custom views which act as containers
> > and implement sizeToFit to arrange the views they contain so that they
> > don't overlap etc.
> > 
> > Otherwise, when you resize the applyButton, it might get so big as to
> > overlap over the closeButton - it depends on the window of course, but as
> > a general rule, you need some sort of container superview aware of the
> > issue and keeping buttons (in this example, other views in other examples)  
> > aligned/in position/in row/column/etc.
> > 
> > Writing such superviews I'm sure is well in *your* capabilities :-) but
> > might be a bit too clumsy/difficult for someone less experienced and/or
> > wanting to write simple code quickly.
> > 
> > Renaissance does indeed provide container classes which are automatically
> > setup and configured ... then calling [xxx sizeToFitContent], as you
> > describe, on all views, would do the trick.  But if you're using
> > Renaissance, that's done for you automatically as well if needed :-)
> > 
> 
> 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.

Renaissance implements it.





reply via email to

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