[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Grasping Gorm
Re: Grasping Gorm
Tue, 2 Apr 2002 16:55:25 +0200
Not easy to get, at first.
Basically, the language mecanism that is needed (to handle classes not
in the frameworks -- read on for more) is a way to access instance
variables from their name. The Objective C runtime has that.
How it works actually:
- AppKit objects you want to store in gorm files know how to encode
(serialize) themselves by implementing the NSCoding protocol.
- Custom subclasses are handled differently, because even if they
implemented NSCoding, Gorm has no access to the (compiled) code (well
except for palettes, but that's another story). So a proxy is used, it
retains the object class name/outlet name-connections pairs and at
runtime, a "true" object of that class is created and the connections
re-made using the ObjC runtime mecanism described above.
Is that clear enough ?
On Tuesday, April 2, 2002, at 04:09 PM, Stefan Rieken wrote:
I'm a developer used to by-hand programming and for my own mental sanity
I'm trying to get a grasp of how Gorm works. I don't mean of how to use
it, but of how things that you make with it actually *compile and work*.
I'm having a little trouble understanding it, so maybe I'd best write
down what I think I know, then you may tell me how far I'm off with
reality, if you wish %)
OK, here goes:
1. Gorm lets you put together an UI out of a static list of UI
object classes that it supports (according to reading between
the lines of the Gorm docs)
2. Gorm lets you create new classes by inheritance from a list
of existing classes (probably a static list of AppKit and
3. Gorm uses black magic to connect the new classes instance
variables (here referred to as "outlets", why is that?) and
methods ("actions") to buttons, text fields, etc.
4. The user can now save a .gorm file. It will be put away
somewhere in the .app dir after installation. It contains all
kind of magic stuff that GNUstep understands to produce
objects, classes and UI's just like you said in Gorm.
5. At runtime, GNUstep's NSApplicationMain () and friends do all
kinds of black magic to autodetect any .gorm file and load
it. (May I conclude that because of this, Gorm has a mean
advantage over other hypothetical UI builders because it is
supported at the core of the GNUstep system? Or, in other
words, that Gorm and GNUstep (resp. InterfaceBuilder and
OpenStep) are as inseperatable as MS Windows and MS Internet
Explorer? Hey, just asking, not directly meaning this is bad
6. GNUstep now uses REALLY black magic to connect the outlets to
the UI components. How does it do this? There are no methods
in the user-built class that send the contents of any of the
"outlet" instance variables to any other object. As far as
I've learnt OO and Objective-C, there's NO way for the UI
objects to get these instance variables if there's no method
for it (e.g. [rectangle length]). How how how?
7. The program starts working, you know, running the compiled
ObjC code and stuff. Now from here, I understand it again :-)
Please explain to me what all this "magic" is about. Thanks!
"What? We didn't order a pizza!"
"It's not a pizza, it's a BOMB."
"We didn't order a bomb, either." -- Penny Arcade
Help-gnustep mailing list