Gorm FAQ

Should I modify the data.classes of file in the .gorm package?

   My advice is never to do this, ever.  Some have said that "they're plain text 
   and I should be able to change them".   My response to this rather weak rationale 
   is that if they are modified I cannot and will not guarantee that Gorm will be able 
   to read them or will function correctly if it does.

Why does my application crash when I add additional attributes for encoding in encodeWithCoder: or initWithCoder: in my custom class?

   If you've selected the custom class by clicking on an existing object and then 
   selecting a subclass in the Custom Class Inspector in Gorm's inspector panel, 
   then when the .gorm file is saved, Gorm must use what is called a template to 
   take the place of the class so that when the .gorm is unarchived in the running 
   application, the template can become the custom subclass you specified.  Gorm has 
   no way of knowing about the additional attributes of your subclass, so when 
   it's archived the template depends on the encodeWithCoder: of the existing 
   class.  Also, when AppKit loads the .gorm file, the initWithCoder: on the 
   subclass is called to allow the user to do any actions, except for additional 
   encoding, which need to be done at that time.  This is particularly true 
   when non-keyed coding is used, since, with keyed coding, it's possible to 
   skip keys that are not present.  The application may not crash if keyed coding 
   is used, but Gorm would still not know about the additional attributes and 
   would not be able to persist them anyway.

   Please see information in previous chapters regarding palettes, if you 
   would like to be able to add your classes to Gorm so that they don't 
   need to be replaced by templates, or proxy objects.

Why does Gorm give me a warning when I have bundles specified in GSAppKitUserBundles?

   Some bundles may use poseAs: to affect change in the existing behavior
   of some GNUstep classes.  The poseAs: method causes an issue which may
   cause Gorm to incorrectly encode the class name for the object which 
   was replaced.   This makes the resulting .gorm file unusable when 
   another user who is not using the same bundle attempts to load it.

How can I avoid loading GSAppKitUserBundles in Gorm?

You need to write to Gorm's defaults like this:

       defaults write Gorm GSAppKitUserBundles '()' 

Doing this overrides the settings in NSGlobalDomain for Gorm and forces Gorm not to load any user bundles at all. To eliminate this simply do:

       defaults delete Gorm GSAppKitUserBundles 

How can I change the font for a widget?

   This is a simple two step process.  Select the window the widget is
   in and then select the widget itself, then bring up the font panel 
   by hitting Command-t (or by choosing the menu item).  By doing this 
   you're making the window the main window and by selecting the widget, 
   you're telling the editor for that object to accept changes.   Then 
   you can select the font in the panel and hit "Set".  Remember to set 
   the pop up button to "As Selected Above".   For some objects, the 
   font panel isn't effective because those objects can't have a font directly 
   set.

Does Gorm use "fake" objects in the Gorm gui when building the model?

   No, it doesn't.  While it's true that Gorm proxies some of the custom 
   objects for the user in various ways described above in #2, Gorm uses 
   actual instances of most objects to do it's work.   Gorm utilizes special
   classes called Editors.  These editors wrap the actual instance and make 
   it possible for Gorm to modify aspects of those objects.   For instance,
   a button in a Gorm model is selected (i.e. knobs appear around it) when 
   the user selects it.   The knobs and the ability to change things about the
   selected button are enabled by the button editor.   Normally, the button
   would simply have been pressed.

Does Gorm itself encode/decode the objects in the .gorm file?

   Yes and no.  Gorm relies heavily on the use of NSArchiver and NSUnarchiver.
   These two classes are absolutely vital to Gorm's operation.  They facilitate
   the use of proxy objects described above which is essential to Gorm's function.
   All of the code for actually saving the objects in the model resides in AppKit.
   The method initWithCoder: and encodeWithCoder: (the NSCoding protocol) are
   implemented on every object in both gui and base which are capable of being
   encoded.   Gorm utilizes these methods and the above mentioned techniques to
   do it's job.