Re: Proposition for a Gorm feature Was: Gorm too complex ?

[Pascal Bourguignon]

> Date: Mon, 11 Feb 2002 22:07:33 +0000
> From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
> 
> On Monday, February 11, 2002, at 08:41 PM, Pascal Bourguignon wrote:
> >
> >
> >> From: "Lars Sonchocky-Helldorf" <Lars.Sonchocky-Helldorf@bbdo-
> >> interone.de>
> >> Date: Mon, 11 Feb 2002 21:34:29 +0100
> >>
> >> No! Why: because hardcoded Interfaces might look ugly or be rendered
> >> unusuable on different Plattforms (that is in this case GNUstep and 
> >> Cocoa)
> >> I can show you some screenshots of GWorkspace on Cocoa that look really
> >> ugly (no Mac User would accept this). What you can do in such a 
> >> situation
> >> is ifdefing the geometrics or have a .nib file for Cocoa and a .gorm or
> >> .gmodel for GNUstep. Guess which solution is easier maintainable. 
> >> (even if
> >> converting nibs is a pain in the ass)
> >>
> >> Greetings, Lars
> >
> > He he ! Right.
> >
> > But  that's  one  more  problem  you have  with  InterfaceBuilder  and
> > Gorm. They store fixed coordinates in their NIB or gorm files.
> >
> > On the other hand, in my "hardcoded" interfaces, I make liberal use of
> > sizeToFit: and other automatic layout techniques.
> >
> > In the  end, it's less work because  I don't have to  do anything just
> > because some traducer added a  new localized strings file. As you have
> > it currently  with Gorm  and Interface builder,  you need to  tune the
> > interface even in that case. Too much work for me.
> 
> I've always found that interfaces produced that way look pretty poor -
> you still need to hand-tune after localisation to get decent appearance.
> 
> Also, it's not the case that you need to re-do nibs for different 
> languages
> all that much ... it's really just the same sort of tweaking either way.
> 
> The real difference is that with sizeToFit type schemes, you can get
> something *less* ugly when you do no work, not that you get something 
> good.
> 
> So I agree that it's good if you want to be lazy, but I wouldn't want to
> be *that* lazy - and by going down the sourcecode route you are throwing
> away an awful lot of big advantages for the sake of being able to put
> no work into one area.


That's worse than that. Not only I  don't want to have to edit NIBs or
GORMs by hand,  but I want to generate  the user interface dynamically
on the fly.

For example, when  accessing databases with EOF, I  don't want to have
to define  myself the user interface,  but have the  software build it
(selecting between  text, popup, check box, drag  areas, whatever, and
even grouping boxes, depending on the data at hand).

Ok, I guess we can stop here, it's no more on topic with Gorm.


-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------