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 ?
Raphael
On Tuesday, April 2, 2002, at 04:09 PM, Stefan Rieken wrote:
> Hi,
>
> 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
> Foundation classes)
> 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
> or whatever.)
> 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!
>
> Stefan Rieken
> --
> "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
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/help-gnustep
>
_______________________________________________
Help-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/help-gnustep
