Re: Grasping Gorm

[Raphael Sebbe]

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
> Help-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-gnustep