[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.
- RE: Proposition for a Gorm feature Was: Gorm too complex ?,
Peron, Stéphane <=