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

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Tcl-mac mailing list
tcl-mac@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-mac