Difference between revisions of "Gorm FAQ"

From GNUstepWiki
Jump to navigation Jump to search
(Fixed formatting to look more like the other FAQs)
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
1) Should I modify the data.classes of file in the .gorm package?
+
=== 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  
+
: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.
    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.
 
  
2) Why does my application crash when I add additional attributes for encoding in encodeWithCoder: or initWithCoder: in my custom class?
+
=== 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  
+
: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.
    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  
+
: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.
    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.
 
  
3) Why does Gorm give me a warning when I have bundles specified in GSAppKitUserBundles?
+
=== Why should I be careful when using Gorm with GSAppKitUserBundles? ===
  
    Some bundles may use poseAs: to affect change in the existing behavior
+
: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.
    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.
 
  
4) How can I avoid loading GSAppKitUserBundles in Gorm?
+
=== How can I avoid loading GSAppKitUserBundles in Gorm? ===
  
'''You need to write to Gorm's defaults like this:'''
+
:You need to write to Gorm's defaults like this:
 +
defaults write Gorm GSAppKitUserBundles '()'  
  
        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  
  
'''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:'''
+
=== How can I change the font for a widget? ===
  
        defaults delete Gorm GSAppKitUserBundles
+
: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.
  
5) How can I change the font for a widget?
+
=== Does Gorm use "fake" objects in the Gorm gui when building the model? ===
  
    This is a simple two step processSelect the window the widget is
+
:No, it doesn'tWhile 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 EditorsThese editors wrap the actual instance and make it possible for Gorm to modify aspects of those objectsFor 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 editorNormally, the button would simply have been pressed.
    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 changesThen
 
    you can select the font in the panel and hit "Set"For some
 
    objects, the font panel isn't effective because those objects can't
 
    have a font directly set.
 
  
 +
=== Does Gorm itself encode/decode the objects in the .gorm file? ===
  
6) Does Gorm use "fake" objects in the Gorm gui when building the model?
+
: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.
  
    No, it doesn't.  While it's true that Gorm proxies some of the custom
+
=== Who should release the top level objects? ===
    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.
 
  
7) Does Gorm itself encode/decode the objects in the .gorm file?
+
:After the .gorm file is finished loading, all of the top level objects should have a retain count of one.  It is the responsibility of the File's Owner/NSOwner to release these objects. The NSOwner, as previously described, is usually the controller class which loaded the file.  In the case of NSWindowController, the window controller should release all of the top level objects for you.
  
    Yes and no.  Gorm relies heavily on the use of NSArchiver and NSUnarchiver.
+
=== Why doesn't Gorm/GNUstep read nib files? ===
    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.
+
:Until recently, the format of the NeXT nibs has been simply a serialized binary. Now that Apple's nibs are XML based using the NSKeyedArchiver and NSKeyedUnarchiver, it makes it easier to reverse engineer the format and allow GNUstep and Gorm to read the nib files.
    All of the code for actually saving the objects in the model resides in AppKit.
+
 
    The method initWithCoder: and encodeWithCoder: (the NSCoding protocol) are
+
:The older, non-xml, serialized format really isn't a "format" as much as it is a byte stream.   Part of the issue is that the data encoded in the nibs is strongly tied to the implementation of each control.   Additionally, each control has serveral versions and it's possible for different versions to be combined.  So, in order to reverse engineer this we would need to understand the internal implementation of each and every control and know in what sequence each of it's attributes is stored as well as implement every version of each control and make whatever corrections need to be made when loading an older version into a newer implementation, etc ,etc.  Add to this that Apple/NeXT would likely change the encoding of some classes between each version and may even change the internal implementation, which would require a full investigation into all of the classes to ensure that our encoding matches for every version of every class.
    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
+
:With the keyed nibs, this is no longer an issue.  Forward and backward compatibility is possible with them and it eases the burden each time there is a new releaseThe Gorm maintainer and others are currently, as of this writing, working on implementation of modern XML nib support in GNUstep.
    do it's job.
+
 
 +
[[Category:FAQ]]

Latest revision as of 16:58, 8 September 2006

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 should I be careful when using Gorm with 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.

Who should release the top level objects?

After the .gorm file is finished loading, all of the top level objects should have a retain count of one. It is the responsibility of the File's Owner/NSOwner to release these objects. The NSOwner, as previously described, is usually the controller class which loaded the file. In the case of NSWindowController, the window controller should release all of the top level objects for you.

Why doesn't Gorm/GNUstep read nib files?

Until recently, the format of the NeXT nibs has been simply a serialized binary. Now that Apple's nibs are XML based using the NSKeyedArchiver and NSKeyedUnarchiver, it makes it easier to reverse engineer the format and allow GNUstep and Gorm to read the nib files.
The older, non-xml, serialized format really isn't a "format" as much as it is a byte stream. Part of the issue is that the data encoded in the nibs is strongly tied to the implementation of each control. Additionally, each control has serveral versions and it's possible for different versions to be combined. So, in order to reverse engineer this we would need to understand the internal implementation of each and every control and know in what sequence each of it's attributes is stored as well as implement every version of each control and make whatever corrections need to be made when loading an older version into a newer implementation, etc ,etc. Add to this that Apple/NeXT would likely change the encoding of some classes between each version and may even change the internal implementation, which would require a full investigation into all of the classes to ensure that our encoding matches for every version of every class.
With the keyed nibs, this is no longer an issue. Forward and backward compatibility is possible with them and it eases the burden each time there is a new release. The Gorm maintainer and others are currently, as of this writing, working on implementation of modern XML nib support in GNUstep.