[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This section will cover some topics which won’t be of general interest to most users. The details in this section pertain to the internal workings of Gorm.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The current Gorm file format is basically just a set of objects, encoded one after another in a continuous stream with some markers indicating when a new class starts or which class is encoded.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Each object in the .gorm file has a name assigned to it by the application. This allows Gorm to refer to the objects by a name once they are loaded rather than an address. Each name is associated with it’s object in a dictionary which preserves the overall structure of the GUI which has been created.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This is only used when the user has associated a custom class with an existing instance in the gorm file. If the user has, for instance, added an NSWindow to the gorm, he/she can use the custom class inspector to select a subclass of NSWindow to change to.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This array is used to form the connections after the .gorm file is loaded. The method ‘[... establishConnection]’ is never called on either NSNibControlConnector or NSNibOutletConnector objects while in Gorm. This prevents the connections from having any effect while they are being edited in Gorm itself. Once they are loaded, the establishConnection method is called and the connections are made.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Custom objects are an interesting challenge in Gorm. By definition, custom classes are not known to Gorm, unless they are in a palette (covered elsewhere). For classes which are not in a palette instances of these classes in Gorm are encoding in one of three ways:
All custom instances have awakeFromNib invoked on them when they are unarchived from the .gorm file. This allows the user to do whatever additional setup that needs to be done, such as setting attribute. Classes which are “known” are, of course, directly encoded into the .gorm file.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The restrictions here are the same as those in Apple’s InterfaceBuilder. In general, you cannot have additional information which is expected to be decoded in an initWithCoder: method from a custom class which uses one of the methods in the previous section. This is because, by definition, Gorm doesn’t know anything about these classes and allowing you to use them in Gorm in this way is a convenience to make it simpler for the developer. Gorm therefore, must use one of the proxies to encode the class since it cannot encode the class directly.
How can you get your classes into Gorm, you say? I’m pleased that you asked me that question. The best way to make your class known to Gorm so that you don’t need to worry about the above restriction is to add a palette which contains your class. In this way, because you’re literally linking the class into Gorm, you’re making the class and it’s structure known to Gorm so that it can encode the class directly. With the new palette loaded you can load and save classes containing real instances, not proxies, of your class encoded directly in the .gorm file. How to create a palette is discussed at length in the following section.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You are, by now, familiar with the built in palettes which are provided with Gorm. Palettes are a powerful feature which allows the developer to add his/her own objects to Gorm. It is possible for a developer to write custom inspectors, editors and palettes for use with Gorm. A good example of a custom palette is palettetest in the dev-apps/test in the GNUstep distribution. Assuming you don’t have that, however, I will explain precisely what you need to do in order to create a simple palette. The entire process is very short and suprisingly simple. First open Gorm and selection Gorm->Document->New Module->New Palette. This will create a palette sized window. Once that’s done go to the classes view in the main document window and find “IBPalette” in the class list. Create a subclass of that, the name can be whatever you want. For the purposes of our example we’ll call it MyPalette. Drag a custom view to the window and choose the class you would like to add to the palette from one of your custom classes.
Once you’ve done this, generate the code for the classes (discussed in previous chapters). In the code, you’ll add a method called “-(void) finishInstantiate” leave it empty for now. In the makefile for the palette make sure that the library or framework the view comes from is linked with the palette. Now build the palette.
After the palette is built you’re ready to load it into Gorm. Go to the preferences panel and go to “Palettes”. This should bring up a table view. Click on add. You should see a open dialog open. Select the palette bundle with this. If the palette is successfully loaded, you should see the name appear in the list. One thing to note here. Once a palette is loaded, it can’t be unloaded until you close and restart Gorm. This is because by loading the palette bundle, the code in the bundle is being linked into Gorm. This can’t be undone, once it’s done.
Now, you should see the palette in the set of palettes in the palette window. Simply scroll over to it and select it’s icon. When you do this, you should see the view that you set up using the custom view displayed as an actual instance. Note that we used one of the techniques listed above, it is possible to use any of the three for any object you add to your palette. You can now drag the view from the palette to a new window.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You may recall the creation of a method called “-(void) finishInstantiate” in the previous section. This section will make full use of that method. Re-open the palette you created before, but this time add an image view to the window. Then add to the image view, the icon you want to represent the non-graphical object. Here you’ll need to add an ivar to the MyPalette class in both Gorm and in your source code called, imageView. Once you’ve done this make the connection between the image view and it’s ivar.
Assuming that the class is called “NonUIObject”, in finish instantiate, you’ll need to add the following line of code:
id obj = [NonUIObject new];
[self associateObject: obj type: IBObjectPboardType with: imageView];
This code has the effect of associating the non-ui object with the ui object you just added to represent it. When you drag and drop the element which prepresents the object to something, it will copy the object, not the ui element, to the destination.
Congratulations, you now know how Palettes work.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by root on July 23, 2013 using texi2html 1.82.