Re: Is there an NSCollectionView selection change notification?

[Markus Spoettl]

On May 18, 2008, at 11:43 PM, Jens Alfke wrote:
Does this look OK, especially, is removeObserver: in dealloc: not  
too late?


Yup, that looks fine.


Excellent, thanks!

Regards
Markus
--
__
Markus Spoettl



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSStream, NSInputStream, NSOutputStream

[Jens Alfke]

On 18 May '08, at 9:19 PM, John MacMullin wrote:

I think that all one needs to do is to write one byte in the  
"external" function, then handle the rest of the writes through the  
delegate NSStreamEventHasSpaceAvailable event.


You don't even need to do the one byte externally. Your delegate will  
be told there's space available as soon as the socket's opened.


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Is there an NSCollectionView selection change notification?

[Jens Alfke]

On 18 May '08, at 10:18 PM, Markus Spoettl wrote:

Does this look OK, especially, is removeObserver: in dealloc: not  
too late?


Yup, that looks fine.

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Erik Buck]

FROM : Peter Duniho
DATE : Mon May 19 07:03:25 2008

[deleted]
Real people are having real problems getting into Cocoa.  I don't see
the kind of repeated commentary about poor documentation and
difficult APIs in the C#/.NET forums or Java forums.  It comes up
once in a blue moon, but not with the reliability I've seen here, nor
is there nearly the kind of practiced, organized defense seen here
(which again suggests a certain regularity to the complaints).
That's odd.  I see endless complaints about WPF and Microsoft's half  
hearted support and poor documentation.



[deleted]
There's no question in my mind that Cocoa is a nice framework, and
that the entire environment provides some good productivity-enhancing
features.  But it's also clear that those benefits are only really
available to someone who has already invested a lot of effort in
learning it.  The "rule of least surprise" doesn't apply; maybe it
does to the framework, but not to the documentation and definitely
not to the tools.
The exact same thing could be said about object oriented programming.   
The benefits are only really available to someone who has already  
invested a lot of effort in learning it.  Object oriented patterns are  
very surprising to people who haven't learned the basics, so I guess  
the "rule of least surprise" doesn't apply to object oriented  
programming.



I contrast that with my experiences moving to C#/.NET and Java from
the Win32 C++ world.  Now, at least with .NET it is true that to some
extent, I benefitted from having a fair amount of Win32 expertise.
Some of the paradigms map closely, and that helped.  But there's a
lot in .NET that is entirely new, and that was easy and fun too.  And
Java was completely foreign to me when I started using it.  In
neither case did I find myself feeling like I'd just entered a whole
new world where, until you had gone through the entire hazing
process, one could never really be effective as a programmer.
Let's see... C++, Java, and C# all share very similar syntax.  All are  
strongly typed bondage and discipline languages.  Two wrap the Win32  
you already knew and the other has three commonly used GUI frameworks  
that are all primative and "lowest common denominator" meaning that  
you were unlikely to find anything surprising.


Here are some interesting comparisons between Cocoa and .Net from  
the .Net Addicts Blog: http://dotnetaddict.dotnetdevelopersjournal.com/tags/?/cocoa



[deleted]
I'd love to see the Mac succeed as a platform.  But frankly, I think
you already have to be a pretty hard-core Mac fan, and _really_ want
to see your software on the Mac, to be motivated to spend a lot of
time with Cocoa.  Until programming in Cocoa is fun for _everyone_,
not just the few who have made it through the gauntlet, I don't see
it attracting a large following.
Many of us love Cocoa _in spite of_ Apple.  I have been using NeXTstep/ 
Openstep/YellowBox/Cocoa since 1988 which was 2+ years before Windows  
3.1 was released with all of the glories of Win16.  Apple acquired the  
technology that became Cocoa, stopped selling its predecessors, and  
sat on it for 7 to 10 years with no significant enhancement and some  
downgrades.


Furthermore, Java was in part inspired by Objective-C. See [http://virtualschool.edu/objectivec/influenceOnJava.html 
]  for quotes from Patrick Naughton, JamesGosling, and BillJoy. The  
early Java frameworks were lobotomized versions of Openstep.  C# was  
created so that Microsoft could own something like Java after embrace  
and extend was halted in court.  C# is incrementally better than Java  
as second systems often are.



[deleted]
As an example, I found myself wanting to exclude an area from my
clipping region.  Nothing complicated: I had a rectangular area, and
I wanted to draw everywhere _except_ a specific sub-rectangle.  The
docs were quite prideful as to how, since Cocoa clipping uses the
NSBezierPath, you have practically infinite control over clipped.  No
doubt this boasting was reasonably accurate (*).  [deleted]

(*) And that's another thing...nowhere else have
I seen documentation that wastes so much time
explaining why _their_ API and paradigm is superior.
Why all the proselytizing?  Just tell me how to get
the damn job done!  I get it...Apple thinks that
there's no better way to write software than using
Cocoa.  Stop hitting me over the head about it!

Great!  We have other posters complaining that the documentation  
doesn't explain "why" often enough.  I am glad you were able to figure  
out a 2D graphics system that is identical to PDF and has existed in  
Postscript and text books for 30+ years.  I am not sure Cocoa  
documentation is the best place to learn about general 2D graphics,  
winding rules, bezier paths, graphics contexts, etc.  I think you  
might find interesting similarities in WPF too.



[deleted]
For that matter, why is the entire NSBezierPath API based on
"append"?  Why isn't there 

Re: Cocoa et al as HCI usability problem

[Graham Cox]

Yes, it's not available pre 10.5

G.


On 19 May 2008, at 4:31 pm, Andrew Merenbach wrote:

Is there any reason to use the cast on cbbox, instead of using  
NSRectFromCGRect(cbbox)


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Andrew Merenbach]

Is there any reason to use the cast on cbbox, instead of using  
NSRectFromCGRect(cbbox), which does the same thing but wraps it up  
nicely in an easy-to-read fashion?


From the docs:


NSRectFromCGRect
Returns an NSRect typecast from a CGRect.


NSRect NSRectFromCGRect(CGRect cgrect) { return (*(NSRect  
*)&(cgrect)); }


Return Value
An NSRect typecast from a CGRect.

Declared InNSGeometry.hSee Also
• NSRectToCGRect
• NSPointFromCGPoint
• NSSizeFromCGSize



Cheers,
Andrew

On May 18, 2008, at 11:20 PM, Graham Cox wrote:

For clipping tasks like this, NSBezierPath is a very poor cousin to  
Apple's old technology for this - Regions. With regions one could  
trivially obtain union, intersection, difference and xor of complex  
shapes using the built-in APIs. Neither NSBezierPath nor the  
underlying Quartz routines it calls upon have the equivalent  
operations. OK, Regions were intrinsically pixel-oriented (scanline)  
entities and maybe it's just too hard to offer this sort of thing  
generically with bezier paths, but I for one feel this is a glaring  
hole in the functionality of Quartz (and, since the rasterizing code  
*already* has to search for self-intersections and so on, in fact  
the private code must be very close to having an implementation of  
this right there - they just need to clean it up, flesh it out and  
make a public API for it).


For the case of excluding an area from the clip region you can  
eventually force it to do the job by combinations of winding rules,  
path reversals and appends, but for other graphics work these are a  
very blunt instrument. The "append" terminology is the only one  
NSBezierPath has because that's all it can do - append more paths.  
It cannot subtract ("remove") one path from another. If the paths  
intersect you can get an xor or a union effect depending on the  
winding rule, but never a subtraction. It's a royal PITA.


Here's one method I have in a category on NSBezierPath that *might*  
address the clipping situation that you have. However, since there's  
no public method to GET the current context's clip path, this works  
using the bounding box of that path instead, which may not be  
applicable in every case. Once again, I know there's a private API  
for this but for some inexplicable reason, Apple do not expose it in  
the public headers, even though without it this sort of thing is  
downright awkward, yet commonly required.


- (void)addInverseClip
{
	// this is similar to -addClip, except that it excludes the area  
bounded by the path instead of includes it. It works by combining  
this path
	// with the existing clip area using the E/O winding rule, then  
setting the result as the clip area. This should be called between

// calls to save and restore the gstate, as for addClip.

	CGContextRef	context = [[NSGraphicsContext currentContext]  
graphicsPort];

CGRect cbbox = CGContextGetClipBoundingBox( context );

	NSBezierPath*	cp = [NSBezierPath  
bezierPathWithRect:*(NSRect*)&cbbox];

[cp appendBezierPath:self];
[cp setWindingRule:NSEvenOddWindingRule];
[cp setClip];
}


G.

On 19 May 2008, at 3:03 pm, Peter Duniho wrote:

As an example, I found myself wanting to exclude an area from my  
clipping region.  Nothing complicated: I had a rectangular area,  
and I wanted to draw everywhere _except_ a specific sub-rectangle.   
The docs were quite prideful as to how, since Cocoa clipping uses  
the NSBezierPath, you have practically infinite control over  
clipped.  No doubt this boasting was reasonably accurate (*).  And  
yet, even as it hints tantalizingly at the idea that there's a way  
to do this (see "Modifying the Current Graphics State"), it doesn't  
quite get you there.



I was finally able to, after reading documentation in three  
different places that discuss NSBezierPath, connect the dots so to  
speak and figure out how the heck to get NSBezierPath to do what  
the docs hinted it could do.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/andrew.merenbach%40ucla.edu

This email sent to [EMAIL PROTECTED]




smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Graham Cox]

For clipping tasks like this, NSBezierPath is a very poor cousin to  
Apple's old technology for this - Regions. With regions one could  
trivially obtain union, intersection, difference and xor of complex  
shapes using the built-in APIs. Neither NSBezierPath nor the  
underlying Quartz routines it calls upon have the equivalent  
operations. OK, Regions were intrinsically pixel-oriented (scanline)  
entities and maybe it's just too hard to offer this sort of thing  
generically with bezier paths, but I for one feel this is a glaring  
hole in the functionality of Quartz (and, since the rasterizing code  
*already* has to search for self-intersections and so on, in fact the  
private code must be very close to having an implementation of this  
right there - they just need to clean it up, flesh it out and make a  
public API for it).


For the case of excluding an area from the clip region you can  
eventually force it to do the job by combinations of winding rules,  
path reversals and appends, but for other graphics work these are a  
very blunt instrument. The "append" terminology is the only one  
NSBezierPath has because that's all it can do - append more paths. It  
cannot subtract ("remove") one path from another. If the paths  
intersect you can get an xor or a union effect depending on the  
winding rule, but never a subtraction. It's a royal PITA.


Here's one method I have in a category on NSBezierPath that *might*  
address the clipping situation that you have. However, since there's  
no public method to GET the current context's clip path, this works  
using the bounding box of that path instead, which may not be  
applicable in every case. Once again, I know there's a private API for  
this but for some inexplicable reason, Apple do not expose it in the  
public headers, even though without it this sort of thing is downright  
awkward, yet commonly required.


- (void)addInverseClip
{
	// this is similar to -addClip, except that it excludes the area  
bounded by the path instead of includes it. It works by combining this  
path
	// with the existing clip area using the E/O winding rule, then  
setting the result as the clip area. This should be called between

// calls to save and restore the gstate, as for addClip.

	CGContextRef	context = [[NSGraphicsContext currentContext]  
graphicsPort];

CGRect cbbox = CGContextGetClipBoundingBox( context );

NSBezierPath*   cp = [NSBezierPath bezierPathWithRect:*(NSRect*)&cbbox];
[cp appendBezierPath:self];
[cp setWindingRule:NSEvenOddWindingRule];
[cp setClip];
}


G.

On 19 May 2008, at 3:03 pm, Peter Duniho wrote:

As an example, I found myself wanting to exclude an area from my  
clipping region.  Nothing complicated: I had a rectangular area, and  
I wanted to draw everywhere _except_ a specific sub-rectangle.  The  
docs were quite prideful as to how, since Cocoa clipping uses the  
NSBezierPath, you have practically infinite control over clipped.   
No doubt this boasting was reasonably accurate (*).  And yet, even  
as it hints tantalizingly at the idea that there's a way to do this  
(see "Modifying the Current Graphics State"), it doesn't quite get  
you there.



I was finally able to, after reading documentation in three  
different places that discuss NSBezierPath, connect the dots so to  
speak and figure out how the heck to get NSBezierPath to do what the  
docs hinted it could do.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Accessing variables across classes

[Adam Leonard]

Hi,
What you are doing is probably bad design. I would recommend your read  
up on the MVC (Model View Controller) pattern: http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/chapter_5_section_4.html


In your set up, the ApplicationDelegate is your controller, the  
NSMutableArray's are your models, and your NSView's are obviously your  
views.


What you probably want to do is add accessor methods or properties to  
your NSView for these NSMutableArrays. For an example of these  
accessors, see http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaViewsGuide/SubclassingNSView/chapter_6_section_5.html#/ 
/apple_ref/doc/uid/TP40002978-CH7-SW34


Then, in your ApplicationDelegate, you would just call [myView  
setFoo:myMutableArray].
That way, ApplicationDelegate is fully fulfilling its role as a  
controller: connecting your models (myMutableArray) to your view  
(myView).



Adam Leonard


On May 18, 2008, at 10:03 PM, Joey None wrote:


Hello all,

I hope someone can help me with this.

I have my ApplicationDelegate which contains a couple of  
NSMutableArrays with data in them.


Then I have a few CustomNSViews classes which I have sub-classed.

I need to access the NSMutableArrays declared on the AppDelegate  
class from the NSView sub-classes I have created.


Any ideas on how to do this? I know there has to be a way and have  
spent all night looking for it but so far no luck.


Thank you very much for all your help!
JC



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/adam%40caffeinatedcocoa.com

This email sent to [EMAIL PROTECTED]



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Accessing variables across classes

[Andrew Merenbach]

On May 18, 2008, at 10:22 PM, Andrew Farmer wrote:


On 18 May 08, at 22:06, Brett Powley wrote:

MyAppDelgate *ad = [NSApp delegate];
then do something with [ad myMutableArray]


Incorrect. You don't get accessors for instance variables  
automatically like that.


To the original poster, there are three approaches you can go with  
here.


One is to set the variables as @public in the ApplicationDelegate,  
then access them as applicationDelegate->theArray. This breaks  
encapsulation, but it works.


Another approach is to write accessor methods on the  
ApplicationDelegate to return the arrays and use those. This  
requires some extra code.


Finally, if you're targeting Leopard, you can use properties. These  
can be put together without any extra code, and they don't break OO  
like @public variables do.



Although the last method -- with properties -- would be my favored  
approach on Leopard, the OP wanted to work with *mutable* arrays.   
There have been some threads on this in the past (available in the  
archives), but basically you have to specify, basically, either  
retain, assign, or copy for your properties -- mutableCopy is *not*  
available.  This means that, should you wish to make a mutable copy  
when setting your property, you'll still have to create an accessor.   
That may or may not be a bad thing in this case, but it might not save  
any code.


Cheers,
Andrew


smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Accessing variables across classes

[Brett Powley]

On 19/05/2008, at 3:22 PM, Andrew Farmer wrote:


On 18 May 08, at 22:06, Brett Powley wrote:

MyAppDelgate *ad = [NSApp delegate];
then do something with [ad myMutableArray]


Incorrect. You don't get accessors for instance variables  
automatically like that.


Well yes, but I assumed that his problem was that he didn't know how  
to get at the application delegate from his views, not that he didn't  
know how to write accessors.  (How do you know that myMutableArray  
isn't an accessor method anyway?)



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Accessing variables across classes

[Andrew Farmer]

On 18 May 08, at 22:06, Brett Powley wrote:

MyAppDelgate *ad = [NSApp delegate];
then do something with [ad myMutableArray]


Incorrect. You don't get accessors for instance variables  
automatically like that.


To the original poster, there are three approaches you can go with here.

One is to set the variables as @public in the ApplicationDelegate,  
then access them as applicationDelegate->theArray. This breaks  
encapsulation, but it works.


Another approach is to write accessor methods on the  
ApplicationDelegate to return the arrays and use those. This requires  
some extra code.


Finally, if you're targeting Leopard, you can use properties. These  
can be put together without any extra code, and they don't break OO  
like @public variables do.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Is there an NSCollectionView selection change notification?

[Markus Spoettl]

On May 18, 2008, at 8:36 PM, Jens Alfke wrote:
I've started playing with NSCollectionView and everything worked  
out beautifully (custom views, selection state handling for items  
etc.). One thing I can't figure out is how my application/document  
gets notified about a change of selection.


If you bind the collection view to an NSArrayController, you can  
observe the controller's selection-related properties, either  
programmatically or by using bindings in IB. For example, you can  
bind a button's "enabled" property to the controller's "canRemove",  
to enable the button only when there's a selection.


Up until now I've tried to stay away from manual KVO, the complexity  
of things is overwhelming as it is. However, I have to say it's rather  
elegant and works perfectly for this case. Just to be sure I did  
things right, this is what I came up with:


@implementation MyCollectionViewController

- (void)dealloc
{
[arrayController removeObserver:self  
forKeyPath:@"selectedObjects"];

[super dealloc];
}

-(void)awakeFromNib
{
[arrayController addObserver:self forKeyPath:@"selectedObjects"
 options:NSKeyValueObservingOptionNew  
context:nil];

}

- (void)observeValueForKeyPath:(NSString *)keyPath
  ofObject:(id)object
change:(NSDictionary *)change
   context:(void *)context
{
// do whatever necessary here
}

Does this look OK, especially, is removeObserver: in dealloc: not too  
late?


Thanks for you help!

Regards
Markus
--
__
Markus Spoettl

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Accessing variables across classes

[Brett Powley]

MyAppDelgate *ad = [NSApp delegate];
then do something with [ad myMutableArray]

Cheers,
Brett


On 19/05/2008, at 3:03 PM, Joey None wrote:


Hello all,

I hope someone can help me with this.

I have my ApplicationDelegate which contains a couple of  
NSMutableArrays with data in them.


Then I have a few CustomNSViews classes which I have sub-classed.

I need to access the NSMutableArrays declared on the AppDelegate  
class from the NSView sub-classes I have created.


Any ideas on how to do this? I know there has to be a way and have  
spent all night looking for it but so far no luck.


Thank you very much for all your help!
JC



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/brett 
%40process.com.au


This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Peter Duniho]

From: ben syverson <[EMAIL PROTECTED]>

This is going to sound bitchy, but it's hard for me to have any
sympathy for vague complaints about the docs or the usability of
Cocoa.


That does sound bitchy.  I mean, it's fair enough to say that people  
ought to be providing specific feedback and constructive complaints.   
But to have _no_ sympathy?  That's harsh.


Real people are having real problems getting into Cocoa.  I don't see  
the kind of repeated commentary about poor documentation and  
difficult APIs in the C#/.NET forums or Java forums.  It comes up  
once in a blue moon, but not with the reliability I've seen here, nor  
is there nearly the kind of practiced, organized defense seen here  
(which again suggests a certain regularity to the complaints).


I had a big long reply (even longer than this one :) ) written to  
Julius's initial post under this subject and detailing many of my  
concerns and complaints about Objective-C, Cocoa, and the  
documentation, but decided the better of posting it.  However, I'll  
say this: I agree that at least for me, the fundamental issue is that  
from a "usability" point of view, Objective-C, Cocoa, and the  
associated documentation leave something to be desired.  I found  
Julius's comments regarding "usability" to be right on the mark, at  
least in the general sense.


There's no question in my mind that Cocoa is a nice framework, and  
that the entire environment provides some good productivity-enhancing  
features.  But it's also clear that those benefits are only really  
available to someone who has already invested a lot of effort in  
learning it.  The "rule of least surprise" doesn't apply; maybe it  
does to the framework, but not to the documentation and definitely  
not to the tools.


I contrast that with my experiences moving to C#/.NET and Java from  
the Win32 C++ world.  Now, at least with .NET it is true that to some  
extent, I benefitted from having a fair amount of Win32 expertise.   
Some of the paradigms map closely, and that helped.  But there's a  
lot in .NET that is entirely new, and that was easy and fun too.  And  
Java was completely foreign to me when I started using it.  In  
neither case did I find myself feeling like I'd just entered a whole  
new world where, until you had gone through the entire hazing  
process, one could never really be effective as a programmer.


.NET and Java were _fun_.  They are still fun.  I love writing code  
for either platform.  I ported one simple .NET application to Cocoa  
and haven't had any interest in writing any more Cocoa code at all.   
I'd love to see the Mac succeed as a platform.  But frankly, I think  
you already have to be a pretty hard-core Mac fan, and _really_ want  
to see your software on the Mac, to be motivated to spend a lot of  
time with Cocoa.  Until programming in Cocoa is fun for _everyone_,  
not just the few who have made it through the gauntlet, I don't see  
it attracting a large following.


Those who love the Mac, and who love Cocoa, ignore this kind of  
feedback, provided to them on a regular basis, at their peril.


[...] But I can't think of a single time when I've been unable to  
figure out

where to look for guidance on a problem, or have been unable to
interpret that guidance.


For what it's worth, it's not (to me) a matter of not being able to  
figure it out at all.  It's how much effort is required to figure it  
out.


MSDN is sprinkled with code samples.  Everywhere.  Granted, some of  
them are kind of silly, and some of them are just plain wrong.  But  
on the whole, they are pretty good.  More to the point, they exist  
for pretty much _every_ documented API element.  Class methods,  
properties, events, fields.  All have a dedicated doc page that  
includes some sample code (in many cases, a single sample is shared  
among multiple elements...but that's just efficient doc writing).


Contrast to the Cocoa docs, where a single class is documented in  
just one web page, with practically no sample code at all and  
incredibly brief descriptions of each element.


Oddly enough, the same complaint can be made for Sun's docs for Java,  
but I haven't found that to be nearly as great a degree of a problem  
there.  It's hard for me to put my finger on exactly what the  
difference is, but I'd guess that at least partly it has to do with  
the fact that Sun's docs include frames with navigation panes that  
help orient you within the API, so that as you jump around you have  
some idea of what classes are related to what and why.  The Java  
tutorials also seem more to the point.


I know that given time, I can figure pretty much anything out.  But  
in the Cocoa docs and API, it can sometimes be a real chore.


As an example, I found myself wanting to exclude an area from my  
clipping region.  Nothing complicated: I had a rectangular area, and  
I wanted to draw everywhere _except_ a specific sub-rectangle.  The  
docs were quite prideful as to 

Accessing variables across classes

[Joey None]

Hello all,

I hope someone can help me with this.

I have my ApplicationDelegate which contains a couple of NSMutableArrays with 
data in them.

Then I have a few CustomNSViews classes which I have sub-classed. 

I need to access the NSMutableArrays declared on the AppDelegate class from the 
NSView sub-classes I have created. 

Any ideas on how to do this? I know there has to be a way and have spent all 
night looking for it but so far no luck.

Thank you very much for all your help!
JC


  
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: XML schema support

[Stuart Malin]

As best as I understand, the NSXML* classes are build on libxml, but  
even so, there isn't, to my knowledge, any schema support exposed in  
Cocoa by these classes. However, the good news is that you should  
have libxml on your machine.


Todd Ditchendorf's XML Nanny performs Schema and RELAX NG valdation.  
Earlier this year he "open-sourced" (BSD license) the code:

http://www.ditchnet.org/wp/2008/01/11/xml-nanny-now-open-source/

Separately, please be advised that, from my experience, NSXMLParser  
is not SAX-like. While it is event-driven, it is not suitable for  
parsing streams. I use the expat parser (libexpat) to handle  stream  
parsing.



On May 18, 2008, David wrote:



Is there a Cocoa package that supports XML schema for either event  
driven

(SAX like) or tree based (DOM like) XML parsing?
I haven't seen any reference to XML schema for either Cocoa  
packages other

than a statement saying you can do your own validation.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSStream, NSInputStream, NSOutputStream

[John MacMullin]

Jens and Ken:

Thank you for your  responses.  I believe I now understand in part as  
to what is happening as to the streams.  Let me take the output  
"trigger" first.  The Stream Programming Guide states:  "if the  
delegate receives an NSStreamEventHasSpaceAvailable event and does  
not write anything to the stream, it does not receive further space- 
available events from the run loop until the NSOutputStream object  
receives more bytes."   This may answer the question of the  
"trigger", which is I now believe is simply the write statement.   
That means that instead of doing a polling loop outside of the  
delegate, (or doing writes inside the NSStreamEventHasBytesAvailable  
section of the delegate during reads) I think that all one needs to  
do is to write one byte in the "external" function, then handle the  
rest of the writes through the delegate  
NSStreamEventHasSpaceAvailable event.  That should be a lot easier  
than doing a custom polling loop and trying to resolve the space  
available issues outside of the delegate.  In other words, it seems  
that the delegate should do it for you after doing a one byte write.


I'll let you know how it works out.  And I will address the other  
questions after I have tested this issue.


Best regards,

John

On May 18, 2008, at 11:10 AM, Jens Alfke wrote:



On 18 May '08, at 8:50 AM, John MacMullin wrote:

I modified slightly the Echo Server code sample from Apple with  
the following results.  One, I couldn't stream a large file from a  
polling routine.  More than likely it would cancel because of a  
Sigterm 15.


Whenever you report a crash, a backtrace is very helpful. Or at  
least tell us what function/method the crash was in. This shouldn't  
crash, so the problem is probably in something in your code.


It appears from reading the docs that the user cannot detect the  
end of a stream and that the NSStreamEventEndEncountered only  
detects a close.


"End of stream" and "close" are the same thing: a TCP input stream  
ends when the other side closes the connection (or crashes...)


Two, when unarchiving a file in a client input stream delegate  
method, if the stream terminated from the server because it was  
too large, the client terminates on an unarchiver error because it  
didn't get the whole stream.


A stream won't ever terminate due to length. You can send gigabyte  
after gigabyte over a TCP stream, as many happy BitTorrent users  
can attest ;-)


But yes, if the incoming stream closed before sending all the data  
the reader needed, then I would expect the reader to report an  
error. This shouldn't cause a crash, though; it sounds like your  
code isn't handling the error gracefully.


Third, the output stream methods shown in Echo Server are polling  
methods, not delegate methods.


The CocoaEcho sample? I just looked at it, and you're right. The  
writing code is badly designed. The client will block in a 'while'  
loop until all the data is sent, and the server code will simply  
drop response data on the floor if there isn't room to send it. I  
just filed feedback on the web page for the sample.


1. How do I stream a large file between connections or is NSStream  
the wrong tool?  Can the stream size be modified?


Most of the CocoaEcho code is reasonable as a base for doing this.  
Rip out the server-side code that echoes the data back, and instead  
write the data to a file.


On the client/sender side, it's best to use the 'spaceAvailable'  
delegate call, as you said. In response to that call, read some  
data from the file into a buffer, then write it to the stream.  
Something like 4k will do. Pay attention to the return value of the  
write, which tells you how many bytes actually got written, and  
advance a file-position instance variable by that amount. That'll  
tell you the position to read from in the input file next time.



2. What is the largest stream size?


There isn't one. TCP was designed to handle arbitrary length  
streams. There are internal byte counters but they just wrap around  
harmlessly after 4GB.


3. Is it possible to detect a valid archive before I unarchive it,  
or do I simply have to intercept the exception?


No. If you have data in archive format, you have to just hand it to  
NSUnarchiver and wrap the call in @try/@catch.


But you said you were sending a file? In that case you should just  
send it as a stream of bytes. If you're reading the entire file  
into an NSData and then sending that with NSArchiver, that's a huge  
amount of overhead for no gain.


4. How does one trigger and make available a file an output stream  
so that the delegate methods can be used?	


I don't understand that question. Can you give more detail? (Or  
perhaps I answered it above under #1.)


—Jens


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa

Re: Cocoa et al as HCI usability problem

[Nathan Kinsinger]

Some people have said they didn't know where to start (or their  
questions lead myself and others to believe that is the case).


One of the conceptual documents that I found most useful was the Cocoa  
Fundamentals Guide

http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/Introduction/chapter_1_section_1.html

Even if you know OO programming (or maybe especially if you do) you  
should read it to find out how cocoa uses OO. Depending on your  
background it is possible that some OO concepts that cocoa uses are  
the same as what you've used before but it was called AAA and cocoa  
calls it BBB.


Don't worry if you don't understand everything at first, just work  
with what you do. I would also suggest that after you've been  
programming with cocoa a month or two you go back and read it again.  
And maybe even again after that. Keep doing that until you read it and  
go "yeah done that", "that too", "and that". You can download the PDF  
and use Preview to read it (preview has the advantage of remembering  
that last page you were on) or print it out if you learn better off of  
dead trees.


As for the order of what to learn there is a good post by Chris Hanson  
about it

http://www.cocoabuilder.com/archive/message/cocoa/2007/6/4/184167

This is similar to the path I've taken and it works (actually, still  
in the Cocoa Bindings part and haven't had a reason to start Core Data  
at this point).


Just for those who may need some help finding the conceptual  
documentation (obviously most people on this list know this but I  
thought I'd state the obvious for those just firing up Xcode for the  
first (or second) time), first on the API pages there is usually  
(thought not always) an item at the bottom of the box in the upper  
right corner called Companion Guide that deals with the info for that  
API.
In general the conceptual docs are called guides, so you won't find  
them by searching for 'conceptual'. The people on this list refer to  
them as conceptual but Apple calls them guides. To look for all of  
them in the Xcode documentation window select the 'Title', 'Core  
Library', and 'Contains' tags under the toolbar and type 'guide' in  
the search box.
The search field here is pretty basic, you only get one search term so  
you won't, for example, get to search for 'guide cocoa' as it will  
look for the full string not two separate strings. The google powered  
search at http://developer.apple.com/ will do better but will not be  
limited to the titles, for example.


I don't have a CS degree and would qualify, as one poster deridingly  
called early mac programmers, as a hobbyist. I have approached  
learning cocoa seriously and actually study it; via the documentation,  
books, open source code, example code, programmer blogs, this lists  
archives, creating test projects, and working on a full application  
(slowly, this all comes out of my spare time after all).


Yes it would be nice if the docs could explain every api in exactly  
the way that I am going to need to use it but that is not realistic.  
At this point I am confident that for most any cocoa (or even non  
cocoa) api I can use it from the api reference and the guides when I  
need to. Things really do start making sense.


Anyway, interesting thread and sorry for rambling.
--Nathan
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: XML schema support

[Jens Alfke]

On 18 May '08, at 7:07 PM, David wrote:

Is there a Cocoa package that supports XML schema for either event  
driven

(SAX like) or tree based (DOM like) XML parsing?
I haven't seen any reference to XML schema for either Cocoa packages  
other

than a statement saying you can do your own validation.


I don't think any of the high-level APIs handle schema, unless I've  
overlooked something. But then, I've never found a need to use schema/ 
validation in any of my own XML-related code.


You might need to drop down to the libxml2 API, which is in C but  
seems to do basically everything (the other APIs are implemented atop  
it.)


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Is there an NSCollectionView selection change notification?

[Jens Alfke]

On 18 May '08, at 7:41 PM, Markus Spoettl wrote:

 I've started playing with NSCollectionView and everything worked  
out beautifully (custom views, selection state handling for items  
etc.). One thing I can't figure out is how my application/document  
gets notified about a change of selection.


If you bind the collection view to an NSArrayController, you can  
observe the controller's selection-related properties, either  
programmatically or by using bindings in IB. For example, you can bind  
a button's "enabled" property to the controller's "canRemove", to  
enable the button only when there's a selection.


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: validateMenuItem() not always being called

[Jens Alfke]

On 18 May '08, at 8:05 PM, [EMAIL PROTECTED] wrote:


I wasn't, but when I did, it still was only called for the File menu.



Any object's validateMenuItem method is only called for menu items  
that would message that object if they were invoked. That means:

* Menu items whose target directly points to that object
* Menu items whose target is "first responder", and your object is on  
the responder chain and implements the item's action method.


Maybe you should tell us which command(s) aren't being validated that  
you think should be?


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa bindings and reluctance to use NSPopupButon

[Brett Powley]

On 19/05/2008, at 12:38 PM, Andreas Mayer wrote:



Am 19.05.2008 um 04:03 Uhr schrieb mmalc crawford:


Which is exactly what the documentation takes pains to tell you.


I guess it's just not clear enough. There should be a big red  
warning box:


"Don't try to use Core Data or Cocoa Bindings unless you are an  
experienced Cocoa programmer and understand - and have used - all  
the underlying technologies."


The problem is that we tend to be seduced by slick WWDC demos which  
show us how to write the next Adobe Photoshop in 15 minutes with zero  
lines of code, using Interface Builder, Core Data, and Cocoa  
Bindings :-)


Of course I exaggerate, but my experience has been that there is quite  
a lot of understanding that goes into knowing what to connect to what,  
that isn't at all apparent until you try to do it yourself.  You may  
be able to do cool things with zero lines of code, but it often takes  
a long time to write those zero lines.


I think one of the issues is that one of the normal sources of  
inspiration - sample code - often isn't really tahat useful for things  
done using Interface Builder.   Seeing things already nicely connected  
up doesn't tell you why they're done that way, and also doesn't tell  
you about the other subtly-different-but-wrong ways of doing things.


Maybe the only way to do it is to work your way up to your own  
personal "aha" moment by spending days getting a popup button to work  
(I've been there too).


Brett




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Michael Vannorsdel]

Nothing wrong with saying "you should read such and such".  But RTFM  
is the condescending way of saying it (just look what it stands for).   
Would be like asking someone where the restroom is and getting "look  
at the building directory, you blind clueless moron".  My point was  
about posts that are belittling and snipe because the question was  
simple.



On May 18, 2008, at 8:42 PM, Andreas Mayer wrote:

Actually, I don't understand why an RTFM kind of answer is perceived  
as rude. I'm really happy when I get an RTFM *with a link* to the  
appropriate document.


Also, I often just don't answer at all, since an RTFM may not be  
well received and I don't have the time to write a more elaborate  
answer. Oh well.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: validateMenuItem() not always being called

[Kyle Sluder]

On Sun, May 18, 2008 at 11:05 PM,  <[EMAIL PROTECTED]> wrote:
> The example "SimpleToolbar" has a validateMenuItem method in MyDocument.m
> and it too only gets
> called for the File menu but the Edit menu is properly updated for Cut, Copy
> and Paste.
> I guess NSTextView handles it.

Correct.  NSText responds to -cut:, -copy:, and -paste:, and since
NSTextView derives from NSText, its -validateUserInterfaceItem: method
is called when the menu and toolbar items with these actions need to
be updated and an NSTextView has the focus.  (Insert description of
the field editor and such here.)

Re-read the documentation about the responder chain, and make sure you
fully understand it.  It's one of the most powerful aspects of AppKit,
and it's really fricken cool to boot.  For me, it meant no more
gigantic switch statements that I was used to in Win32 programming.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Stuart Malin]

On May 18, 2008, at 3:56 PM, [EMAIL PROTECTED] wrote:


On Sun, May 18, 2008 at 8:41 PM, Julius Guzy
<[EMAIL PROTECTED]> wrote:
Well, there is a problems with the documentation and if it does  
not get
resolved then people will end up unable to write the code. I mean  
what is
the point in loosing people who actually want to program this  
machine and

are willing to put oodles of effort into doing it?


There's been a lot of discussion on the list lately about how Cocoa
has been so hard for people to learn, but not a lot of useful
specifics or follow-up. People haven said "the API is bad because it
refers to all these terms you're already supposed to know and I don't
know them!", and then when someone says "Did you read the conceptual
documentation?" the response is a resounding... silence. I think this
is part of why those veteran Cocoa developers are often less than
sympathetic.


I would self-describe myself as a newbie, and feel compelled to chime  
in on this discussion. The odd thing is, one can read the conceptual  
docs and not see what is obvious to others, In my own experience, in  
the very beginning, I would wend my way through the conceptual docs  
dull eyed - yes, I was reading words, but the concepts escaped me.  
For me, much of the learning comes in the pursuit of making code  
work. Eventually the wonderful AHA moments happen. After which, when  
I go back and read the conceptual docs again I smile - in a proud and  
embarrassed way -- for suddenly parts make complete sense. And so, I  
find I need to revisit the docs, over and over. In this regard,  
addressing the discussion here regarding the quality of the docs is  
quite a bit influenced by how much one already knows.


I have for the past few days been struggling to find a way to append  
an attributed string to the end of text view. I resisted the  
temptation to ask the list. I did look all through the docs. I read  
loads of conceptual material about the text system (architecture,  
layout, containers, storage, and many of the class references). I did  
find an example in the text architecture document (Simple Tasks) for  
using replaceCharactersInRange:withString: to append a string to the  
end of the text view. I actually had trouble finding info on this  
method (it is a part of NSText, which I had developed a notion of  
that it was better to use its subclasses rather than itself  
directly). That aside, there was no  
replaceCharactersInRange:withAttributedString: But then it struck me  
-- inheritance. What else does an NSTextView inherit from? What about  
its storage? And by pursuing that, the answer became clear and the  
solution utterly trivial.  In fact, the way to do this is so  
painfully obvious now that I am embarrassed to mention here that I  
spent the better part of two days trying to figure this out. But this  
is the plight of the programmer new (or relatively) to Cocoa.  
Hopefully I will retain some humility from this experience.


The key to learning is to have fundamental ideas fall into place.  
Before enough of that happens, even easy problems loom large. The gap  
between the accomplished Cocoa programmer and the newcomer is the  
context of their respective knowledge -- a context that makes problem  
solving either more or less difficult, and that makes the docs either  
useful or not.


My point in writing is that veteran Cocoa developers do need to have  
some sympathy and compassion -- that we aspiring developers don't  
have the patterns, and so what is obvious to you isn't obvious to us,  
even if the docs say so.


On the other hand, aspiring developers need to understand that  
learning involves struggle. And that having read the docs once or  
twice isn't good enough. And also to understand that learning is  
sometimes circular -- one needs to go round and round because so much  
of the system is inter-related My advice:  experiment!  I must also  
admit that I read and read about a Nib's File's Owner, but it wasn't  
until I made a bunch of small apps that did nothing but display a  
window (all done in various ways) that the idea finally sunk in.


That said, one of the huge barriers to climbing the Cocoa/Objective-C/ 
CF app development learning curve is that there is so very much to  
learn. The deeper I get into it, the bigger the sea seems to become  
(I am now trying to use Security Framework to manage passwords on a  
keychain --  no small mountain here!).


BTW: I download PDFs of the Apple docs (from developer.apple.com) ...  
and access those quite often. Using Preview, it is easy to search for  
a term. I find I often have several open all at the same time, and  
need to cross-reference what I am reading in order for solutions to  
problems to appear.


Anyway, not sure if I have added anything meaningful...just sharing  
my experience.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or mod

Re: validateMenuItem() not always being called

[jeffs87]

Hi


  else
   {
   enable = [super validateMenuItem:menuItem];
   }

I wasn't, but when I did, it still was only called for the File menu.


-validateMenuItem: is deprecated; you should probably be using
-validateUserInterfaceItem:

Tried validateUserInterfaceItem, no change.


I recommend Hillegass's standard, Cocoa Programming for
Mac OS X, Third Edition (the previous editions may confuse you as
Interface Builder has drastically changed with Leopard).

I forgot to mention I'm on Tiger with Xcode 2.5.
I have Learning Cocoa With Objective-C, 2nd Edition O'Reilly.


In particular, keep in mind the
actions that the File menu items have versus the actions of all other
menu items, and why this would cause AppKit to only invoke your
document's -validateMenuItem: method for File menu items.
The example "SimpleToolbar" has a validateMenuItem method in 
MyDocument.m and it too only gets
called for the File menu but the Edit menu is properly updated for Cut, 
Copy and Paste.

I guess NSTextView handles it.

thanks
Jeff


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa bindings and reluctance to use NSPopupButon

[John Joyce]

Johnny Lundy had a difficult time using NSPopupButon along with
bindings.  The struggles are archived via www.cocoabuilder.com for
posterity.  Mr. Lundy recently wrote "...I am still very very hesitant
to put another NSPopUpButton on my interface, because of the complete
absence of guidance on how to implement the thing, and the many days
it took to get a single one working, and even now I have no idea why
it works..."

Having just now re-read Mr. Lundy's questions and follow-up, I don't
think he had any problem with NSPopupButton at all.  That makes sense
because NSPopupButton is not particularly difficult to use.  I think
Mr. Lundy's struggles were all with "bindings."  Had I been inclined
to participate in the threads at the time, I would have said the
following:

1) Bindings are an ADVANCED technique that was recently introduced and
not yet completely documented.  If someone tries to use bindings in a
situation where he/she doesn't already know how to write the
application without bindings, it is a mistake to use bindings.
2) Bindings exist to _reduce_ the amount of Controller code needed
when the Model View Controller pattern is used.  Bindings don't
eliminate controller code and can't handle all Controller
responsibilities.
3) Bindings appear to be magic, but they are in fact just an
abstraction that enables reuse in place of commonly re-written
controller code.
4) Bindings ARE NOT A REPLACEMENT FOR ALL CONTROLLER CODE, and
bindings are often not the best technique to use.

Mr. Lundy would have been better off writing his controller code
explicitly and using the established outlet, target and action
patterns instead of bindings.  Not only would he have achieved
complete control over all aspects of his application's behavior, he
would have gained insight into how, and and why bindings work or not.
I find that I hardly ever use bindings in my own applications.  I am
more comfortable doing things the good old fashion way in part because
I often want very fine control over application behavior.  I blame Mr.
Lundy's specific struggles on misguided insistence on using the wrong
tool for the job.

I counsel Cocoa newbies to just forget about the Bindings inspector in
Interface Builder and pretend they don't exist.



Thank you Erik!
That's what I had concluded at one point, and then felt pushed back  
towards.
People often said, "you should just use bindings", but I felt I did  
need to first understand how it works without bindings...
With tableViews and treeViews, I can totally see where bindings would  
simplify a lot of things, but still... the bindings docs are still  
tough reading.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Andreas Mayer]

Am 19.05.2008 um 04:08 Uhr schrieb Michael Vannorsdel:


Hopefully you won't get rude people responding with RTFM and such.


Actually, I don't understand why an RTFM kind of answer is perceived  
as rude. I'm really happy when I get an RTFM *with a link* to the  
appropriate document.


Also, I often just don't answer at all, since an RTFM may not be well  
received and I don't have the time to write a more elaborate answer.  
Oh well.



Andreas
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Is there an NSCollectionView selection change notification?

[Markus Spoettl]

Hello List,

  I've started playing with NSCollectionView and everything worked  
out beautifully (custom views, selection state handling for items  
etc.). One thing I can't figure out is how my application/document  
gets notified about a change of selection.


I could go through the NSCollectionViewItem:setSelected: property  
setter (which I'm implementing to probagate the selected state to the  
view) and notify the proper authorities in my application. However,  
that just isn't proper design and there must be a much better  
solution. There is no documentation on delegate methods or  
notifications for NSCollectionView, so I'm wondering how one gets  
notified about things like that.


I have a feeling there's something I'm overlooking here. Is there?

Regards
Markus
--
__
Markus Spoettl



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[ben syverson]

On May 18, 2008, at 8:39 PM, Julius Guzy wrote:

Well this is exactly how things seem to pan out. Those who have been  
doing this for some time like the documentation they have. No doubt  
once I become a bit more adept I will too. But right now..



This is going to sound bitchy, but it's hard for me to have any  
sympathy for vague complaints about the docs or the usability of  
Cocoa. There have been a few times when I wasn't reading the  
documentation thoroughly enough, or have had a question about  
implementation that wasn't answered by looking at example code, and  
have consulted the Apple listservs. (My bad)


There have been far fewer times when an obscure feature from one of  
the more advanced APIs has not worked as it should. (Apple's bad)


But I can't think of a single time when I've been unable to figure out  
where to look for guidance on a problem, or have been unable to  
interpret that guidance.


For bird's-eye overviews, Apple posts things like this:
http://developer.apple.com/leopard/overview/graphicsandmedia.html

They also have resources broken down by category for hierarchically- 
minded folks:

http://developer.apple.com/referencelibrary/

Once you narrow down what it is you want to do, Apple provides  
"Getting Started" guides which give you the background you need:

http://developer.apple.com/referencelibrary/GettingStarted/GS_GraphicsImaging/

That will lead you to deep guides like this:
http://developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/

If you need to see a piece of code in action, Apple provides a wealth  
of Example files both on the web and in your /Developer folder.


Even if you need to have a video, step-by-step instructions and  
associated sample code, Apple's still (!) got your back:

http://developer.apple.com/mac/codingheadstarts.php

And finally, if you're not hierarchically-minded, there's Google (just  
specify site:developer.apple.com after your search terms), and the  
fact that the Reference Library is generously hyperlinked. Apple has  
put a huge amount of effort into making Cocoa and its related  
technologies easy to use and extremely well documented, and in my  
opinion, it shows.


The only thing I can think of that would be better than Apple's online  
docs would be if an Apple engineer would physically sit down and walk  
you through something personally. And of course, Apple does that as  
well. It'll cost you a bit more (plane fare & WWDC ticket), but if you  
need to have your hand held, they'll do it.


So if you're going to complain about the docs, I would suggest that  
you get very very specific, because Apple is truly bending over  
backward to make it easy for you.


- ben

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa bindings and reluctance to use NSPopupButon

[Andreas Mayer]

Am 19.05.2008 um 04:03 Uhr schrieb mmalc crawford:


Which is exactly what the documentation takes pains to tell you.


I guess it's just not clear enough. There should be a big red warning  
box:


"Don't try to use Core Data or Cocoa Bindings unless you are an  
experienced Cocoa programmer and understand - and have used - all the  
underlying technologies."



Andreas
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Erik Buck]

On Sun, May 18, 2008 at 8:41 PM, Julius Guzy
<> wrote:

Tthe fact is that there will be others like me who do not find it
easy to get into cocoa. At this stage I'll not be jumping ship but
believe me I've had sleeples nights about it. Mainly i'll not do it
because although I'm far from attack speed I can just about open a
few windows and pump bit map images to the screen, have menus and
buttons and get mouse and tablet input and hopefully will soon be
able to write to and from disk, and if i'm really lucky i might even
be able to archive system state! in short, I am just about able to do
the things I need to and I am actually progressing the technology
that this current program of mine is supposed to deliver. In short
the investment is beginning to pay off. But getting this far has been
the most difficult piece of learning I've ever done in my life.


As an author of two books about Cocoa programming, it breaks my heart  
to read the above quote.  I don't write Cocoa books for the money.   
There isn't much money to be made.  I do it precisely because I want  
to share the joy and satisfaction of Cocoa programming.  It is my  
profession and my hobby.  I share my experiences and knowledge for the  
same reason anybody encourages others to join in a shared interest.  
Reading about "...sleepless nights..." and "...the most difficult  
learning I've ever done in my life", I despair that the universe has  
tilted on its axis and all is not right with creation.


The brief description of the application being developed follows:

1) Open a few windows
2) pump a few images to the screen
3) have menus
4) have buttons
5) get mouse and tablet input
6) write to and from disk
7) Archive APPLICATION state


All of the described features are implemented in the Sketch example  
application that comes with the developer tools.  /Developer/Examples/ 
AppKit/Sketch  Sketch also provides undo, redo, rulers, marque  
selection, keyboard events handling, copy & paste, drag & drop,  
inspectors, and more.   Many veteran Cocoa programmers learned from  
the much more voluminous Draw example that preceded Sketch.


There are of course more detailed and focused examples focusing on  
image processing and tablet input etc.


What precisely was difficult to learn?  The books I write are intended  
to ease the learning curve.  If you describe your difficulties  
sufficiently, I might be able to alleviate them for the next person.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Jonathan Hendry]

For what it's worth, something about the OS X Cocoa docs' arrangement  
has never quite clicked with me. In part it might be an excess of  
hyper text, too many pages to click through, breaking up the stream  
of thought. (I wish XCode's doc viewer had some kind of keyboard  
shortcut for clicking the 'next' or 'previous' links, rather than  
having to scroll, find the link, and click on it. Surely it's  
consistent enough to be automated?) I also get annoyed with  
programming docs on Windows for the same reason - too much linky- 
jumpy, too much documentation appearing to be little more than links  
to yet other pages.


I found the arrangement of the NeXTStep docs to be a bit more  
conducive to study. For one thing, the class reference docs were more  
independently useful. Today the NSWindow class reference contains  
method descriptions, but little context to help you make sense of  
them. That context is in the Window Programming Guide For Cocoa,  
which is itself 22 separate HTML pages, some of which are long  
('Window Layering and Types of Window'), some short ('Handling Events  
in Windows'). Some of the pages in the guide hardly seem long enough  
to merit their own page. (That kinda bugs me. When a section gets its  
own TOC entry, and its own page, but its only a short paragraph, I  
think it leads the reader to feel a bit shortchanged, as if useful  
information was left out. Worse, there might be relevant information  
that is hiding elsewhere in the docs.)


In the NeXTSTEP days, a lot of that context information would be up  
the top of the class reference file, so it was a self-contained unit  
of information. There was also a set of Concepts documents that tied  
things together, but there was a pretty high likelihood that a  
question about a class could be answered simply by bringing up the  
class reference rtf file. Need to know about NSWindow? Bring up  
NSWindow.rtf.


Nowadays, the answer could be on any of a hundred pages, but probably  
not in the class' own reference page.


(The NeXT docs were mostly set in Times, too, which I found easier to  
read than the current near-universal use of sans serif.)


Your mileage may vary, of course. And I may be looking back through  
rose-colored memories. I can't say the current arrangement is an  
error or a case of bad design, it's just that I think the old  
fashioned way worked better for my brain.


At the very least, before I got my hands on a NeXT box of my own I  
was able to learn a fair amount from the NeXTStep Reference books,  
two fat volumes consisting of the class reference files and little  
else. The concepts material was in another volume. Nowadays, the  
class reference files have largely been stripped down to  
documentation of the methods, with little additional info, so there  
would be little benefit from printing and binding them all together.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: XML schema support

[Michael Vannorsdel]

Checkout NSXML* and friends (NSXMLNode, NSXMLElement).  Also there's  
"Introduction to Tree-Based XML Programming Guide for Cocoa" and  
"Introduction to Event-Driven XML Programming Guide for Cocoa" guides  
in the docs.



On May 18, 2008, at 8:07 PM, David wrote:

Is there a Cocoa package that supports XML schema for either event  
driven

(SAX like) or tree based (DOM like) XML parsing?
I haven't seen any reference to XML schema for either Cocoa packages  
other

than a statement saying you can do your own validation.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Michael Vannorsdel]

On May 18, 2008, at 7:39 PM, Julius Guzy wrote:

So I wouldn't have much to say about it except that it does have a  
tendency to make things seem more exciting than they actually are.  
For instance I can refer here to the idea of dynamic typing which  
still requires us to have the header files present in the calling  
file which isn't exactly in the enthusiastic spirit of how it's  
talked about.
Indeed many of my problems with dynamic typing came about because I  
took the enthusism at face value.



The header issue was just the compiler getting confused.  It would  
happen with most frameworks and C based languages.  ObjC objects can  
do all kinds of magical things like class posing, dynamic methods,  
ect.  But the compiler needs basic information so it knows how to pass  
args and whatnot.  Cocoa or ObjC can't fix this.  You can message an  
object without having any info about the method, but you have to be  
sure the compiler will put the args where the method will expect  
them.  And to do that it needs to know the arg types.




Well I do do a lot of jumping right in. Always done it.
Normally I find it the quickest way of becoming familiar with the  
language of the particular tribe i getting to know.
After that of course I set myself a small problem, e.g. open a  
window, write hello world, open another window, draw something etc.  
That for me is a natural way of proceeding. The real difficulties  
have come about because of the need for precise answers to  
relatively simple questions. What was one of these that took up a  
fair bit of my time once



Ask away here, that's what the list is for.  I don't think anyone here  
can claim they've never asked a stupid programming question before.   
Everyone at one time or another has a bad day when they forget how to  
do something simple and can't remember where they saw the docs  
covering it.  Hopefully you won't get rude people responding with RTFM  
and such.



Well this is exactly how things seem to pan out. Those who have been  
doing this for some time like the documentation they have. No doubt  
once I become a bit more adept I will too. But right now..



My best advice is to keep working at it, trying out classes just to  
learn how to make them work (and how to make them not work).  Browse  
the class listing and the methods in each class, often times you'll  
find a method you never knew about and could really use.  Soon things  
will click and you'll wonder why it was so hard just a week before.   
Kind of like those posters with all the weird patterns on them that  
you stare at for hours until finally the 3D shapes pop out and you see  
them.  After that you can see them every time and wonder why it was so  
hard the first time.


Keep making prototype programs like the dynamic typing one and try out  
new things, and feel free to ask "simple" questions here.  I often  
times will make prototype programs and keep them.  When I forget how I  
got something to work I just look through my prototypes to remind me  
and to grab code from.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

XML schema support

[David]

Is there a Cocoa package that supports XML schema for either event driven
(SAX like) or tree based (DOM like) XML parsing?
I haven't seen any reference to XML schema for either Cocoa packages other
than a statement saying you can do your own validation.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa bindings and reluctance to use NSPopupButon

[mmalc crawford]

On May 18, 2008, at 6:57 PM, David wrote:

In anycase, I started with the highest level facilities expressly  
because
I'm a newbie. Coredata and in turn bindings, seemed simple to  
configure and
use. I didn't have to learn all the underlying gorp. Sadly that  
doesn't seem

to be the case.


Which is exactly what the documentation takes pains to tell you.

mmalc

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Julius Guzy]

On 19 May 2008, at 2:34, Jens Alfke wrote:



On 18 May '08, at 6:15 PM, Julius Guzy wrote:

I do not think it naive of me to raise serious questions regarding  
usability given that i have made huge and increasingly successful  
efforts to get into this system so I can do some heavy duty  
programming.

…
Well if it were doing as good a job as you think it is then I for  
one would not have lived through the nightmare of the last five or  
six months struggle.


If you want to talk about this in terms of HCI usability, then you  
need to play by those rules and _not_ describe the problem  
anecdotally, just in terms of your own experience.
Well, in the present case I only have my own experience to go on. I  
dived into this debate because someone else was expressing  
difficulties and he or she was being told in essence that they should  
not have been finding it hard at all because in reality everything in  
the garden was rosy. So I just thought to respond with expressions of  
solidarity.
Typically when this happens, it's a programmer designing a user  
interface according to his own preferences, which are often very  
different from those of a mainstream computer user.

Sorry, no comprendo.
In my original missive I was equating the problems of HCI design with  
the problems of designing manuals for engineers.


In this case it sounds like the opposite — you seem to be finding  
Cocoa a lot more difficult to learn than most do. It definitely  
shouldn't take months of struggle. (CoreAudio or Security, maybe.  
Not AppKit.)
Well I don't know how much more difficult I find learning it than  
others have.

It would be interesting to find out.
I have perhaps expressed my true feelings more than others because  
I'm not going to loose out on any jobs by admitting to a few  
difficulties. On the other hand maybe everyone here has had very few  
difficulties in learning this quite enormous body of knowledge. I did  
ask in an earlier missive how others came to learn the system and  
there seems to have been the usual mix of starting early or going on  
training courses or having talent and working hard.


I don't know why that would be, and I don't mean it as a value  
judgment. Different people have different learning styles. Maybe  
the docs aren't matching yours. As others have pointed out, it  
would be good to have more details on what you think the docs are  
missing.
Yes but I like others have programs to write and very little time to  
do it in. So yes, I think that would be a very good idea. I don't  
know who else would be interested in contributing an hour or so a  
week to the general good but if there were a consensus then I think I  
might.


One thing that does seem to apply to a number of other people  
asking questions on this forum is a seeming lack of ability to  
experiment and figure out answers oneself. Writing code is  
engineering, but debugging it and figuring out how an API works is  
more like a science — and understanding how to experiment, and draw  
conclusions from evidence, are vital skills.



Yes. That's what programmers do.

Julius

http://juliuspaintings.co.uk



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa bindings and reluctance to use NSPopupButon

[David]

This is a very interesting topic.I've been writing my first large Cocoa
application. New to objective-C and Cocoa, very experienced with Java.

I started out wanting to learn what facilities are available in this new
platform, partly to try to get a quick feel if it was worth switching to
rather than just writing the app in Java.

So I started with CoreData and was able to get most of the application
working with some trouble.

My first problems were really with Core Animation. I wanted to do what
seemed like a simple transition effect, yet it seemed way more involved than
I wanted to get into. I abandoned that effort after learning a reasonable
amount about Core Animation.

Then I tried to add some optimization to my Core Data application to handle
threading. Whoa. Big catastrophe. Found out that Core Data and bindings are
NOT threadsafe. I had taken it for granted that they were threadsafe. The
hoops that are required to use it in a multi-threaded environment are way
more involved than I was willing to invest in. And I realized as a result
that I was very much using the wrong tool for the job. Core data is too big,
too heavy weight for what was really a simple outline view requirement.

So, I backed down to use bindings. Bindings are working pretty well for
me... until

Seems simple. I want to use a NSButtonCell in the first column of the
outline view. Again this seems to me to be the typical, in almost all cases,
use of a NSButtonCell in an outline view. Yet it seems like I've asked it to
make Martians. Too obscure. If I could find out what the message exchanges
are, it shouldn't be difficult. But a combination of minimal and hard to
find documentation, classes with unpublished interfaces and closed source
make it difficult for those not in the know.

So, I'm realizing that maybe its more reasonable to back down to just using
a data source, target/action and delegates.

I'm still having trouble understanding the delegate signatures when they
throw in some (id) types, I'm not sure what data types are expected.

In anycase, I started with the highest level facilities expressly because
I'm a newbie. Coredata and in turn bindings, seemed simple to configure and
use. I didn't have to learn all the underlying gorp. Sadly that doesn't seem
to be the case. It reminds me of trying to understand MFC without knowing
anything about Win32. It helps to know Win32 to see that MFC is simply an OO
wrapper around Win32 to understand some of its awkwardness.

In the end, unfortunately it makes me question if I've made the right choice
writing for Cocoa and Obj-C rather than Java. Much of the value add I saw in
Cocoa, with Core Data, Core Animation, bindings etc. has slowly whittled
away. I'm now fairly comfortable with Obj-C so I'll probably stick it out in
hopes that more value will become apparent over time.

On Sun, May 18, 2008 at 8:03 PM, Erik Buck <[EMAIL PROTECTED]> wrote:

> Johnny Lundy had a difficult time using NSPopupButon along with bindings.
>  The struggles are archived via www.cocoabuilder.com for posterity.  Mr.
> Lundy recently wrote "...I am still very very hesitant to put another
> NSPopUpButton on my interface, because of the complete absence of guidance
> on how to implement the thing, and the many days it took to get a single one
> working, and even now I have no idea why it works..."
>
> Having just now re-read Mr. Lundy's questions and follow-up, I don't think
> he had any problem with NSPopupButton at all.  That makes sense because
> NSPopupButton is not particularly difficult to use.  I think Mr. Lundy's
> struggles were all with "bindings."  Had I been inclined to participate in
> the threads at the time, I would have said the following:
>
> 1) Bindings are an ADVANCED technique that was recently introduced and not
> yet completely documented.  If someone tries to use bindings in a situation
> where he/she doesn't already know how to write the application without
> bindings, it is a mistake to use bindings.
> 2) Bindings exist to _reduce_ the amount of Controller code needed when the
> Model View Controller pattern is used.  Bindings don't eliminate controller
> code and can't handle all Controller responsibilities.
> 3) Bindings appear to be magic, but they are in fact just an abstraction
> that enables reuse in place of commonly re-written controller code.
> 4) Bindings ARE NOT A REPLACEMENT FOR ALL CONTROLLER CODE, and bindings are
> often not the best technique to use.
>
> Mr. Lundy would have been better off writing his controller code explicitly
> and using the established outlet, target and action patterns instead of
> bindings.  Not only would he have achieved complete control over all aspects
> of his application's behavior, he would have gained insight into how, and
> and why bindings work or not.  I find that I hardly ever use bindings in my
> own applications.  I am more comfortable doing things the good old fashion
> way in part because I often want very fine control over appli

Re: releasing NSKeyedUnarchiver causes crash

[Markus Spoettl]

On May 18, 2008, at 1:53 PM, Jonathan Dann wrote:
Sorry if I've told you things you know already and there was another  
perfectly valid reason for doing what you did.



Actually it's a good question why I didn't use a property. I'm using  
properties all the time - one of the reasons being the automatic  
retain release handing. thanks for pointing that out.


Regards
Markus
--
__
Markus Spoettl



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Scott Anguish]

where you feel this to be the case, PLEASE file bugs  
(bugreporter.apple.com) or feedback.


it is all taken seriously.


On May 18, 2008, at 5:39 PM, Νικόλας Τουμπέλης wrote:

Apple's documentation is often verbose and pedantic but there are  
excellent

free alternatives online and very good books. Cocoa


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Scott Anguish]

On May 18, 2008, at 5:03 PM, Johnny Lundy wrote:

Take the "Currency Converter With Bindings" much-touted tutorial; it  
actually uses a method that is deprecated.



this actually is a prime example of why tutorials are few and far  
between in the Apple doc.  They require significant upkeep.


This is on the list to be updated but has (unfortunately) been pushed  
out more than once.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Julius Guzy]

On 19 May 2008, at 1:56, David Wilson wrote:



On Sun, May 18, 2008 at 8:41 PM, Julius Guzy
<[EMAIL PROTECTED]> wrote:

Well, there is a problems with the documentation and if it does  
not get
resolved then people will end up unable to write the code. I mean  
what is
the point in loosing people who actually want to program this  
machine and

are willing to put oodles of effort into doing it?



There's been a lot of discussion on the list lately about how Cocoa
has been so hard for people to learn, but not a lot of useful
specifics or follow-up. People haven said "the API is bad because it
refers to all these terms you're already supposed to know and I don't
know them!", and then when someone says "Did you read the conceptual
documentation?" the response is a resounding... silence. I think this
is part of why those veteran Cocoa developers are often less than
sympathetic.

The silence on my part is that I understood that bit of the  
documentation.
In fact the conceptual stuff is largely a doddle. I've been familiar  
with it for some time now and it doesn't give me trouble.
So I wouldn't have much to say about it except that it does have a  
tendency to make things seem more exciting than they actually are.  
For instance I can refer here to the idea of dynamic typing which  
still requires us to have the header files present in the calling  
file which isn't exactly in the enthusiastic spirit of how it's  
talked about.
Indeed many of my problems with dynamic typing came about because I  
took the enthusism at face value.




You say it's the most difficult piece of learning you've done in your
life, but I wonder how you went about it. It may be that the problem
is not so much in the documentation itself, as in the
"meta-documentation" - that is, guiding newbies to the appropriate
documentation in the appropriate order. Unfortunately, that can of
course be frustrated by the types who jump right in and start reading
APIs with abandon and then complain that they don't understand certain
terminology or concepts. (Not that I'm accusing you in particular of
doing this, your comment just happened to spark this response).


Well I do do a lot of jumping right in. Always done it.
Normally I find it the quickest way of becoming familiar with the  
language of the particular tribe i getting to know.
After that of course I set myself a small problem, e.g. open a  
window, write hello world, open another window, draw something etc.  
That for me is a natural way of proceeding. The real difficulties  
have come about because of the need for precise answers to relatively  
simple questions. What was one of these that took up a fair bit of my  
time once




So, it'd be interesting to hear from people what they actually *tried*
with respect to learning from the documentation and why it failed.


... exactly. That's a problem. You identify it correctly.
It is difficult without keeping a diary or something like it to  
remember the questions.
I tried to do this several times because I thought I might put up  
some web pages about it and the discipline would serve to knock the  
stuff into my head. However giving a good explanation is a lot harder  
than one might at first suppose and besides, the exigencies of time  
got the better of my good intentions.




Clearly the documentation worked for a large percentage of the veteran
developers on the list - personally, I own one Cocoa book, and I think
I made it through about a quarter of it before giving it up as useless
because the API was well written and conceptual documentation covered
the questions that arose. I wonder if this has more to do with a
difference in approach to the documentation than anything else.

Well this is exactly how things seem to pan out. Those who have been  
doing this for some time like the documentation they have. No doubt  
once I become a bit more adept I will too. But right now..


All the best
Julius

http://juliuspaintings.co.uk

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Jens Alfke]

On 18 May '08, at 6:15 PM, Julius Guzy wrote:

I do not think it naive of me to raise serious questions regarding  
usability given that i have made huge and increasingly successful  
efforts to get into this system so I can do some heavy duty  
programming.

…
Well if it were doing as good a job as you think it is then I for  
one would not have lived through the nightmare of the last five or  
six months struggle.


If you want to talk about this in terms of HCI usability, then you  
need to play by those rules and _not_ describe the problem  
anecdotally, just in terms of your own experience. Typically when this  
happens, it's a programmer designing a user interface according to his  
own preferences, which are often very different from those of a  
mainstream computer user.


In this case it sounds like the opposite — you seem to be finding  
Cocoa a lot more difficult to learn than most do. It definitely  
shouldn't take months of struggle. (CoreAudio or Security, maybe. Not  
AppKit.)


I don't know why that would be, and I don't mean it as a value  
judgment. Different people have different learning styles. Maybe the  
docs aren't matching yours. As others have pointed out, it would be  
good to have more details on what you think the docs are missing.


One thing that does seem to apply to a number of other people asking  
questions on this forum is a seeming lack of ability to experiment and  
figure out answers oneself. Writing code is engineering, but debugging  
it and figuring out how an API works is more like a science — and  
understanding how to experiment, and draw conclusions from evidence,  
are vital skills.


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Julius Guzy]

On 18 May 2008, at 17:41, Jens Alfke wrote:



On 18 May '08, at 4:33 AM, Julius Guzy wrote:

Apple has been less celebrated for the humanity of its programming  
interface having, in my experience of Macs from the Lisa onwards,  
seemingly taken the attitude that its programmers were hobbyists,  
geeks essentially, who because of their enthusiasm would  
successfully negociate their way into the machine's innards.


"Hobbyists"? I think "professionals" is more accurate — especially  
since in the early days of the Mac you had to spend hundreds of  
dollars to become a developer and get access to tools and  
documentation.

well there you are. Precisely.


I can see your point about obsessive hackers having the stamina to  
overcome complicated APIs, but any platform vendor's main objective  
in developer tools is to target professional developers who will  
create the products that make the platform attractive to customers.  
"Professional" doesn't necessarily imply a big company; I refer  
equally to startups and indie outfits, anyone seriously devoted to  
creating a product.

Like me for instance.


I have to say I find this whole discussion frustrating. The  
attitude of some people seems to be that writing computer programs,  
of arbitrary complexity, should be as easy as using a word  
processor. That's a Utopian goal at best, and more generally just  
naïve.
To my knowledge during these discussions nobody has suggested this  
least of all I. There is nothing about programming computers that  
does not require a fair bit of knowledge of how to get around the  
machine. I do not think it naive of me to raise serious questions  
regarding usability given that i have made huge and increasingly  
successful efforts to get into this system so I can do some heavy  
duty programming. From that point of view the debate has been quite  
informative regarding the documentation and how to use it, even  
though I still find it exceptonally hard.


Of course we should be trying to make the APIs and tools and  
documentation more useable; that's a constant task, and a very  
difficult one, and one Apple's doing a good job at. (The complexity  
under the hood is terrifying, and it's already been covered up  
enough that in an hour an experienced developer can throw together  
an app that fifteen years ago would have sold for $100.)
Well if it were doing as good a job as you think it is then I for one  
would not have lived through the nightmare of the last five or six  
months struggle.


Face it, any sort of serious creative endeavor is hard! There's no  
way around it. And the hardest part is learning the techniques and  
tools. If you wanted to build a robot,

done it

play Vivaldi on the violin

can't

, design a house,

done it

paint landscapes,

sometimes

or cure Ebola,

next week
you'd have to accept that it would take months or years of serious  
study,

absolutely!!! years and years
that the tools and documentation would sometimes be hard to use,  
and you'd have to put up with frustration before you mastered the  
skills.

been there, done it , still have not mastered the skills bit.


Why on earth is writing the best GUI applications in the world  
supposed to be trivial by comparison? Maybe I'm taking this too  
personally, but I sense a subtext that some people think the task  
of software design itself is somewhat trivial, more like  
programming a VCR than like architecture or painting or chemistry.


"Problems worthy of attack
 Prove their worth by hitting back." [Piet Hein]
What have I said that should make anyone suppose I think designing  
software is trivial?



Julius

http://juliuspaintings.co.uk



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[David Wilson]

On Sun, May 18, 2008 at 8:41 PM, Julius Guzy
<[EMAIL PROTECTED]> wrote:
> Well, there is a problems with the documentation and if it does not get
> resolved then people will end up unable to write the code. I mean what is
> the point in loosing people who actually want to program this machine and
> are willing to put oodles of effort into doing it?

There's been a lot of discussion on the list lately about how Cocoa
has been so hard for people to learn, but not a lot of useful
specifics or follow-up. People haven said "the API is bad because it
refers to all these terms you're already supposed to know and I don't
know them!", and then when someone says "Did you read the conceptual
documentation?" the response is a resounding... silence. I think this
is part of why those veteran Cocoa developers are often less than
sympathetic.

You say it's the most difficult piece of learning you've done in your
life, but I wonder how you went about it. It may be that the problem
is not so much in the documentation itself, as in the
"meta-documentation" - that is, guiding newbies to the appropriate
documentation in the appropriate order. Unfortunately, that can of
course be frustrated by the types who jump right in and start reading
APIs with abandon and then complain that they don't understand certain
terminology or concepts. (Not that I'm accusing you in particular of
doing this, your comment just happened to spark this response).

So, it'd be interesting to hear from people what they actually *tried*
with respect to learning from the documentation and why it failed.
Clearly the documentation worked for a large percentage of the veteran
developers on the list - personally, I own one Cocoa book, and I think
I made it through about a quarter of it before giving it up as useless
because the API was well written and conceptual documentation covered
the questions that arose. I wonder if this has more to do with a
difference in approach to the documentation than anything else.

-- 
- David T. Wilson
[EMAIL PROTECTED]
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Julius Guzy]

On 18 May 2008, at 14:36, Jason Stephenson wrote:


(Have you ever tried programming X11 with just XLib C calls? Nasty  
stuff that)
Yes,  
superDooperExtraSpecialHighIntensityOpenWindowAndDoLotsOfWonderfulThings 
IfYouSetTheParametersRightWidget.


Also, please don't confuse the language, Objective-C in this case,  
with the frameworks/system interface. Objective-C is a very small  
language, and it is easy to keep the main things in mind. PL/1 is  
another matter altogether (So is C++ if you think about it.)

I don't think I mentioned Objective C in that missive.

Cocoa is much larger, but the same could be said of  C and XLib  
respectively. Not to mention that on X you have many different GUI  
toolkits to choose from to abstract away the complexity of XLib:  
Xt, Qt, Tk, XAW, Motif, GNUStep, Gnome, KDE, etc., etc.


Modern computer systems are complex. There are many, many options  
of the programmer. If modern computer systems lacked this  
complexity, and if the published interfaces did not have APIs  
available so that programmers could make adequate use of this  
complexity, then we'd be stuck where we were in the early '80s,  
having to roll our own library for everything.


I don't think you can expect to lose the learning curve in any  
programming interface. APIs expose complexity, and at the same  
time, cover it up. Imagine if you had to implement your own Model- 
View-Controller paradigm for your GUI widgets before you could  
start making your own applications? That is the situation that  
you'd be in with something like XLib, or even the old Macintosh  
Toolbox. Today, that complexity is abstracted away rather neatly by  
the Cocoa framework, just as it would be on X if you used Motif or  
Qt or some other toolkit.
It has been true for quire a long time now that learning a computer  
language is child's play compared with learning the api and how to  
use it. And modern systems are more complex and at the same time  
conceptually a lot simpler than earlier systems would be if they had  
tried to do the same job.


If you do want to just jump in and start writing code, then perhaps  
you should look into Python or some other "scripting" language.  
They do an even better job of hiding the complexity.


As yet I have not worked with Python but I am familiar with PHP and  
especially Perl

I am also familiar with c, java, prolog, pascal, ...
From that point of view my favourite programm of all time was  
Hypercard untill Apple started making it fancy and finally destroyed  
it by selling it to people who had no idea of the amazing things one  
could so quickly prototype in it.




I also don't find any great difficulty in using Apple's  
documentation. The conceptual documents cover the concepts, and the  
reference documentation serves as a reference. No, I don't think  
you should learn to use Cocoa just from the conceptual documents,  
but I'm sure it is possible.
well this is precisely the point I made, that the debate has been  
polarising between those who find the documentation adequate if not  
best ever and people like myself who despite their best efforts have  
so far found it an uphill struggle.


The simple fact of the matter is that documentation, just like a  
GUI, cannot be all things to all people. Programmers and those  
interested in programming are a particularly eclectic bunch. We  
each come at Cocoa for the first time with different experience,  
different reference points, and different expectations. One set of  
documentation cannot be expected to handle all of the possible  
permutations of programmer knowledge and experience. For this  
reason, other books exist written by third parties to cover those  
gaps or target different audiences.
Precisely. In my view the documentation is by and large a very good  
list of what is to be found and its components and how it relates to  
other components and subsystems. And I think that an awful lot of  
care has gone into its production. With regard to the books, we're  
touching on a sore point. I have the Quartz book which is pretty  
good, the Hillglass which i hate but can't do without, the Kochan  
which I like a lot because clear and suscinct,  the Anguish et al.  
often rewards the occasional dip, an O'Malley that I think I opened  
once, ditto Trent and McCormack, the Feiller OS X developer's guide  
was a nice read, and then there are the (for me) just awful vermont  
recipies. Of course the best book of the lot here is still the  
Kerningham and Ritchie and a book which has nothing to do with cocoa  
or c but raises the spirits when necessary: Seggern's Practical  
Handbook of Curve Design and Generation.


Tthe fact is that there will be others like me who do not find it  
easy to get into cocoa. At this stage I'll not be jumping ship but  
believe me I've had sleeples nights about it. Mainly i'll not do it  
because although I'm far from attack speed I can just about open a  
few windows and pump bi

Re: Cocoa et al as HCI usability problem

[Torsten Curdt]

On May 18, 2008, at 22:38, P Teeson wrote:


begin rant:

Oh me oh my the poor newcomers to Cocoa. Sorry folks back in the  
days of 360 mainframes there were manuals and they were inscrutable.
But if you took the Winston Churchill aproach and spent some blood,  
sweat, toil and tears you would probably become a 1/2 decent  
assembler language programmer.


I see - ignorance is bliss :-p

I have been writing a LOT of assembler code the early days and have a  
strong C and OOP background - it should be a piece of cake, right?  
Well, and you know what - the basics are! When you just need reference  
documentation - well, then you are OK as well. But there is A LOT to  
cover in the middle where your "RTFM" just sound like mockery.


I think what we are seeing now is (or will is) that (probably also  
because of the iPhone) Cocoa programming is becoming more popular.  
Just looking around me... the number of people (I know) that know how  
to write a Cocoa program is -let's not make a comparison- ...but it's  
tiny! This is changing and ...like or not - more newbies will hit this  
list. Period! People coming from the Java and the .Net world. A world  
that has a LOT more coverage on the net.


When you come from that world. You find yourself asking questions like:

 "Someone must have done this before! Nothing on the blogosphere? No  
articles?"
 "The mail sending API is deprecated in Leopard - without an  
alternative? WTF!"
 "People say XCode is great - they can't have worked with Eclipse/ 
Idea. Where are my refactoring tools??"


Of course I have also been asking question that ARE explained in  
Apple's docs. Guilty as charged! But - well, I just did not find them!


Now I think everyone on this list is probably picky about good UI -  
for a good reason. Using your app should preferably be possible  
without reading a big manual. Actually that is also one of the best  
goals when designing a framework or API. (Not saying Cocoa does not  
fit this shoe!) ...but this also applies to documentation. Just saying  
- I searched for things and didn't find them. Knowing that I am not  
entirely stupid this could mean there is room for improvement.  
Reacting like "I don't get you newbies - I can work with it just fine"  
is like saying  "What's do you mean by you 'would like to use the  
mouse'? I am happy with the terminal". (That said I am a command line  
guy :-o )


If so many voices say "it's hard" ...there might be at least some  
truth in it. And this is not the normal "I learn a new language/ 
framework" thing. Good programming is hard - I think we all know that.  
But that is really not the point here (I think).


Frankly speaking I hope this discussion will resolve itself after a  
while. I personally have the feeling that cocoa resources on the net  
are increasing. Also I have high hopes for learning a couple of things  
during WWDC :) (see you there!)


That said: Sweat of not - I still like getting into it :) Maybe you  
guys just have to cut us newbies some slack. Maybe we are just  
spoiled ;)


cheers
--
Torsten


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Cocoa bindings and reluctance to use NSPopupButon

[Erik Buck]

Johnny Lundy had a difficult time using NSPopupButon along with  
bindings.  The struggles are archived via www.cocoabuilder.com for  
posterity.  Mr. Lundy recently wrote "...I am still very very hesitant  
to put another NSPopUpButton on my interface, because of the complete  
absence of guidance on how to implement the thing, and the many days  
it took to get a single one working, and even now I have no idea why  
it works..."


Having just now re-read Mr. Lundy's questions and follow-up, I don't  
think he had any problem with NSPopupButton at all.  That makes sense  
because NSPopupButton is not particularly difficult to use.  I think  
Mr. Lundy's struggles were all with "bindings."  Had I been inclined  
to participate in the threads at the time, I would have said the  
following:


1) Bindings are an ADVANCED technique that was recently introduced and  
not yet completely documented.  If someone tries to use bindings in a  
situation where he/she doesn't already know how to write the  
application without bindings, it is a mistake to use bindings.
2) Bindings exist to _reduce_ the amount of Controller code needed  
when the Model View Controller pattern is used.  Bindings don't  
eliminate controller code and can't handle all Controller  
responsibilities.
3) Bindings appear to be magic, but they are in fact just an  
abstraction that enables reuse in place of commonly re-written  
controller code.
4) Bindings ARE NOT A REPLACEMENT FOR ALL CONTROLLER CODE, and  
bindings are often not the best technique to use.


Mr. Lundy would have been better off writing his controller code  
explicitly and using the established outlet, target and action  
patterns instead of bindings.  Not only would he have achieved  
complete control over all aspects of his application's behavior, he  
would have gained insight into how, and and why bindings work or not.   
I find that I hardly ever use bindings in my own applications.  I am  
more comfortable doing things the good old fashion way in part because  
I often want very fine control over application behavior.  I blame Mr.  
Lundy's specific struggles on misguided insistence on using the wrong  
tool for the job.


I counsel Cocoa newbies to just forget about the Bindings inspector in  
Interface Builder and pretend they don't exist.






___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSTreeController problems

[Charles Srstka]

On May 18, 2008, at 6:44 PM, Jonathan Dann wrote:

Yeah that one's really useful. NSTreeController is so much easier to  
use in 10.5 but those extensions to NSTreeController NSTreeNode and  
NSIndexPath make it really simple to use.


You're welcome. These ones I didn't post but I use ALL the time too  
(note they call other methods in the sample project)


Many thanks. :-)

Charles
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSTreeController problems

[Jonathan Dann]

On 18 May 2008, at 23:57, Charles Srstka wrote:


On May 18, 2008, at 5:47 PM, Jonathan Dann wrote:

Not any more, the documentation may not have been updated yet.  The  
header for NSTreeController says differently as of 10.5.  It's  
always good to check the docs and the comments in the header file.   
(control double click on the word NSTreeController in your code to  
get to the header). You often find the odd method that's not in the  
docs too. File a radar if you do for any of the classes you use.


Glad to be of service, feel free to ask more.

Jon


Oh sweet, you are indeed correct. The header also mentions a - 
descendantNodeAtIndexPath: method I can send this object that will  
allow me to get the node at a given index path, which was another  
thing I was having trouble doing.


Thanks! :-)

Charles


Yeah that one's really useful. NSTreeController is so much easier to  
use in 10.5 but those extensions to NSTreeController NSTreeNode and  
NSIndexPath make it really simple to use.


You're welcome. These ones I didn't post but I use ALL the time too  
(note they call other methods in the sample project)


//NSTreeNode_Extensions (insipred by Apple's SourceView sample code)
- (NSArray *)descendants;
{
NSMutableArray *array = [NSMutableArray array];
for (NSTreeNode *item in [self childNodes]) {
[array addObject:item];
if (![item isLeaf])
[array addObjectsFromArray:[item descendants]];
}
return [[array copy] autorelease];
}

// NSTreeController_Extensions
- (void)setSelectedNode:(NSTreeNode *)node;
{
[self setSelectionIndexPath:[node indexPath]];
}

- (void)setSelectedObject:(id)object;
{
[self setSelectedNode:[self treeNodeForObject:object]];
}

- (NSArray *)flattenedSelectedNodes;
{
NSMutableArray *mutableArray = [NSMutableArray array];
for (NSTreeNode *treeNode in [self selectedNodes]) {
if (![mutableArray containsObject:treeNode])
[mutableArray addObject:treeNode];
if (![[treeNode valueForKeyPath:[self leafKeyPath]] boolValue]) 
{
			[mutableArray addObjectsFromArray:[treeNode  
valueForKeyPath:@"descendants"]];

}
}
return [[mutableArray copy] autorelease];
}

- (NSArray *)flattenedSelectedObjects;
{
	return [[self flattenedSelectedNodes]  
valueForKey:@"representedObject"];

}

- (NSArray *)flattenedSelectedLeafNodes;
{
NSMutableArray *mutableArray = [NSMutableArray array];
for (NSTreeNode *treeNode in [self flattenedSelectedNodes]) {
if ([[treeNode valueForKeyPath:[self leafKeyPath]] boolValue])
[mutableArray addObject:treeNode];
}
return [[mutableArray copy] autorelease];
}

- (NSArray *)flattenedSelectedLeafObjects;
{
	return [[self flattenedSelectedLeafNodes]  
valueForKey:@"representedObject"];

}

- (NSArray *)flattenedSelectedGroupNodes;
{
NSMutableArray *mutableArray = [NSMutableArray array];
for (NSTreeNode *treeNode in [self flattenedSelectedNodes]) {
if (![[treeNode valueForKeyPath:[self leafKeyPath]] boolValue])
[mutableArray addObject:treeNode];
}
return [[mutableArray copy] autorelease];
}


- (NSArray *)flattenedSelectedGroupObjects;
{
	return [[self flattenedSelectedGroupNodes]  
valueForKey:@"representedObject"];

}

Jon



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: validateMenuItem() not always being called

[Hal Mueller]

Correction: deprecated on NSDocument.

http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSDocument_Class/Reference/Reference.html#/ 
/apple_ref/doc/uid/2008-BBCDBJEF


Hal

On May 18, 2008, at 3:55 PM, j o a r wrote:



On May 18, 2008, at 3:46 PM, Hal Mueller wrote:


-validateMenuItem: is deprecated



Really? Where is this documented?

j o a r




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSTreeController problems

[Charles Srstka]

On May 18, 2008, at 5:47 PM, Jonathan Dann wrote:

Not any more, the documentation may not have been updated yet.  The  
header for NSTreeController says differently as of 10.5.  It's  
always good to check the docs and the comments in the header file.   
(control double click on the word NSTreeController in your code to  
get to the header). You often find the odd method that's not in the  
docs too. File a radar if you do for any of the classes you use.


Glad to be of service, feel free to ask more.

Jon


Oh sweet, you are indeed correct. The header also mentions a - 
descendantNodeAtIndexPath: method I can send this object that will  
allow me to get the node at a given index path, which was another  
thing I was having trouble doing.


Thanks! :-)

Charles
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: validateMenuItem() not always being called

[j o a r]

On May 18, 2008, at 3:46 PM, Hal Mueller wrote:


-validateMenuItem: is deprecated



Really? Where is this documented?

j o a r


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: validateMenuItem() not always being called

[Kyle Sluder]

On Sun, May 18, 2008 at 6:46 PM, Hal Mueller <[EMAIL PROTECTED]> wrote:
> -validateMenuItem: is deprecated; you should probably be using
> -validateUserInterfaceItem:

Not entirely true... according to the Application Menu and Pop-up List
Programming Topics for Cocoa document, under "Choosing
validateMenuItem: or validateUserInterfaceItem:"...

"In general, you should use validateUserInterfaceItem: instead of
validateMenuItem: since the former will also work for toolbar items
which have the same target and action. If, however, there is
additional work that you want to do that is specific to a menu item,
use validateMenuItem:—for example, validateMenuItem: is also a good
place to toggle titles or set state on menu items to make sure they're
always correct."

So yes, in most cases, -validateUserInterfaceItem: is more
appropriate, but some cases would benefit from using
-validateMenuItem: instead.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSTreeController problems

[Jonathan Dann]

On 18 May 2008, at 21:57, Charles Srstka wrote:

Thanks, that looks very useful. I only have one trepidation about  
it, which concerns this:


On May 18, 2008, at 3:33 PM, Jonathan Dann wrote:

- (NSArray *)rootNodes;
{
return [[self arrangedObjects] childNodes];
}


Isn't -arrangedObjects one of those methods you're never supposed to  
call manually, only through bindings? At least, that seems to be the  
vibe I picked up while searching the list before posting my  
question. The docs say this:




Not any more, the documentation may not have been updated yet.  The  
header for NSTreeController says differently as of 10.5.  It's always  
good to check the docs and the comments in the header file.  (control  
double click on the word NSTreeController in your code to get to the  
header). You often find the odd method that's not in the docs too.  
File a radar if you do for any of the classes you use.


Glad to be of service, feel free to ask more.

Jon

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: validateMenuItem() not always being called

[Joel Norvell]

Jeff,
You need to call super for the "else" cases.
Are you doing that?
Joel

- (BOOL) validateMenuItem: (NSMenuItem *) menuItem
{
BOOL enable = NO;

if ([menuItem action] == @selector(yourSelector:))
{
if (yourEnablingLogicForThisSelectorIsSatisfied)
{
enable = YES;
}
}
else if ...
{

} 
else
{
enable = [super validateMenuItem:menuItem];
}

return enable;
}




  
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: validateMenuItem() not always being called

[Hal Mueller]

-validateMenuItem: is deprecated; you should probably be using - 
validateUserInterfaceItem: (these are both methods, not functions as  
you wrote).  Where to implement it depends on what functionality  
you're trying to control/limit.  If I'm only allowing one document  
open for read/write at a time, then I want to implement it in one  
place.  If I want to restrict a window's maximum zoom level and I have  
multiple windows, I'll implement it in a different place.


Hal

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: validateMenuItem() not always being called

[Kyle Sluder]

On Sun, May 18, 2008 at 4:31 PM,  <[EMAIL PROTECTED]> wrote:
> I'm new to Cocoa and I created a Document-based Application with New
> Project.  I added a validateMenuItem() method to my document class and it is

Methods in Objective-C are not denoted as you have done.  The correct
method is -validateMenuItem:, which specifies that it is an instance
method (the - prefix) and that it accepts one argument (the colon).

> only being called when you click on the FIle menu, not any of the other
> menus.  Is the document the correct place for this or do I need o add a

Please re-read the Application Menu and Pop-Up List Programming Topics
guide, which describes the exact steps that AppKit takes to validate
an automatically-enabled menu item.  In particular, keep in mind the
actions that the File menu items have versus the actions of all other
menu items, and why this would cause AppKit to only invoke your
document's -validateMenuItem: method for File menu items.

> controller class?  If I do need to add a controller class, how would I go
> about doing that?

This is a very fundamental concept that, if you don't understand, will
hamper your progress in learning the framework.  There is ample
documentation to get you on your feet in this regard, after (or
instead of) which you may find it useful to purchase a book on Cocoa
programming.  I recommend Hillegass's standard, Cocoa Programming for
Mac OS X, Third Edition (the previous editions may confuse you as
Interface Builder has drastically changed with Leopard).

Good luck, and welcome to Cocoa!

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Michael Vannorsdel]

I'm also wondering if many of the people finding Cocoa difficult are  
also lacking OO programming experience.  The docs teach Cocoa really  
well but if you're unfamiliar with OO design and concepts the Cocoa  
docs are going to be very daunting.



On May 18, 2008, at 3:28 PM, Jason Stephenson wrote:


Have you read the Cocoa Fundamentals Guide?

http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/Introduction/chapter_1_section_1.html

Much of what you seek is explained therein. If the Guide makes no  
sense to you, I'd suggest picking up some basic books on OO  
programming and design patterns. Read them, then come back to the  
Cocoa Fundamentals Guide.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Νικόλας Τουμπέλης]

As a (relatively) newcomer to Cocoa and generally far less experienced than
most of the people that have responded so far, here are my 2 cents.
Cocoa and Objective-C are no more difficult or obscure than any other
popular OO framework out there. I made the transition from .NET as easily as
I had done (to .NET) before from Java. The only stumbling block I
encountered is that Xcode and Interface Builder don't work like Eclipse or
Visual Studio. The separation between the Model, View and Controller is far
more distinct than in any other tool I've used, so my mental model was
problematic at first.

There only minor stumbling blocks for a Cocoa newbie and these are
differences of culture...mostly. Cocoa offers a much better development
experience and provides avenues for better design practices as long as you
don't try to write code as if you're writing it for Windows.

Apple's documentation is often verbose and pedantic but there are excellent
free alternatives online and very good books. Cocoa methods and classes are
clearly and fully named, by convention and you don't really have to rely too
much upon the documentation later. The learning curve is steep, especially
for those used to Java or .NET or any other development platform, but the
benefits are much greater.

The only thing I miss from the Windows world is the plethora of free custom
controls...




On Sun, May 18, 2008 at 2:33 PM, Julius Guzy <[EMAIL PROTECTED]>
wrote:

> The very good , interesting and informative debate in this list concerning
> the accessibility of the programming environment to new users has it seems
> to me incresingly polarised between those who think the documentation more
> or less adequate and those like me who for whatever reason, have great
> difficulties making use of the facilities.
>
> I think this debate relates to the same concerns and battles we had, and in
> many cases are still having about computer usability, namely the effective
> design of human-computer interfaces, aka HCI.
>
> It is ironic that we are having this debate within an Apple programmer's
> mailing list. Apple has been celebrated for the usability of its machines
> and long may it continue to be so. However, Apple has been less celebrated
> for the humanity of its programming interface having, in my experience of
> Macs from the Lisa onwards, seemingly taken the attitude that its
> programmers were hobbyists, geeks essentially, who because of their
> enthusiasm would successfully negociate their way into the machine's
> innards. That said, the 9 tomes of "Inside the Macintosh" documentation of
> the programmer's workshop were pretty good once you got into them but there
> was a lot less to get into then than there is today.
>
> This question of volume of documentation and system size and complexity is
> significant to our debate. It is pertinent to quote what one of the great
> programming pioneers, Dijkstra said about PL/1: That it
>" must be like flying a plane with 7,000 buttons, switches, and
> handles to manipulate in the cockpit. I absolutely fail to see how we can
> keep our growing programs firmly within our intellectual grip when by its
> sheer baroqueness the programming language - our basic tool, mind you! -
> already escapes our intellectual control". ("Humble Programmer", see
> Prgramming Methodology 1978).
>
> Well I think that the sheer size and complexity of Cocoa et al comes close
> to being an aeroplane cockpit and one which we are largely expected to learn
> to use from engineering manuals essentially concerned with listing the
> identity, composition and location of components,(not to mention the various
> incarnations of Xcode and Interface Builder). I am not saying that
> tremendous pains have not been taken to create a robust coherent system nor
> to document it. There have. Also there are many who have succeeded in
> mastering the system. Some will have done so through having grown up with it
> from early days, others will have had the fortune to attend (expensive)
> traning courses, and others still will have done so through dint of talent,
> perspicacity and hours of hard work. So mastery is possible. But I am not
> stupid nor a shirker nor a complete novice and I expect that the same can be
> said for most people who have had and are continuing to have horrendous
> dificulties in getting to use the system. It is clear that the programing
> interface to the Mac has serious usability issues.
>
> I cannot help touting one recent example. To specify the outlets etc
> between a class definition and Interface Builder on Leopard we are told to
> type the name of the class into a field and that thereafter IB will make the
> appropriate links with Xcode. It took me ten minutes of doing it this way
> and that before I realised that IB would only make the connections AFTER one
> had typed in the class name AND saved IB! We know from HCI research that it
> is little things like this which most frequently cause users to give up a

Re: Cocoa et al as HCI usability problem

[Jason Stephenson]

Johnny Lundy wrote:

Tutorials to me are pretty much useless, as I am not looking for a "step 
by step" cookbook to just getting something working, but rather a 
discussion of the why. How many times have we seen a tutorial say 
something like "control-drag from the textfield to the File's Owner 
object?" (just a random example). OK, I can do that, but it is a waste 
of my time - it's like paint-by-number when trying to learn art. Take 
the "Currency Converter With Bindings" much-touted tutorial; it actually 
uses a method that is deprecated.


It's my eagerness to explore and understand all of this rich collection 
of functions that frustrates me when the documentation doesn't go into 
enough depth.


Have you read the Cocoa Fundamentals Guide?

http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/Introduction/chapter_1_section_1.html

Much of what you seek is explained therein. If the Guide makes no sense 
to you, I'd suggest picking up some basic books on OO programming and 
design patterns. Read them, then come back to the Cocoa Fundamentals Guide.


Cheers,
Jason

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Cocoa et al as HCI usability problem

[Johnny Lundy]

For the record, my comments weren't about it being difficult; it's  
about the documentation not providing the information needed to use it.


It's a beautiful API, as you say with tons of work done to implement  
these reusable constructs. The documentation is voluminous, but in too  
many cases just repeats the name of the method or rephrases the method  
name. The examples stop just when they were getting to a line that  
would illustrate how to use the construct. And most of the items don't  
have an example.


Tutorials to me are pretty much useless, as I am not looking for a  
"step by step" cookbook to just getting something working, but rather  
a discussion of the why. How many times have we seen a tutorial say  
something like "control-drag from the textfield to the File's Owner  
object?" (just a random example). OK, I can do that, but it is a waste  
of my time - it's like paint-by-number when trying to learn art. Take  
the "Currency Converter With Bindings" much-touted tutorial; it  
actually uses a method that is deprecated.


It's my eagerness to explore and understand all of this rich  
collection of functions that frustrates me when the documentation  
doesn't go into enough depth.


If I thought the API itself had problems, I would just give up. I have  
heard people, very successful Java programmers, say they "didn't care"  
for Obj-C/Cocoa. Not me - I want to learn all I can. I have no Java  
books and six Cocoa books. I think this API is the coolest thing ever.  
Thus the frustration with the documentation.


But I am still very very hesitant to put another NSPopUpButton on my  
interface, because of the complete absence of guidance on how to  
implement the thing, and the many days it took to get a single one  
working, and even now I have no idea why it works - one of the random  
combinations of checkboxes and popup choices did the trick.


I can do target/action and outlets - I want to learn bindings. If it's  
a single-term binding, I can do it now.


I'm just going to finish Aaron's third edition, which arrived two days  
ago, and see if anything has changed in things like model key paths,  
isa-swizzling and so forth.



Well what can you do.  Not sure why but lately many newcomers have
been showing up and complaining about Cocoa's difficulty.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSTreeController problems

[Charles Srstka]

Thanks, that looks very useful. I only have one trepidation about it,  
which concerns this:


On May 18, 2008, at 3:33 PM, Jonathan Dann wrote:

- (NSArray *)rootNodes;
{
return [[self arrangedObjects] childNodes];
}


Isn't -arrangedObjects one of those methods you're never supposed to  
call manually, only through bindings? At least, that seems to be the  
vibe I picked up while searching the list before posting my question.  
The docs say this:


Returns an proxy root tree node for the containing the receiver’s  
sorted content objects.


...



Prior to Mac OS X v10.5 this method returned an opaque root node  
representing all the currently displayed objects. This method should  
be used for binding, no assumption should be made about what methods  
this object supports.



which of course is nice and ambiguous. It says no assumption should be  
made, but says that in a paragraph prefixed by "Prior to Mac OS X  
v10.5". Since the root note was opaque and unreliable as to format  
prior to OS X v10.5, does that mean that it *can* be reliably used now  
that it is defined as an (sic) proxy root tree node for the (sic)  
containing the receiver's sorted content objects, or does that still  
apply?


Thanks,
Charles___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: releasing NSKeyedUnarchiver causes crash

[Jonathan Dann]

On 18 May 2008, at 18:04, Markus Spoettl wrote:


On May 18, 2008, at 5:25 AM, Klaus Backert wrote:
- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName  
error:(NSError **)outError

{
  *outError = nil;
  NSKeyedUnarchiver *archiver;
  archiver = [[NSKeyedUnarchiver alloc] initForReadingWithData:  
data];


  // release current data
  [tracks release];
  tracks = [archiver decodeObjectForKey: @"myobject"];
  [tracks retain];




As tracks seems to be an ivar, it would likely be better practice to  
handle your memory management in an accessor, this way you never have  
to remember to write retain and release multiple times:


- (void)setTracks:(id)newTracks;
{
if(tracks == newTracks)
return;
[tracks release];
tracks = [newTracks retain];
}

you can the just call [self setTracks:newValue];

see here:

http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmAccessorMethods.html

To avoid writing accessors altogether, use Obj-C 2.0 properties.

http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_5_section_2.html#/ 
/apple_ref/doc/uid/TP30001163-CH17-SW13


Sorry if I've told you things you know already and there was another  
perfectly valid reason for doing what you did.


Jon

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[P Teeson]

begin rant:

Oh me oh my the poor newcomers to Cocoa. Sorry folks back in the days  
of 360 mainframes there were manuals and they were inscrutable.
But if you took the Winston Churchill aproach and spent some blood,  
sweat, toil and tears you would probably become a 1/2 decent  
assembler language programmer.


Same with Obj- C - if you know C you can grok Obj-C in at most a week  
- less if you are experienced. You won't be a master of it for a year  
or so of serious programming.

But that's true of acquiring literacy in any field.

Finally in this spoon fed age of sound bytes and simplistic and  
thoughtless political and economic panacea's in a world far more  
complex that when I grew up (70 years ago)

you newbies to Cocoa need to do what the docs provide you with.

RTFM! and sweat it out. Or else take the blue pill! Sheesh they all  
want pay for no work!


rant ends:
On 18-May-08, at 1:56 PM, Michael Vannorsdel wrote:

Well what can you do.  Not sure why but lately many newcomers have  
been showing up and complaining about Cocoa's difficulty.  I'm not  
sure if they've done GUI work before, but I remember my days with  
PowerPlant and spending a massive amount of time just creating the  
GUI and the code to back it.  Perhaps this is what gave me the  
sense of how much time Cocoa saves.  It's easy to take things like  
webviews for granted.  I can guess the amount of code Apple wrote  
to back those to work out of the box is pretty massive and  
complicated.


If programming was just drag and drop and clicking some option  
boxes users could just write their own programs.  But the fact is  
programming is far more complicated than that (and probably will be  
for a long time) and making such a framework would take a decade or  
more, by which time it would be obsolete and outdated.


For professionals the GUI is a smaller part of development thanks  
to time saved by Cocoa.  If I have to write my own controls from  
scratch, I will as it's what programmers do, write code.  But I'm  
thankful 99% of the time I can use something from Cocoa that comes  
with much of the code already done for me.


I guess some people are upset Cocoa doesn't do enough, or all, of  
the work for them.  I'm more of the people happy Cocoa does any  
work for me at all.  If it saves me time, it's a good thing.



On May 18, 2008, at 10:41 AM, Jens Alfke wrote:

"Hobbyists"? I think "professionals" is more accurate — especially  
since in the early days of the Mac you had to spend hundreds of  
dollars to become a developer and get access to tools and  
documentation.


I can see your point about obsessive hackers having the stamina to  
overcome complicated APIs, but any platform vendor's main  
objective in developer tools is to target professional developers  
who will create the products that make the platform attractive to  
customers. "Professional" doesn't necessarily imply a big company;  
I refer equally to startups and indie outfits, anyone seriously  
devoted to creating a product.


In Apple's defense, the task of implementing a sophisticated GUI  
on such limited computers was extremely difficult. The top goals  
were usability, decent performance, and affordable price. That  
left no leeway for making the APIs themselves easy to use — the  
niceties we take for granted like object-oriented programming  
would have used up way too much of that 128k of RAM and 64k of ROM.


(Yes, some of the first GUIs were written in the first OOP  
language, Smalltalk. But the Xerox computers that ran Smalltalk-80  
cost $10,000 or more; the ones that ran it with any kind of decent  
performance (the "Dorado") cost $50,000 and were basically  
supercomputers. They all had ten times as much RAM as the first  
Mac, and had custom CPUs with programmable microcode optimized for  
Smalltalk. Even so, performance was much worse than the original  
Mac, and the GUI was much cruder and harder to use. I'd already  
been using Smalltalk-80 when the first Mac came out, and the Mac's  
speed and aesthetics were just jaw-dropping.)


Anyway.

I have to say I find this whole discussion frustrating. The  
attitude of some people seems to be that writing computer  
programs, of arbitrary complexity, should be as easy as using a  
word processor. That's a Utopian goal at best, and more generally  
just naïve. Of course we should be trying to make the APIs and  
tools and documentation more useable; that's a constant task, and  
a very difficult one, and one Apple's doing a good job at. (The  
complexity under the hood is terrifying, and it's already been  
covered up enough that in an hour an experienced developer can  
throw together an app that fifteen years ago would have sold for  
$100.)


Face it, any sort of serious creative endeavor is hard! There's no  
way around it. And the hardest part is learning the techniques and  
tools. If you wanted to build a robot, play Vivaldi on the violin,  
design a house, paint landscapes, or cure 

Re: NSTreeController problems

[Jonathan Dann]

On 18 May 2008, at 20:57, Charles Srstka wrote:

Lately, I've been trying to update my stodgy old ways and try to  
incorporate some of the new technologies Cocoa has picked up over  
the years when starting new projects (my main app has had to be  
compatible with older OS X versions, so I haven't had much  
opportunity to jump into the world of bindings prior to now). One of  
these is NSTreeController. Unfortunately, I'm having a bit of  
trouble using figuring out how to do what I want with it.


1. The order of the objects in my (non-Core Data) data model is  
sometimes important, so rather than using the tree controller to add  
objects, I have been adding them manually by calling the appropriate  
-insertObject:inatIndex: methods. Okay, that works pretty well,  
and the objects show up in the NSOutlineView. However, I'd like to  
select the objects after I insert them. Now, I know where these  
objects are in the model, but since the order of the objects in the  
outline view might be different due to the user clicking on one  
column header or another to sort, and since the index paths sent to  
the tree controller's -setSelectedIndexPaths: method seem to be  
based on the interface, not the model, I don't know exactly where  
these objects are in order to select them. NSTreeController appears  
to have no -indexPathForObject: method or anything similar - does  
anyone know a way around this?


	1a. At first I thought that since I am making a sibling to the  
currently selected object, I could just get the parent's index path  
via [[treeController selectionIndexPath]  
indexPathByRemovingLastIndex], then get the node at that index path  
and iterate through its -childNodes until I find the one whose - 
representedObject is the correct model object, but there doesn't  
seem to be any way to get NSTreeController to give the node (or the  
model object, for that matter) for an index path. Does anyone else  
find this a little bizarre


To have an indexPathForObject method you need this:


- (NSArray *)rootNodes;
{
return [[self arrangedObjects] childNodes];
}

// this is a depth-first search
- (NSArray *)flattenedNodes;
{
NSMutableArray *mutableArray = [NSMutableArray array];
for (NSTreeNode *node in [self rootNodes]) {
[mutableArray addObject:node];
if (![[node valueForKey:[self leafKeyPath]] boolValue])
[mutableArray addObjectsFromArray:[node 
valueForKey:@"descendants"]];
}
return [[mutableArray copy] autorelease];   
}

- (NSTreeNode *)treeNodeForObject:(id)object;
{   
NSTreeNode *treeNode = nil;
for (NSTreeNode *node in [self flattenedNodes]) {
if ([node representedObject] == object) {
treeNode = node;
break;
}
}
return treeNode;
}

- (NSIndexPath *)indexPathToObject:(id)object;
{
return [[self treeNodeForObject:object] indexPath];
}

They're all separate methods as I have quite a few extensions on  
NSTreeController!




2. Okay, so I've got my objects displaying in an NSOutlineView, and  
now I'd like to add a search feature. Rather than eliminating the  
options that don't match, what I want to do is find the object,  
expand all its ancestors in the outline view so it's visible, and  
select it. Finding the model object is easy, and doing the rest  
*would* be easy enough if I weren't using NSTreeController - just  
climb the family tree, use -rowForItem: for each, expand it, and  
then use -rowForItem: to get the object and select it. Of course,  
with NSTreeController we have all these NSTreeNode objects instead  
of the actual objects themselves in the outline view, so - 
rowForItem: won't work. Is there any way to find the rows for the  
various nodes in the family tree of an object without resorting to  
just iterating through every row in the outline view? Any way to get  
the tree node for a given model object?


Now you have a treeNode for object you can as the NSOutlineView to  
expand that item (the NSTreeNode) using -expandItem:


Ive recently written two posts on NSTreeController, the first is non- 
Core Data the second is with core data but the sample project has a  
load of extensions that let you do what you want to do. They're at


http://jonathandann.wordpress.com/2008/04/06/using-nstreecontroller/

and

http://jonathandann.wordpress.com/2008/05/13/nstreecontroller-and-core-data-sorted/

Hope this helps

Jon



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

validateMenuItem() not always being called

[jeffs87]

Hi,

I'm new to Cocoa and I created a Document-based Application with New 
Project.  I added a validateMenuItem() method to my document class and 
it is only being called when you click on the FIle menu, not any of the 
other menus.  Is the document the correct place for this or do I need o 
add a controller class?  If I do need to add a controller class, how 
would I go about doing that?


thanks
Jeff

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[I. Savant]

On May 18, 2008, at 12:41 PM, Jens Alfke wrote:

Maybe I'm taking this too personally, but I sense a subtext that  
some people think the task of software design itself is somewhat  
trivial, more like programming a VCR than like architecture or  
painting or chemistry



  ... well it *should* be. It probably *will* be some day (in the  
distant future). but not today. Like any other technical profession,  
it takes intensive research and studying (as you more or less said). I  
share your frustration with some of the sentiment shown here.


  An employer of mine was shocked - SHOCKED - to learn that the Great  
and Powerful Cocoa did not automagically make a (statically-drawn)  
graph in a custom view (which is all he originally asked for) fully- 
interactive as in Excel with no extra development effort. He was even  
more shocked (yes, SHOCKED) to learn that such an interactive view  
would take a single developer months (probably a year or more) to  
approach the lofty level of sophistication he described. He expected  
it in a few weeks.


  His words: "I thought Cocoa was the most advanced platform out  
there." It sounded accusatory. I laughed and explained that the best  
damned bricks and two-by-fours in the world won't suddenly self- 
assemble and become a mansion. Drawing a pie chart is a far cry from  
Excel graphs on steroids. That's a bit harder. Besides, I heard  
steroids shrink your bullet points.


  In short, I believe Cocoa is a victim of its own superiority.  
People seem to expect:


  "Computer, reconfigure the main deflector to transmit the entire  
contents of Wikipedia in the form of tachyon bursts using a  
triaxilating frequency on a covariant subspace band."


  < The computer chirps happily, and those backward, planet-bound  
savages now know all about our great nations: http://en.wikipedia.org/wiki/Principality_of_Sealand 
 >


--
I.S.




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

NSTreeController problems

[Charles Srstka]

Lately, I've been trying to update my stodgy old ways and try to  
incorporate some of the new technologies Cocoa has picked up over the  
years when starting new projects (my main app has had to be compatible  
with older OS X versions, so I haven't had much opportunity to jump  
into the world of bindings prior to now). One of these is  
NSTreeController. Unfortunately, I'm having a bit of trouble using  
figuring out how to do what I want with it.


1. The order of the objects in my (non-Core Data) data model is  
sometimes important, so rather than using the tree controller to add  
objects, I have been adding them manually by calling the appropriate - 
insertObject:inatIndex: methods. Okay, that works pretty well,  
and the objects show up in the NSOutlineView. However, I'd like to  
select the objects after I insert them. Now, I know where these  
objects are in the model, but since the order of the objects in the  
outline view might be different due to the user clicking on one column  
header or another to sort, and since the index paths sent to the tree  
controller's -setSelectedIndexPaths: method seem to be based on the  
interface, not the model, I don't know exactly where these objects are  
in order to select them. NSTreeController appears to have no - 
indexPathForObject: method or anything similar - does anyone know a  
way around this?


	1a. At first I thought that since I am making a sibling to the  
currently selected object, I could just get the parent's index path  
via [[treeController selectionIndexPath]  
indexPathByRemovingLastIndex], then get the node at that index path  
and iterate through its -childNodes until I find the one whose - 
representedObject is the correct model object, but there doesn't seem  
to be any way to get NSTreeController to give the node (or the model  
object, for that matter) for an index path. Does anyone else find this  
a little bizarre?


2. Okay, so I've got my objects displaying in an NSOutlineView, and  
now I'd like to add a search feature. Rather than eliminating the  
options that don't match, what I want to do is find the object, expand  
all its ancestors in the outline view so it's visible, and select it.  
Finding the model object is easy, and doing the rest *would* be easy  
enough if I weren't using NSTreeController - just climb the family  
tree, use -rowForItem: for each, expand it, and then use -rowForItem:  
to get the object and select it. Of course, with NSTreeController we  
have all these NSTreeNode objects instead of the actual objects  
themselves in the outline view, so -rowForItem: won't work. Is there  
any way to find the rows for the various nodes in the family tree of  
an object without resorting to just iterating through every row in the  
outline view? Any way to get the tree node for a given model object?


For me, the jury's still out - are these new bindings features really  
that useful, or is the best route just to pretend it's 2002 and  
continue to do things via the simpler method of making an outline  
delegate?


Any assistance you can give is greatly appreciated.

Charles
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: The challenge for Cocoa's on-line documentation

[Scott Anguish]

bindings is discussed in the Cocoa Bindings Reference

the UI settings alone don't take into account all the usage patterns.

although there is no question that documentation could always be  
better (and that's coming from someone in techpubs).



On May 17, 2008, at 4:16 PM, Johnny Lundy wrote:

- Interface Builder User Guide ignores the dozens of checkboxes and  
popups that appear in the Bindings panes and instead rambles on for  
pages about rarely-used features.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: CATransactions not working

[Brian Christensen]

On May 18, 2008, at 12:00 , Adam Radestock wrote:


Hi everyone,

I've been struggling to work out how to animate some properties on  
my NSButton subclass. I have looked through all the examples given  
in Apple's docs, but can't work out why my code doesn't animate.


Where exactly are you invoking this code? Is it in awakeFromNib?

/brian



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSTextView Font Substitution

[Ken Thomases]

On May 17, 2008, at 8:36 AM, Gerriet M. Denkmann wrote:

So: is there a way in Tiger to tell the text system to prefer  
FixedPitchFonts?


Possibly using NSFontDescriptor.  You can specify NSFontMonoSpaceTrait  
as part of its symbolic traits.


If nothing else, you can specify the list of fonts to fallback on  
explicitly with NSFontCascadeListAttribute.


-Ken
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSStream, NSInputStream, NSOutputStream

[Ken Thomases]

On May 18, 2008, at 10:50 AM, John MacMullin wrote:

I modified slightly the Echo Server code sample from Apple with the  
following results.


To which sample are you referring?  I assume you mean the sample  
called CocoaEcho at .


 One, I couldn't stream a large file from a polling routine.  More  
than likely it would cancel because of a Sigterm 15.


SIGTERM, really?  I can't think of why or how a SIGTERM would be  
raised by the system or the frameworks.  I can see SIGPIPE, SIGTRAP,  
or SIGABRT.  And, of course, programming error can result in SIGBUS or  
SIGSEGV.


Hmm.  Perhaps launchd might terminate a service with SIGTERM if it  
determined that the service was misbehaving somehow.



It appears from reading the docs that the user cannot detect the end  
of a stream and that the NSStreamEventEndEncountered only detects a  
close.


What is it that you would call the end of a stream other than it being  
closed?


Two, when unarchiving a file in a client input stream delegate  
method, if the stream terminated from the server because it was too  
large, the client terminates on an unarchiver error because it  
didn't get the whole stream.


That doesn't seem surprising.

 Third, the output stream methods shown in Echo Server are polling  
methods, not delegate methods.


Well, it does blocking output, true.  And it doesn't account for the  
possibility of partial writes.  If it were to account for that, I  
would expect that it would loop around the [ostream write:buffer  
maxLength:actuallyRead], advancing the buffer and decrementing the  
length each time.  And it would handle errors.


For it to properly perform asynchronous output using delegate methods,  
it would need to buffer the data it receives from clients.  But it  
would have to impose some limit on the amount of data it is willing to  
buffer before it can be written out.  When it hit that limit, it would  
have to stop reading from that client until it could send some of its  
output.


By writing synchronously, it's effectively doing that with some  
automatic, smallish buffer supplied by the underlying APIs.  However,  
a block on one client causes a block of the entire server.


A better approach might be to suspend processing of that one client's  
input stream by removing it from the runloop.  Then, when that  
client's buffer drained a bit, due to some  
NSStreamEventHasSpaceAvailable events, the input stream could be re- 
added to the runloop.  If you just ignore  
NSStreamEventHasSpaceAvailable events rather than unscheduling the  
input stream, then I think you'll get them in a tight loop and your  
server will eat CPU like mad.



1. How do I stream a large file between connections or is NSStream  
the wrong tool?  Can the stream size be modified?


2. What is the largest stream size?


There's no such thing as "stream size".  That's one of the defining  
characteristics of a stream.


3. Is it possible to detect a valid archive before I unarchive it,  
or do I simply have to intercept the exception?


I think you just have to catch the exception.

4. How does one trigger and make available a file an output stream  
so that the delegate methods can be used?


I don't understand what you're asking here.

-Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSStream, NSInputStream, NSOutputStream

[Jens Alfke]

On 18 May '08, at 8:50 AM, John MacMullin wrote:

I modified slightly the Echo Server code sample from Apple with the  
following results.  One, I couldn't stream a large file from a  
polling routine.  More than likely it would cancel because of a  
Sigterm 15.


Whenever you report a crash, a backtrace is very helpful. Or at least  
tell us what function/method the crash was in. This shouldn't crash,  
so the problem is probably in something in your code.


It appears from reading the docs that the user cannot detect the end  
of a stream and that the NSStreamEventEndEncountered only detects a  
close.


"End of stream" and "close" are the same thing: a TCP input stream  
ends when the other side closes the connection (or crashes...)


Two, when unarchiving a file in a client input stream delegate  
method, if the stream terminated from the server because it was too  
large, the client terminates on an unarchiver error because it  
didn't get the whole stream.


A stream won't ever terminate due to length. You can send gigabyte  
after gigabyte over a TCP stream, as many happy BitTorrent users can  
attest ;-)


But yes, if the incoming stream closed before sending all the data the  
reader needed, then I would expect the reader to report an error. This  
shouldn't cause a crash, though; it sounds like your code isn't  
handling the error gracefully.


Third, the output stream methods shown in Echo Server are polling  
methods, not delegate methods.


The CocoaEcho sample? I just looked at it, and you're right. The  
writing code is badly designed. The client will block in a 'while'  
loop until all the data is sent, and the server code will simply drop  
response data on the floor if there isn't room to send it. I just  
filed feedback on the web page for the sample.


1. How do I stream a large file between connections or is NSStream  
the wrong tool?  Can the stream size be modified?


Most of the CocoaEcho code is reasonable as a base for doing this. Rip  
out the server-side code that echoes the data back, and instead write  
the data to a file.


On the client/sender side, it's best to use the 'spaceAvailable'  
delegate call, as you said. In response to that call, read some data  
from the file into a buffer, then write it to the stream. Something  
like 4k will do. Pay attention to the return value of the write, which  
tells you how many bytes actually got written, and advance a file- 
position instance variable by that amount. That'll tell you the  
position to read from in the input file next time.



2. What is the largest stream size?


There isn't one. TCP was designed to handle arbitrary length streams.  
There are internal byte counters but they just wrap around harmlessly  
after 4GB.


3. Is it possible to detect a valid archive before I unarchive it,  
or do I simply have to intercept the exception?


No. If you have data in archive format, you have to just hand it to  
NSUnarchiver and wrap the call in @try/@catch.


But you said you were sending a file? In that case you should just  
send it as a stream of bytes. If you're reading the entire file into  
an NSData and then sending that with NSArchiver, that's a huge amount  
of overhead for no gain.


4. How does one trigger and make available a file an output stream  
so that the delegate methods can be used?	


I don't understand that question. Can you give more detail? (Or  
perhaps I answered it above under #1.)


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Michael Vannorsdel]

Well what can you do.  Not sure why but lately many newcomers have  
been showing up and complaining about Cocoa's difficulty.  I'm not  
sure if they've done GUI work before, but I remember my days with  
PowerPlant and spending a massive amount of time just creating the GUI  
and the code to back it.  Perhaps this is what gave me the sense of  
how much time Cocoa saves.  It's easy to take things like webviews for  
granted.  I can guess the amount of code Apple wrote to back those to  
work out of the box is pretty massive and complicated.


If programming was just drag and drop and clicking some option boxes  
users could just write their own programs.  But the fact is  
programming is far more complicated than that (and probably will be  
for a long time) and making such a framework would take a decade or  
more, by which time it would be obsolete and outdated.


For professionals the GUI is a smaller part of development thanks to  
time saved by Cocoa.  If I have to write my own controls from scratch,  
I will as it's what programmers do, write code.  But I'm thankful 99%  
of the time I can use something from Cocoa that comes with much of the  
code already done for me.


I guess some people are upset Cocoa doesn't do enough, or all, of the  
work for them.  I'm more of the people happy Cocoa does any work for  
me at all.  If it saves me time, it's a good thing.



On May 18, 2008, at 10:41 AM, Jens Alfke wrote:

"Hobbyists"? I think "professionals" is more accurate — especially  
since in the early days of the Mac you had to spend hundreds of  
dollars to become a developer and get access to tools and  
documentation.


I can see your point about obsessive hackers having the stamina to  
overcome complicated APIs, but any platform vendor's main objective  
in developer tools is to target professional developers who will  
create the products that make the platform attractive to customers.  
"Professional" doesn't necessarily imply a big company; I refer  
equally to startups and indie outfits, anyone seriously devoted to  
creating a product.


In Apple's defense, the task of implementing a sophisticated GUI on  
such limited computers was extremely difficult. The top goals were  
usability, decent performance, and affordable price. That left no  
leeway for making the APIs themselves easy to use — the niceties we  
take for granted like object-oriented programming would have used up  
way too much of that 128k of RAM and 64k of ROM.


(Yes, some of the first GUIs were written in the first OOP language,  
Smalltalk. But the Xerox computers that ran Smalltalk-80 cost  
$10,000 or more; the ones that ran it with any kind of decent  
performance (the "Dorado") cost $50,000 and were basically  
supercomputers. They all had ten times as much RAM as the first Mac,  
and had custom CPUs with programmable microcode optimized for  
Smalltalk. Even so, performance was much worse than the original  
Mac, and the GUI was much cruder and harder to use. I'd already been  
using Smalltalk-80 when the first Mac came out, and the Mac's speed  
and aesthetics were just jaw-dropping.)


Anyway.

I have to say I find this whole discussion frustrating. The attitude  
of some people seems to be that writing computer programs, of  
arbitrary complexity, should be as easy as using a word processor.  
That's a Utopian goal at best, and more generally just naïve. Of  
course we should be trying to make the APIs and tools and  
documentation more useable; that's a constant task, and a very  
difficult one, and one Apple's doing a good job at. (The complexity  
under the hood is terrifying, and it's already been covered up  
enough that in an hour an experienced developer can throw together  
an app that fifteen years ago would have sold for $100.)


Face it, any sort of serious creative endeavor is hard! There's no  
way around it. And the hardest part is learning the techniques and  
tools. If you wanted to build a robot, play Vivaldi on the violin,  
design a house, paint landscapes, or cure Ebola, you'd have to  
accept that it would take months or years of serious study, that the  
tools and documentation would sometimes be hard to use, and you'd  
have to put up with frustration before you mastered the skills.


Why on earth is writing the best GUI applications in the world  
supposed to be trivial by comparison? Maybe I'm taking this too  
personally, but I sense a subtext that some people think the task of  
software design itself is somewhat trivial, more like programming a  
VCR than like architecture or painting or chemistry.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Working through a problem...

[Scott Ribe]

> How do I get IB to select the tableView instead of the columnView?

Get out of the column. Drag to the header or to the edge between columns.

-- 
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-0567 voice


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: releasing NSKeyedUnarchiver causes crash

[Markus Spoettl]

On May 18, 2008, at 5:25 AM, Klaus Backert wrote:
- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName  
error:(NSError **)outError

{
   *outError = nil;
   NSKeyedUnarchiver *archiver;
   archiver = [[NSKeyedUnarchiver alloc] initForReadingWithData:  
data];


   // release current data
   [tracks release];
   tracks = [archiver decodeObjectForKey: @"myobject"];
   [tracks retain];


may be because this is missing:

[archiver finishDecoding];



That wasn't it but thanks for helping.

The real reason was that I forgot to retain the objects decoded in  
tracks:initWithCoder: after decoding, so instead of


  timeStamp = [[decoder decodeObjectForKey:@"timeStamp"] retain];

I had

  timeStamp = [decoder decodeObjectForKey:@"timeStamp"];

and apparently the NSKeyedUnarchiver was the only think keeping that  
data alive.


Well, I apologize for wasting your time.

Regards
Markus
--
__
Markus Spoettl



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSTextView Font Substitution

[Jens Alfke]

On 17 May '08, at 6:36 AM, Gerriet M. Denkmann wrote:

I have an NSTextView with no "Multiple fonts allowed" (isRichText =  
NO).

The font is the userFixedPitchFontOfSize: 0 (Monaco 10 pt).
But when I insert a THAI CHARACTER SARA E (Unicode 0E40), which has  
no glyph in Monaco, a replacement font is used.


Yup. Technically this is glyph substitution, not a change of font, so  
it's considered correct behavior even with multiple-fonts disallowed.



This is Lucida Grande, which is not a FixedPitchFont.
So things meant to be in nice columns get all messed up.
But if one has the "Additional Asian Fonts" installed, there is also  
Ayuthaya, which, being a FixedPitchFont, would be a much better  
replacement.
So: is there a way in Tiger to tell the text system to prefer  
FixedPitchFonts?


Not that I know of. But even if there were, there's no reason the  
character width in Ayuthaya has to match that of Monaco (or Courier or  
Andale Mono or...) so the column layout would probably still get  
messed up.


The only real solution would be to customize the layout manager to  
force it to use a single width for all glyphs, regardless of font. I  
think this could probably be done by subclassing NSLayoutManager, but  
I don't know the details.


(Of existing programmers' editors, I know that Xcode uses NSTextView  
but supports multiple fonts and so doesn't assume that text will  
always be fixed-pitch; while TextMate uses a custom text editing  
engine that always uses fixed character spacing.)


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Jens Alfke]

On 18 May '08, at 4:33 AM, Julius Guzy wrote:

Apple has been less celebrated for the humanity of its programming  
interface having, in my experience of Macs from the Lisa onwards,  
seemingly taken the attitude that its programmers were hobbyists,  
geeks essentially, who because of their enthusiasm would  
successfully negociate their way into the machine's innards.


"Hobbyists"? I think "professionals" is more accurate — especially  
since in the early days of the Mac you had to spend hundreds of  
dollars to become a developer and get access to tools and documentation.


I can see your point about obsessive hackers having the stamina to  
overcome complicated APIs, but any platform vendor's main objective in  
developer tools is to target professional developers who will create  
the products that make the platform attractive to customers.  
"Professional" doesn't necessarily imply a big company; I refer  
equally to startups and indie outfits, anyone seriously devoted to  
creating a product.


In Apple's defense, the task of implementing a sophisticated GUI on  
such limited computers was extremely difficult. The top goals were  
usability, decent performance, and affordable price. That left no  
leeway for making the APIs themselves easy to use — the niceties we  
take for granted like object-oriented programming would have used up  
way too much of that 128k of RAM and 64k of ROM.


(Yes, some of the first GUIs were written in the first OOP language,  
Smalltalk. But the Xerox computers that ran Smalltalk-80 cost $10,000  
or more; the ones that ran it with any kind of decent performance (the  
"Dorado") cost $50,000 and were basically supercomputers. They all had  
ten times as much RAM as the first Mac, and had custom CPUs with  
programmable microcode optimized for Smalltalk. Even so, performance  
was much worse than the original Mac, and the GUI was much cruder and  
harder to use. I'd already been using Smalltalk-80 when the first Mac  
came out, and the Mac's speed and aesthetics were just jaw-dropping.)


Anyway.

I have to say I find this whole discussion frustrating. The attitude  
of some people seems to be that writing computer programs, of  
arbitrary complexity, should be as easy as using a word processor.  
That's a Utopian goal at best, and more generally just naïve. Of  
course we should be trying to make the APIs and tools and  
documentation more useable; that's a constant task, and a very  
difficult one, and one Apple's doing a good job at. (The complexity  
under the hood is terrifying, and it's already been covered up enough  
that in an hour an experienced developer can throw together an app  
that fifteen years ago would have sold for $100.)


Face it, any sort of serious creative endeavor is hard! There's no way  
around it. And the hardest part is learning the techniques and tools.  
If you wanted to build a robot, play Vivaldi on the violin, design a  
house, paint landscapes, or cure Ebola, you'd have to accept that it  
would take months or years of serious study, that the tools and  
documentation would sometimes be hard to use, and you'd have to put up  
with frustration before you mastered the skills.


Why on earth is writing the best GUI applications in the world  
supposed to be trivial by comparison? Maybe I'm taking this too  
personally, but I sense a subtext that some people think the task of  
software design itself is somewhat trivial, more like programming a  
VCR than like architecture or painting or chemistry.


"Problems worthy of attack
 Prove their worth by hitting back." [Piet Hein]

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[David Wilson]

On Sun, May 18, 2008 at 10:39 AM, Erik Buck <[EMAIL PROTECTED]> wrote:
> Cocoa is the most consistent, elegant, and productive software development
> technology I have ever used, and I have used a lot.  Cocoa uses key
> metaphors and design patterns ubiquitously.  If the programmer is either
> unaware of the metaphors or  does not see their utility, it will be
> difficult to use Cocoa.  If a programmer fails to grasp a particular
> pattern, the whole framework may be incomprehensible because the pattern is
> most likely used throughout.

I have to second this. Cocoa certainly has its quirks, but it seems to
have far fewer of them than any other toolkit (especially any other
GUI toolkit) that I've ever worked with.

I daresay that 90% of the problems that I've seen with Cocoa usage
(either my own or that of others) is born out of the programmer
fighting the system. It's very easy to get an idea in your head about
how something "must" work, and because we're dealing with
Turing-complete languages here we can generally make something work
even if it requires taking a sledgehammer to the problem. And, of
course, when we're done forcing the round peg into the square hole,
we're frustrated that the toolkit didn't make it easy for us.

With Cocoa, there seems to a be a very simple guiding principle: If
you're frustrated because the system isn't letting you do what you
want, rethink what you want to do and how you want to do it. A lot of
thought and design has gone into Cocoa; it's worth respecting all of
that design and asking yourself, when you're fighting the frameworks,
if it's really the frameworks that are doing the wrong thing in that
instance- because, at least in my experience, chances are it's the
programmer.
-- 
- David T. Wilson
[EMAIL PROTECTED]
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Gary L. Wade]

Just to add some insight, when reading the Cocoa documentation, it's 
very helpful when a developer also has some degree of exposure to 
Interface Builder.  Take heart, though, as Interface Builder is just a 
click away.


Once you have an idea how things somewhat work within Interface Builder 
and have seen it simulate the interface within Interface Builder or run 
it in a sample application, lots of things in the documentation begin to 
make sense, especially the date picker.


[As a caveat, the date picker class is a very easy one for me to 
understand at face value, as I wrote a UI widget and class very much 
like it using THINK Class Library almost 15 years ago that was used in 
an industry leader's software product, and I'm a frequent development 
user of date/time technologies with respect to internationalization.]


As Aaron Hillegass says in the starting pages of his Cocoa intro book, 
and I'm paraphrasing, programming is hard, and if you don't get it 
immediately, it doesn't mean you're not smart; it just means you need 
some more time working through the examples.


By the way, you really should build and try out the examples installed 
under the /Developer path.  Build them, add breakpoints in strategic 
places, make changes, incorporate their code in your own, rewrite it as 
needed to suit your own needs, and you'll be happier.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

CATransactions not working

[Adam Radestock]

Hi everyone,

I've been struggling to work out how to animate some properties on my  
NSButton subclass. I have looked through all the examples given in  
Apple's docs, but can't work out why my code doesn't animate.


My code is:
[CATransaction begin]; // Begin grouping animated property changes

if (highlightEffect == SGUIButtonOpaqueEffect) {

[CATransaction begin];
[CATransaction setValue:[NSNumber numberWithFloat:5.0f]
 
forKey:kCATransactionAnimationDuration];
self.layer.opacity = 1.0;
[CATransaction commit];

} else if (highlightEffect == SGUIButtonSlideEffect) {

[CATransaction begin];
[CATransaction setValue:[NSNumber numberWithFloat:1.0f]
 
forKey:kCATransactionAnimationDuration];
		self.layer.bounds = CGRectMake(self.layer.position.x,  
self.layer.position.y, self.bounds.size.width + 10,  
self.bounds.size.height);

[CATransaction commit];

[CATransaction begin];
[CATransaction setValue:[NSNumber numberWithFloat:2.0f]
 
forKey:kCATransactionAnimationDuration];
		self.layer.position = CGPointMake(self.layer.position.x -  
self.layer.bounds.size.width, self.layer.position.y);

[CATransaction commit];

}

[CATransaction commit];

Can anyone see any problems with this? Why aren't there any animations  
when this code executes?


Any help greatly appreciated.

Adam Radestock
Glass Monkey Software
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

NSStream, NSInputStream, NSOutputStream

[John MacMullin]

I modified slightly the Echo Server code sample from Apple with the  
following results.  One, I couldn't stream a large file from a  
polling routine.  More than likely it would cancel because of a  
Sigterm 15.


It appears from reading the docs that the user cannot detect the end  
of a stream and that the NSStreamEventEndEncountered only detects a  
close. Two, when unarchiving a file in a client input stream delegate  
method, if the stream terminated from the server because it was too  
large, the client terminates on an unarchiver error because it didn't  
get the whole stream.  Third, the output stream methods shown in Echo  
Server are polling methods, not delegate methods.


So:

1. How do I stream a large file between connections or is NSStream  
the wrong tool?  Can the stream size be modified?


2. What is the largest stream size?

3. Is it possible to detect a valid archive before I unarchive it, or  
do I simply have to intercept the exception?


4. How does one trigger and make available a file an output stream so  
that the delegate methods can be used?	


Thank,

John MacMullin
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

NSTextView Font Substitution

[Gerriet M. Denkmann]

I have an NSTextView with no "Multiple fonts allowed" (isRichText = NO).
The font is the userFixedPitchFontOfSize: 0 (Monaco 10 pt).

But when I insert a THAI CHARACTER SARA E (Unicode 0E40), which has  
no glyph in Monaco, a replacement font is used. This is Lucida  
Grande, which is not a FixedPitchFont.

So things meant to be in nice columns get all messed up.

But if one has the "Additional Asian Fonts" installed, there is also  
Ayuthaya, which, being a FixedPitchFont, would be a much better  
replacement.


So: is there a way in Tiger to tell the text system to prefer  
FixedPitchFonts?


Kind regards,

Gerriet.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Erik Buck]

There are conventions and metaphors of human computer interfaces.
Apple used to provide interactive training programs to explain the use  
of a mouse to customers in stores.  My own father who is a brilliant  
scientist could not initially master double-click and fifteen years  
later frequently double clicks when a single click is adequate.  To  
follow up on the theme of the first post, the Attitude Direction  
Indicator (ADI) is a critical cockpit instrument that is absolutely  
obvious and second nature to a pilot, but most people off the street  
would need an explanation to understand its use.


The point is that we are not born knowing how to interact with  
computers.  We are trained, and sometimes the training is so thorough  
and internalized that later we can't imagine any other way to  
interact.  It is also clear that there have been  both evolutionary  
and revolutionary changes to HCI.  The acceptance of changes depends  
on how easy it is for humans to fit the changes into existing  
metaphors and/or adopt new metaphors and/o perceive the improvement if  
any that change may provide.  I remember the time when existing  
command line users and even DOS junkies could not understand why  
anyone would want to use a mouse.  They could not perceive any  
advantage to a mouse, and their internalized metaphors for interfacing  
with computers did not include graphical user interfaces. Many others  
could not understand why anyone would use a command line interface.


Now relate this to Cocoa.  Smalltalk stepped into a vacuum in the  
early 1970s and invented a whole new set of metaphors for  
programming.  Smalltalk's metaphors started with object oriented  
programming but included Model-View-Controller and many of the object  
oriented patterns such as decorators, composition, and hierarchies,  
that we still use and document today.   Objective-C mixes Smalltalk  
with C, and Cocoa/NeXTstep started by incorporating many of the  
venerable Smalltalk metaphors and patterns.  Cocoa did not stand  
still.  There have been refinements and adaptations to accommodate and  
exploit the C side of Objective-C too.


If you, the programmer, are unfamiliar with the metaphors used by  
Cocoa, you are a bit like the DOS junkie who can't understand the  
point of a GUI.  In some respects, the more invested and internalized  
you are with other metaphors, the harder it is for you to accept  
Cocoa.  Take heart.  There aren't many DOS junkies left.  For an  
interesting but probably irrelevant parallel, it took from about 1984  
when the Mac was released to about 1993 when the general public  
started using GUIs.  There is a correlation to the fact that it took  
from about 1997 when Apple started selling Cocoa technology to 2006 or  
so when Apple's developers embraced it.  The GUI pre-existed the Mac  
by 8 years or so.  NeXTstep pre-existed Cocoa by about 8 years or so.


Cocoa is the most consistent, elegant, and productive software  
development technology I have ever used, and I have used a lot.  Cocoa  
uses key metaphors and design patterns ubiquitously.  If the  
programmer is either unaware of the metaphors or  does not see their  
utility, it will be difficult to use Cocoa.  If a programmer fails to  
grasp a particular pattern, the whole framework may be  
incomprehensible because the pattern is most likely used throughout.


The attributes of Cocoa that make it so consistent and elegant are  
exactly the same attributes that I think newbies are complaining  
about.  The newbie complains that the reference documentation mentions  
delegates or tags or data sources or the responder chain or key value  
coding or bindings or targets or actions etc. without defining them.   
This is exactly like  a newbie complaining that clicking and dragging  
and selecting and double clicking are used throughout a GUI but not  
explained in the documentation for every application.  Once the GUI  
metaphors are internalized, it is unnecessary at best and annoying at  
worst to keep encountering mouse based selection explained in every  
user's guide.  The consistent application of the metaphors makes the  
GUI easy to use.  The consistent use of metaphors makes Cocoa easy to  
program. BUT YOU MUST UNDERSTAND THE METAPHORS FIRST in both cases.




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Conditionally modifying NIBs?

[Mike Fischer]

Am 18.05.2008 um 11:14 schrieb Uli Kusterer:


Am 14.05.2008 um 19:37 schrieb Mike Fischer:
Given the recent/ongoing discussion about bypassing Interface  
Builder I have one question/issue for which IB does not seem to  
provide any solution. Interface Builder and NIBs are nice and have  
many advantages but I am missing a way to build different versions  
of nib files depending on Project targets/settings. I'm wondering  
how others handle this?



I generally split up the NIB into several NIBs. That way, I can  
load the master NIB containing the window, and then load the sub- 
NIBs using NSViewController depending on which version of the app  
is built.


Thanks! That is basically the advice I got from Jon Hess and David  
Wilson. It transfers some of the burden to runtime but I guess this  
is generally the best way to get this done. It also seems to have  
other advantages like less complex nibs and better support for  
version control (svn).



I also have some view classes not unlike Javas GridBag and similar  
that arrange their subviews and, when used as a window's content  
view, can resize the window to fit their contents. Comes in very  
handy for all sorts of dynamic view arrangements, including using  
bindings to show/hide non-applicable parts and having the window  
magically re-layout in response to that. Though in that case I  
often just embed the views in an NSView that have to be shown/ 
hidden together, without loading them from separate NIBs.


Yes, I can see how that would help. I guess I'll be keeping that in  
mind when constructing and adding to my personal library of reusable  
classes.



Mike
--
Mike Fischer Softwareentwicklung, EDV-Beratung
Schulung, Vertrieb
Web: 
Note: I read this list in digest mode!
  Send me a private copy for faster responses.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa et al as HCI usability problem

[Jason Stephenson]

Julius,

You could change Apple for just about any other vendor, and Cocoa for 
just about another GUI/system interface, and your argument will still hold.


(Have you ever tried programming X11 with just XLib C calls? Nasty stuff 
that)


Also, please don't confuse the language, Objective-C in this case, with 
the frameworks/system interface. Objective-C is a very small language, 
and it is easy to keep the main things in mind. PL/1 is another matter 
altogether (So is C++ if you think about it.)


Cocoa is much larger, but the same could be said of  C and XLib 
respectively. Not to mention that on X you have many different GUI 
toolkits to choose from to abstract away the complexity of XLib: Xt, Qt, 
Tk, XAW, Motif, GNUStep, Gnome, KDE, etc., etc.


Modern computer systems are complex. There are many, many options of the 
programmer. If modern computer systems lacked this complexity, and if 
the published interfaces did not have APIs available so that programmers 
could make adequate use of this complexity, then we'd be stuck where we 
were in the early '80s, having to roll our own library for everything.


I don't think you can expect to lose the learning curve in any 
programming interface. APIs expose complexity, and at the same time, 
cover it up. Imagine if you had to implement your own 
Model-View-Controller paradigm for your GUI widgets before you could 
start making your own applications? That is the situation that you'd be 
in with something like XLib, or even the old Macintosh Toolbox. Today, 
that complexity is abstracted away rather neatly by the Cocoa framework, 
just as it would be on X if you used Motif or Qt or some other toolkit.


If you do want to just jump in and start writing code, then perhaps you 
should look into Python or some other "scripting" language. They do an 
even better job of hiding the complexity.


I also don't find any great difficulty in using Apple's documentation. 
The conceptual documents cover the concepts, and the reference 
documentation serves as a reference. No, I don't think you should learn 
to use Cocoa just from the conceptual documents, but I'm sure it is 
possible.


The simple fact of the matter is that documentation, just like a GUI, 
cannot be all things to all people. Programmers and those interested in 
programming are a particularly eclectic bunch. We each come at Cocoa for 
the first time with different experience, different reference points, 
and different expectations. One set of documentation cannot be expected 
to handle all of the possible permutations of programmer knowledge and 
experience. For this reason, other books exist written by third parties 
to cover those gaps or target different audiences.


In summary, I think it is a problem of all programming documentation and 
programming interface regardless of the platform or language, and I 
don't really see a way for a single vendor to resolve the issue, not do 
I think they really should.


Well, I'll shut up, now.

Cheers,
Jason
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

releasing NSKeyedUnarchiver causes crash

[Klaus Backert]

Am 18.05.2008 um 09:51 schrieb Markus Spoettl:

- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName  
error:(NSError **)outError

{
*outError = nil;
NSKeyedUnarchiver *archiver;
archiver = [[NSKeyedUnarchiver alloc] initForReadingWithData:  
data];


// release current data
[tracks release];
tracks = [archiver decodeObjectForKey: @"myobject"];
[tracks retain];


may be because this is missing:

[archiver finishDecoding];


[archiver release]; // <--- crash here, no crash if commented out
return YES;
}


Greetings
Klaus

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Cocoa et al as HCI usability problem

[Julius Guzy]

The very good , interesting and informative debate in this list  
concerning the accessibility of the programming environment to new  
users has it seems to me incresingly polarised between those who  
think the documentation more or less adequate and those like me who  
for whatever reason, have great difficulties making use of the  
facilities.


I think this debate relates to the same concerns and battles we had,  
and in many cases are still having about computer usability, namely  
the effective design of human-computer interfaces, aka HCI.


It is ironic that we are having this debate within an Apple  
programmer's mailing list. Apple has been celebrated for the  
usability of its machines and long may it continue to be so. However,  
Apple has been less celebrated for the humanity of its programming  
interface having, in my experience of Macs from the Lisa onwards,  
seemingly taken the attitude that its programmers were hobbyists,  
geeks essentially, who because of their enthusiasm would successfully  
negociate their way into the machine's innards. That said, the 9  
tomes of "Inside the Macintosh" documentation of the programmer's  
workshop were pretty good once you got into them but there was a lot  
less to get into then than there is today.


This question of volume of documentation and system size and  
complexity is significant to our debate. It is pertinent to quote  
what one of the great programming pioneers, Dijkstra said about PL/1:  
That it
	" must be like flying a plane with 7,000 buttons, switches, and  
handles to manipulate in the cockpit. I absolutely fail to see how we  
can keep our growing programs firmly within our intellectual grip  
when by its sheer baroqueness the programming language - our basic  
tool, mind you! - already escapes our intellectual control". ("Humble  
Programmer", see Prgramming Methodology 1978).


Well I think that the sheer size and complexity of Cocoa et al comes  
close to being an aeroplane cockpit and one which we are largely  
expected to learn to use from engineering manuals essentially  
concerned with listing the identity, composition and location of  
components,(not to mention the various incarnations of Xcode and  
Interface Builder). I am not saying that tremendous pains have not  
been taken to create a robust coherent system nor to document it.  
There have. Also there are many who have succeeded in mastering the  
system. Some will have done so through having grown up with it from  
early days, others will have had the fortune to attend (expensive)  
traning courses, and others still will have done so through dint of  
talent, perspicacity and hours of hard work. So mastery is possible.  
But I am not stupid nor a shirker nor a complete novice and I expect  
that the same can be said for most people who have had and are  
continuing to have horrendous dificulties in getting to use the  
system. It is clear that the programing interface to the Mac has  
serious usability issues.


I cannot help touting one recent example. To specify the outlets etc  
between a class definition and Interface Builder on Leopard we are  
told to type the name of the class into a field and that thereafter  
IB will make the appropriate links with Xcode. It took me ten minutes  
of doing it this way and that before I realised that IB would only  
make the connections AFTER one had typed in the class name AND saved  
IB! We know from HCI research that it is little things like this  
which most frequently cause users to give up and never touch the  
equipment again.


Now, of course, as programmers we are well used to wasting hours  
hacking through the underbrush to discover that to switch on the  
machine we need to hold down Alt-Escape with the right hand whilst  
depressing a button round the back of the machine with the left.  
(That was how in the 70s one turned on some of the PCs at Leicester  
Poly!). But what a waste of time and effort and how demoralising and  
off-putting to anyone but the most obstinate programmer. I deferred  
having a go at Cocoa for about three or four years because I knew it  
would be a struggle and these last five months or is it six have been  
horrorshow.


Let me state two principal facts.
1. Designing good user interfaces is hard.
2. Designing good user interfaces is expensive.

It is hard because every human being is an individual,
because there is seemingly a lot to learn
and because there are limits to the complexity we can handle.

It is expensive because the design of good HCI is primarily an  
empirical activity centered on user testing.


The question is then whether we and possibly apple should do anything  
about it.


Julius



http://juliuspaintings.co.uk



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Updat

Re: Conditionally modifying NIBs?

[Uli Kusterer]

Am 14.05.2008 um 19:37 schrieb Mike Fischer:
Given the recent/ongoing discussion about bypassing Interface  
Builder I have one question/issue for which IB does not seem to  
provide any solution. Interface Builder and NIBs are nice and have  
many advantages but I am missing a way to build different versions  
of nib files depending on Project targets/settings. I'm wondering  
how others handle this?



I generally split up the NIB into several NIBs. That way, I can load  
the master NIB containing the window, and then load the sub-NIBs using  
NSViewController depending on which version of the app is built.


I also have some view classes not unlike Javas GridBag and similar  
that arrange their subviews and, when used as a window's content view,  
can resize the window to fit their contents. Comes in very handy for  
all sorts of dynamic view arrangements, including using bindings to  
show/hide non-applicable parts and having the window magically re- 
layout in response to that. Though in that case I often just embed the  
views in an NSView that have to be shown/hidden together, without  
loading them from separate NIBs.


Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

releasing NSKeyedUnarchiver causes crash

[Markus Spoettl]

Hi all,

  once again I have a question I can't seem to figure out on my own.

I'm trying to implementing an NSDocument application, more  
specifically the load/store part of it. It actually works as expected,  
reading and writing my object graph to and from a file works fine. The  
problem is that when releasing the NSKeyedUnarchiver instance used to  
read the data, the application crashes - and I don't know why.


This is the exact code I'm using (tracks is an object that conforms to  
< NSCoding >)


- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
{
NSMutableData *data = [[NSMutableData alloc] init];
NSKeyedArchiver *archiver = [[NSKeyedArchiver alloc]  
initForWritingWithMutableData: data];

[archiver setOutputFormat: NSPropertyListBinaryFormat_v1_0];
[archiver encodeObject:tracks forKey: @"myobject"];
[archiver finishEncoding];
[archiver release];
return [data autorelease];
}

- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName error: 
(NSError **)outError

{
*outError = nil;
NSKeyedUnarchiver *archiver;
archiver = [[NSKeyedUnarchiver alloc] initForReadingWithData:  
data];


// release current data
[tracks release];
tracks = [archiver decodeObjectForKey: @"myobject"];
[tracks retain];
[archiver release]; // <--- crash here, no crash if commented out
return YES;
}

The crash happens when [archiver release] is called. Since I own the  
object I have to release it and in my understanding it should no  
longer be necessary (the reading is finished at that point).  
Furthermore Leaks reports a leak if archiver is not released (which  
seem to be perfectly valid).


I've also tried [archiver autorelease] but that only delays the crash  
a little.


I don't understand the mistake I'm making, please help. Thanks!

Regards
Markus
--
__
Markus Spoettl



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]