From: Kevin W. <kw...@co...> - 2007-07-09 23:15:45
|
I'm dabbling with learning Cocoa/Objective-C, to extend my knowledge beyond Tk and to expand my development options given the uncertainty over TK-Aqua's Carbon foundation, and I'm struggling with some cognitive dissonance. Please bear with me. In following an example Cocoa application, I lay out my GUI in Interface Builder, including a tableview (the Cocoa analogue to a listbox). Then, I have to implement several methods to get the tableview to populate and display correctly: 1. Get the length of the table. - (int)numberOfRowsInTableView:(NSTableView *)tableView { return [[NSSpeechSynthesizer availableVoices] count]; } 2. Get the value of an item: -(id)tableView:(NSTableView *)tableView objectValueForTableColumn:(NSTableColumn *)tableColumn row:(int)row { NSString *voice = [[NSSpeechSynthesizer availableVoices] objectAtIndex:row]; return [[NSSpeechSynthesizer attributesForVoice:voice] valueForKey:NSVoiceName]; } 3. Check to see if the selection has changed: - (void) tableViewSelectionDidChange:(NSNotification *)notification { NSArray *availableVoices = [NSSpeechSynthesizer availableVoices]; int row = [tableView selectedRow]; if (row == -1) { return; } NSString *selectedVoice = [availableVoices objectAtIndex:row]; [speechSynth setVoice:selectedVoice]; NSLog(@"new voice = %@", selectedVoice); } These commands would achieve the same thing in Tk: 1. Get the length of the table. llength [.listbox get 0 end] (And this isn't even necessary to populate the listbox} 2. Get the value of an item: .listbox get [.listbox curselection] 3. Check to see if the selection has changed: bind .listbox <<ListboxSelect>> {some proc here} The cognitive dissonance I'm struggling with is the way Cocoa/Objective-C is marketed: as a "high-level toolkit," one vastly superior to the alternative toolkits out there, one that permits rapid development. From my perspective, it appears that a lot of code is needed in Cocoa to implement what comes with Tk by default. Omitting the "numberOfRowsInTableView" method from the tutorial application I'm studying yields an application that builds, but includes a blank table view. So the application requires it. Just as interestingly, the "numberOfRowsInTableView" code appears to be just as necessary in a scripting language that wraps Cocoa, such as Python, as from Objective-C. Here's a snippet from a PyObjC sample application: def numberOfRowsInTableView_(self, aTableView): #do stuff here So, this brings me to a question: By what standard is Cocoa a "high-level" toolkit/framework--especially when compared to Tk? I won't deny that Cocoa provides a richer range of Mac widgets than Tk does, even with Tile and script-level extensions such as BWidgets. I've done a lot with these components to make my own apps look, well, Mac-like, but spiffy UI effects, such as a native toolbar and gradients in the "unified" window view, do not seem to be available from Tk. Fair enough. But, in looking at Cocoa as a GUI alternative to Tk (because Carbon's days seem numbered), I see only increased complexity and less productivity than I currently have with Tk--and this is true whether I am talking about accessing Cocoa from the Objective-C level or Python. (I've worked with Tk from Python as well as Tcl, so I have some basis for comparison here.) I guess I'm just having a very hard time drinking the Cocoa kool-aid. Interface Builder does make it faster to lay out a GUI than Tk does, but visually drawing all the connections and actions and outlets makes callbacks a bit hard to keep track of. And it seems to me that you have to write a lot of glue code to implement the way things are presented in the GUI--stuff that can be handled in a single commands, such as tablelist's "sortbycolumn" command, or via bindings. (Cocoa Bindings are marketed as the best thing since sliced bread, but they look no different to me than Tk's binding mechanism.) I'm genuinely perplexed here, not to mention a little disappointed. Cocoa (regardless of the language it's accessed from) seems to me to be much lower-level than Tk. If you exclude the uncertainty over Carbon's future, I'm not sold at all on the advantages of using Cocoa as the basis for my development, such as porting my Python/Tk app to PyObjC (and my Tcl apps as well). Comments are appreciated. -- Kevin Walzer Code by Kevin http://www.codebykevin.com |