[MacRuby-devel] Problem with a window controller

Thu Dec 6 09:42:02 PST 2012

Hi David,

It does take time to learn to use IB. IB was first presented to me in a small group by none other than Apple employee #1 Steve Wozniak in a small demonstration of the first Mac OS running on a Next Step black box in Tysons Corner, VA. I don't recall the year. In his demo he created an entire text editor application in about 5 minutes. He was working too fast for me to follow everything that he was doing but I still think of that demo when I am hooking up links in IB. I could tell that he was very proud of Xcode and IB.

As you become more familiar with IB, you will probably do more initialization of objects in IB and less in MacRuby. Nib file expansion instantiates objects and then makes calls to initialize the objects using the same methods that you are using to initialize objects in MacRuby. Actually, in a large application, it would difficult to hook up all of the outlets without using IB.

You mentioned an attr_accessor :window in AppDelegate. Although you could reference a window in AppDelegate for a small single window application, you should follow the prescribed object hierarchy and inheritance by always referencing you windows through an NSWindowController instance which could be instantiated in the Main XIB for a single window app. Following the prescribed object hierarchy becomes more important as the application grows and you get into restorable windows and App Sandboxing. Then you will need more of the functionality provided by NSWindowController.

One really big problem with MacRuby though is the poor performance in scanning source files for IB outlets. I think MacRuby is great for large application development, but when my app grows to several hundred source files, I have to take a break while I'm waiting for outlets to appear in IB. I recall early releases of MacRuby where a keyword was required to identify an IB outlet as is done in Objective C, but that was changed to have all MacRuby accessors appear as IB outlets. That can be confusing when hooking things up in IB.

So the IB support performance is the biggest issuer that I have with MacRuby.

Bob Rice

On Dec 5, 2012, at 2:45 AM, david kramf <dakr.012 at gmail.com> wrote:

> Hi Bob
> I still have to get used to the IB. One of the things I find confusing is that after I define something using the IB I don't see the  generated code . I think that initially I will rely less on the IB and more on the code.
> Many Thanks,
> David.
> 
> On Dec 4, 2012, at 9:19 AM, Robert Carl Rice wrote:
> 
>> Hi David,
>> 
>> AppDelegate doesn't inherit from NSWindowController so you would need a MacRuby outlet to obtain a link to the Main Menu window or any other object instantiated in the NIB, but usually you don't need this. This outlet doesn't need to be named "window". You could rename it to something like :mainMenuWindow to be less confusing. Usually you would add additional outlets to change controls within the Main Menu. These outlets don't need to be in an NSWindowController  subclass. The attr_writer or attr_accessor pre-processor macros will define a class variable that you would reference with a leading "@".
>> 
>> If you instaintiate a subclass of NSWindowController by adding an object to the XIB that you assign to your own subclass, then NSWindowController will automatically add an IB outlet for "window" to your subclass that you would normally "hookup" in IB to your own subclass of NSWindow instantiated by the same NIB. You should not create MacRuby accessors for "window" in an NSWindowController subclass rather you use the self.window superclass method. The @window class variable should be undefined in your NSWindowController subclass . Cocoa does not define MacRuby class variables; only MacRuby code can do that. You would only get the same NSWindow instance for both your AppDelegate and your NSWindowController subclass if you connect both your AppDelegate and your NSWindowController subclass to the same window in IB.
>> 
>> Bob Rice
>> 
>> 
>> On Dec 4, 2012, at 1:25 AM, david kramf <dakr.012 at gmail.com> wrote:
>> 
>>> Hi Bob
>>> I never programmed in Objective-C.
>>> When I open a MacRuby project I automatically get a window attar_accessor defined in my AppDelegate created code, but not in the controller which I write by my own. If I connect, using  IB , the window to my controller parameter (object variable) , I get the same window property created both in my WindowController and in the appDelegate. So far during my plays with the code I don't encounter any other problem apart from the willLoad and didLoad delegates which I expected to be called . Since the @window variable is already instantiated when my awakeFromNib is called, I have a feeling that the Cocoa code already called them before he created MyController class. I am not sure about that , since this reasoning leads to a conclusion that this is some kind of a bug in Cocoa , but Cocoa exists for a long time and used a lot , so I am not sure.
>>> Since this is the only problem I faced so far , I decided to move on and be careful upon relying on these 2 delegates.
>>> Thanks, David.
>>>  
>>> On Dec 4, 2012, at 2:06 AM, Robert Carl Rice wrote:
>>> 
>>>> Hi David,
>>>> 
>>>> You should consider the "window" Objective C property to be "owned" by NSWindowController and it's confusing to define a Ruby class variable with the same name. It should automatically appear as an IB outlet for your NSWindowController subclass that you would "hook up" in IB just as you would a MacRuby outlet assuming that you instantiate your NSWindowController subclass with the same NIB with your NSWindow.
>>>> 
>>>> As per the NSWindowController documentation, you would read the window property using the method window() or self.window which will first load the window if it not already loaded.
>>>> 
>>>> You could set the window property using setWindow( window ), but normally you have NIB expansion call setWindow.
>>>> 
>>>> Similarly NSWindow automatically defines the delegate property that you can hook up to your window controller in IB assuming that you instantiate your NSWindowController subclass with the same NIB with your NSWindow.
>>>> 
>>>> I removed a lot of initialization code from my applications once I better understood how NIB file expansion works. You can hook up most of your delegates and target actions in IB. You can even initialize static Popup and comboBox option lists in IB. However, don't hookup dataSource in IB for NSTableView or NSOutlineView because it will attempt to load table data before you get awakeFromNib.
>>>> 
>>>> Bob Rice
>>>> 
>>>> On Dec 3, 2012, at 1:35 AM, david kramf <dakr.012 at gmail.com> wrote:
>>>> 
>>>>> Hi Bob
>>>>> My code crashes if I omit the attr_accessor. 
>>>>> Can you refer me to instructions of how to configure the IB to link to my controller as delegate (?) . In the examples I have in my book  and ,if I am not mistaken, lectures I viewed in iTunes U ( the Stanford series ), they all used the awakeFromNib as point of initialization .
>>>>> Thanks, David 
>>>>> On Dec 3, 2012, at 6:24 AM, Robert Carl Rice wrote:
>>>>> 
>>>>>> Hi David,
>>>>>> 
>>>>>> A couple of things I notice offhand in you code:
>>>>>> 
>>>>>> The NSWindowController class defines accessor methods for "window" so you shouldn't redefine it with the Ruby attr_accessor method. Note: similarly NSViewController defines accessor methods for "view".
>>>>>> 
>>>>>> You can configure IB to link the window delegate when the Nib is expanded so that you don't need to set it in awakeFromNib.
>>>>>> 
>>>>>> Bob Rice
>>>>>> 
>>>>>> 
>>>>>> On Nov 29, 2012, at 6:50 PM, david kramf <dakr.012 at gmail.com> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> Hi, 
>>>>>>> In the copied below code only the awakeFromNib is executed . Can someone explain me what do I do wrong ?  Window is displayed and I expected all other methods to be called.
>>>>>>> Thanks, David
>>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> MacRuby-devel mailing list
>>>>>> MacRuby-devel at lists.macosforge.org
>>>>>> http://lists.macosforge.org/mailman/listinfo/macruby-devel
>>>>> 
>>>>> _______________________________________________
>>>>> MacRuby-devel mailing list
>>>>> MacRuby-devel at lists.macosforge.org
>>>>> http://lists.macosforge.org/mailman/listinfo/macruby-devel
>>>> 
>>>> _______________________________________________
>>>> MacRuby-devel mailing list
>>>> MacRuby-devel at lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo/macruby-devel
>>> 
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> MacRuby-devel at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo/macruby-devel
>> 
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo/macruby-devel
> 
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macruby-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20121206/f6dd0c5e/attachment.html>