[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposition for a Gorm feature Was: Gorm too complex ?
From: |
Lars Sonchocky-Helldorf |
Subject: |
Re: Proposition for a Gorm feature Was: Gorm too complex ? |
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
Pascal Bourguignon <pjb@informatimago.com>
Sent by: discuss-gnustep-admin@gnu.org
11.02.2002 17:48
Please respond to pjb
To: discuss-gnustep@gnu.org
cc: richard@brainstorm.co.uk
Subject: Proposition for a Gorm feature Was: Gorm too complex ?
Right now, Gorm saves .gorm files that are GNUstep archives, therefore
an application developed with Gorm needs to be compiled and run on a
GNUstep system, or at least, on a system where gorm file reading
classes are ported to.
That is, it does exactly like InterfaceBuilder.
That's for this exact same reason that I'd try to avoid its use, and
prefer to write graphical user interface building code in Objective-C
in the sources of my OpenStep programs. It may be awkward, (until I
grab or write some class to do automatic layout), but at least, it's
portable : I can compile my OpenStep programs on OPENSTEP 4.2, on
GNUstep and on MacOSX.
Now suggestion:
Instead of writting archives of user interface objects, why not write
Objective-C source code, that would build this user interface net of
objects instead of unarchiving them.
I know that there is the difficulty of reading back this generated
source, to edit it from Gorm, because the programmer may have edited
the source form. There is no general solution here, but we can find a
good enough solution.
I can think of two broad classes of solutions:
- read and interpret the source. In this class of solutions, there
are several possibilities, from a very tight one such as:
- put delimiting comments around the source code generated,
and containing an encoded form of the user interface with
a checksum of the source code generated. When reading, if
the source code has been edited, put big warning and
caution dialogs asking whether changes should be
overwritten (or may be put in comments) when saving the
Gorm edited version.
And a more flexible one such as:
- just try and read the (special comment delimited) user
interace source code, and reject only stuff that's not
understandable as user interface building code. Harder,
but this too let the programmer edit or tune the user
interface in its source code form.
- compile the source and run it to build the user interface on the
fly and analyse it in Gorm. I think that's about what nib2gmodel
does. This solution would have the advantage of letting the
programmer edit quite freely the user interface building source
code.
More "conventions" may have to be enforced. Such as : having the user
interface building code in specific methods, or even in a special
category such as @implementation NSApplication(GormGenerated) (or
whatever class to which the user interface code can be attached), and
stored in separate files from the normal sources.
Note that InterfaceBuilder enforced that the actions be written
without any type. If you wrote -(id)myAction:(id)sender; instead of
-myAction:sender;, it would not be recognized as an action.
I would not mind using any specific tool if I can use the results of
this tool in whatever platform I need to later port and compile my
sources.
But never again will I use a tool such as Interface Builder, even if
it can reduce by ten the time needed, if I'm later locked with
it. That's the reason why I use freedom-enabled software in the first
place.
I know that having the sources of Gorm, I could compile it on other
OpenStep systems and use such ports to continue edit the gorm files,
but I think it would be even better with the proposed generation of
user interface in source code form.
--
__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
- Re: Proposition for a Gorm feature Was: Gorm too complex ?,
Lars Sonchocky-Helldorf <=