[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposition for a Gorm feature Was: Gorm too complex ?
From: |
Pascal Bourguignon |
Subject: |
Re: Proposition for a Gorm feature Was: Gorm too complex ? |
Date: |
Tue, 12 Feb 2002 00:39:20 +0100 (CET) |
> 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------