Re: Grasping Gorm

[Nicola Pero]

> 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.

It contains the objects, serialized, and the connections between objects,
serialized as well.

'serialized' just means that the objects are saved in binary form in the
file with all their instance variables.  you can then de-serialize the
objects from the file, which just means loading the objects from the
binary file.  You find that in gnustep-base NSCoder, NSArchiver,
NSUnarchiver.

The connections are stored in objects as well.  Each connection is
represented by a special object.  To save the connections in the file, the
connection objects are serialized just like other objects are.


>         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.)

Not really.  Loading a .gorm file is trivial - it's just one line of code
basically.

It's trivial to load a different hypothetical (maybe not so hypothetical
;-) UI.  Just a couple of lines in your application source loading the UI
from a different source. (of course you need to have implemented a library
able to manage this different UI source).

There is already a different UI source, which is the Model library (which
uses a different format than .gorm, called .gmodel).  Other ones will
follow.

The .gorm one *is* somewhat special but for a different reason, that it is
using the encoding/decoding (ie, serializing/deserializing) support built
in the gnustep-gui library itself, while other UI tools, like gmodel,
normally provide their own.  So, the loading/saving of .gorm is somewhat
built into the library itself, while loading/saving of other formats must
be provided outside the library.  Incidentally, this makes impossible to
run .gorm files on another OpenStep system ... they are intrinsically
bound to gnustep-gui and only gnustep-gui can run them.  Other OpenStep
libraries (eg, the Apple OS X AppKit) can load/save gui objects into
files, but the format it stronly dependent on the specific library ... so
Apple OS X AppKit has its own gorm-like format, which is called .nib, and
you can only run nibs on Apple OS X AppKit, and not on gnustep.


>         6. GNUstep now uses REALLY black magic to connect the outlets to
>            the UI components. How does it do this?

Each connection is stored in an object.  The connection object is able to
connect the components by using a technique called key-value coding (Even
if it doesn't exactly call the key-value coding methods in gnustep-base,
that is what it is doing - the concept, and the implementation, is the
same).  So, once the file is loaded, the connections are asked to
establish the connections, and they do so by using key-value coding.

You find key-value coding in gnustep-base NSKeyValueCoding.h: the main
methods are -takeValue:forKey: and -valueForKey:.

The connection objects are stored in the .gorm file, and when the .gorm
file is opened, the connection objects are recreated from the file as
well.

You find all the code doing that in gnustep-gui NSBundleAdditions.