[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Grasping Gorm

From: Raphael Sebbe
Subject: Re: Grasping Gorm
Date: 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
           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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]