morris

http://developer.apple.com/documentation/Security/Reference/authorization_ref/01authref_ref/chapter_1.2_section_6.html

Bör finnas lite exempelkod nånstans på developer.apple.com också, men det hittar jag inte nu bara för det.

Du kan använda både C och Objective-C i m-filer och h-filer. Du kan bara använda C i c-filer. Följande är t ex helt legalt:

#import <stdlib.h>

-(void)sleep:(time_t)n {
	sleep(n);
}

http://developer.apple.com/documentation/Cocoa/Conceptual/MenuList/Tasks/EnablingMenuItems.html

Där finns en beskrivning på hur NSMenu söker efter ett objekt som implementerar sin selector. Vanligast brukar väl vara att man lägger metoden i controllern/delegaten till det fönster som ska påverkas, eller till NSApps controller/delegate.

Förmodligen ligger det object som implementerar -selectItem: inte i responder chain, vilket den måste göra för att ska kunna köra selectors från NSMenuItems. Vad är det för klass?

http://www.cocoadev.com/index.pl?DragAndDropTableView

Självklart, de använder ju helt olika metoder för att fråga sin datasource om data, och alla skickar ju med en referens till den view som frågar efter datan.

Nej, du kan använda samma datasource till dem allihop. Ett vanligt pattern är att låta fönstrets controllerklass vara datasource till innehållet i fönstret. Om du har flera tableviews, skapa outlets för dem allihop och kolla vilken i metoden, t ex:

-(int)numberOfRowsInTableView:(NSTableView *)tableView {
	if(tableView == usersTableView)
		return [users count];
	else if(tableView == groupsTableView)
		return [groups count];
	
	/* ska inte hända */
	return 0;
}

Klassmetoden kräver absolut path till något som är en bundle. Plocka ut ditt programs bundlereferens och kör en instansmetod såhär istället:

[[NSBundle mainBundle] pathForResource:@default ofType:@plist]

Lägg till plistan som resource i Xcode (där du lägger tiffar etc) och använd sedan NSBundles -pathForResource:ofType: för att hitta pathen till filen från programmet.

Har tyvärr inte med saken att göra. Problemet är att projektet är för stort och Xcode är för långsamt. Det är alltså gränssnittet vi pratar om här, xcodebuild är fortfarande ok-snabbt i terminalen.

Xcode är fruktansvärt långsamt tycker jag. Inte bara kompilatorn, som är vansinnigt trög jämfört med andra versioner, men också alla andra operationer som trådade indexeringar etc är extremt sega. Om inte Apple fixar Xcode snart börjar det bli dags att byta IDE faktiskt. Så dålig är den. Nu sitter jag visserligen på ett större projekt vilket kan förklara varför andra här inte ser några problem med hastigheten, men det känns ändå orimligt att utvecklingsmiljön ska vara såhär seg.

Att öppna projektfilen tar minst 30 sekunder. Att indexera från scratch tar 5 minuter. Att bygga utan en enda touchad fil tar 2 minuter. Att ladda in debuggern tar minst en minut. Samma med att öppna CVS-fönstret. Detta på en 2x2GHz G5 med 2 GB RAM.

"Operation not permitted" är lite missvisande. Det beror på att "grep foo /etc/*" matchar både /etc/passwd och /etc/httpd, varav den ena är en mapp. Att du däremot inte fick några resultat alls bortsett från felmeddelanden beror helt enkelt på att ditt användarnamn inte hittades. Mac OS X lagrar för tillfället sin användardatabas i NetInfo, och inte i den normal flatfilen /etc/passwd.

nidump -r /users .

Har du läst http://developer.apple.com/documentation/Cocoa/Conceptual/Streams/index.html?http://developer.apple.com/documentation/Cocoa/Conceptual/Streams/Articles/NetworkStreams.html#//apple_ref/doc/uid/20002277? Beskriver i alla fall hur man sätter upp socketströmmar med hjälp av -getStreamsToHost: port:inputStream:outputStream:. Kan också vara värt att läsa /Developer/Examples/Foundation/PictureSharing/, även om den använder BSD-sockets.

Tänk också på att NSStream bara går att använda på 10.3 och senare. Om du behöver supporta 10.2 kan det vara värt att kika på CFStream.

Vet inte vad Onyx är, men jag tvivlar att den har något läge speciellt för att avinstallera utvecklingsmiljön. Antar att du skulle kunna avinstallera de paket som ingår i Developer Tools med någon sorts avinstallerare, men det verkar säkrast att göra det med Apples script eftersom det verkar ha bättre koll på exakt vad som ska bort. Ska räcka med att köra

sudo /Developer/Tools/uninstall-devtools.pl

Skriv in ditt lösenord. Ska inte komma några fler frågor, bara massa meddelanden om vad den tar bort.

För övrigt är det inte skadligt att låta programmen ligga kvar, om det nu inte är hårddiskutrymmet du är orolig över. Om du däremot tar bort installationen lite halvt om halvt och sedan försöker installera nya devtools kan det bli problem.

Använd

/Developer/Tools/uninstall-devtools.pl

för att avinstallera Xcode. Den installerar till exempel ett par saker i /System/Library/PrivateFrameworks/DevTools* också (för att inte tala om kompilatorn och övriga unixverktyg i /usr).