On Jul 14, 2005, at 1:53 PM, Sean Kamath wrote:

So I have a question: Some of the variables are _foo and some are just
foo.  And "id <IServerData> server_"?  Is there some nomenclature
guide from Apple I can look at?  I try and name variables in the style
of the program I'm editing. . .But this one's hard, because we have
"NSString titleString;" and "NSPoint _mouseLocation;".  What's the
difference?

This drives me nuts too.  The original author of the software that became Chicken used straight embedded caps for instance variable names, like "connection".  I originally tried to follow his lead and did the same, but after working on Chicken for awhile, not knowing whether a variable was an ivar or a local began to drive me insane, so I switched to prefixing instance variables with 'm', like 'mConnection'.  Then Apple introduced key-value binding.  To be key-value binding compliant, instance variables should be prefixed with an underscore, like "_connection".  So in all new code, that's what I do.  

The result is a mish-mash of styles, and it drives me totally crazy.  

I do the same thing as you and try to write my code to match the style of whatever code it's going into - when I tweak Jared's code, I try to match his style (which I find to be very clean and readable).  But for very old code, like RFBConnection, when I write new code, I use whatever my current style is.

I mainly agree with this style guide for new code, with a few differences regarding spacing and curly brackets:
http://webkit.opendarwin.org/coding/coding-style.html

Huh.  I would have thought that as the connection that closed tore
down, it would remove the window shielding and all that, thus allowing
the keychain authorization, *THEN* the reconnect.  How about throwing
something into "connectionWillGoFullscreen" to make sure the keychain
is unlocked?

It does.  I'm not sure how this was coming about, but it looked as though Chicken was trying to authorize before tearing down the existing connection.

I don't think a user process can ask whether the keychain is unlocked - that'd probably be a security hole.  Not positive, though - I know nothing about programmatically interfacing with Keychain.

Jason