discuss-gnustep
[Top][All Lists]
Advanced

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

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


From: Peron, Stéphane
Subject: RE: Proposition for a Gorm feature Was: Gorm too complex ?
Date: Tue, 12 Feb 2002 10:18:49 +0100

Hi !

Why not creating a converter ? :
an application that could convert a .gorm file in objective c files (.[mh] )
?

What do you think about ?

Stef




> > 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------
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep

Ce message contient des informations confidentielles ou appartenant au
Crédit Lyonnais et est établi à l'intention exclusive de ses
destinataires. Toute divulgation, utilisation, diffusion ou reproduction
(totale ou partielle) de ce message, ou des informations qu'il contient,
doit être préalablement autorisée. Tout message électronique est
susceptible d'altération et son intégrité ne peut être assurée.
Le Crédit Lyonnais décline toute responsabilité au titre de ce
message s'il a été modifié ou falsifié. Si vous n'êtes pas
destinataire de ce message, merci de le détruire immédiatement et
d'avertir l'expéditeur de l'erreur de distribution et de la destruction
du message.

This e-mail contains confidential information or information belonging
to Crédit Lyonnais and is intended solely for the addressees.
The unauthorised disclosure, use, dissemination or copying (either whole
or partial) of this e-mail, or any information it contains, is prohibited.
E-mails are susceptible to alteration and their integrity cannot be guaranteed.
Crédit Lyonnais shall not be liable for this e-mail if modified or falsified.
If you are not the intended recipient of this e-mail, please delete it
immediately from your system and notify the sender of the wrong delivery
and the mail deletion.

reply via email to

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