On Jul 9, 2007, at 7:15 PM, Kevin Walzer wrote:

>  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).
> 

Ahhh, I wish I were young again...

I retired 5 years ago and started programming in Cocoa as a way to  
pass the
time of day ( My sixty-ninth birthday is only a few weeks away...).

I started having problems with Cocoa when "Cocoa Bindings" first  
appeared, I
could not seem to grasp the "high concept" and the cocoa implementation.

One of my quibbles with Cocoa is that it hid too much of the machine  
from the
programmer ie one had to drop down into Carbon in order to get at the
nitty gritty parts of the file system and other parts of the hardware.

I think you are being a bit hard on the NSTableView, a comparison with
Tk's TkTable or the WxPython Grid would be more appropriate. In fact
having experience with the Cocoa TableView made using the WxPython  
grid control fairly
easy :)

I think that Cocoa Bindings are more sophisticated that Tk's binding a
variable to an interface element.

After getting burned out on Cocoa I decided to try Tcl/Tk ( I had bought
Ousterhouts book several years before I retired and decided to give it
a try).

The cool thing about Tcl/Tk is the utter simplicity of the language,  
once
you get the basic principles it becomes a super tool for quick app  
development
and is fairly efficient. I bought a "PC" laptop a couple of years ago
and turned it into a dual WinXP/Fedora box and with Tcl/Tk I could write
applications across all three platforms with almost *no* changes. It
was nirvana for a while...

I started getting the feeling that Tcl/Tk development was slowing due
to (my perception) the lack of a large user base which in turn put
pressure on the core developers. When was the last time you saw a Tcl
book in a bookstore?

In addition my retention abilities are fading...Tcl does not impose
much structure and my code was becoming more "messy".

I then turned to Python+Tkinter and found that the deeply embedded
object methodology forced me to approach problems in a much more
structured manner. I feel a bit more comfortable nowadays writing
Python and have recently turned to WxPython because the GUI looks
nicer that Tkinter on all three basic platforms. (there are some
warts on the Mac WxPython side however...)

Kevin, don't worry, be happy :)

Use whatever tools are available, learn whatever you can!

This is advice from a guy who was *sure* Dec's VMS was going
to conquer the world and live happily ever after.

Tools come tools go...

Jerry








-------------------------------------------------------------------------
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