From spongelavapaul at mac.com Mon Jun 2 11:53:51 2008 From: spongelavapaul at mac.com (Paul Thomas) Date: Mon Jun 2 11:53:56 2008 Subject: Getting binary data linked into an executable Message-ID: <39C41E9D-072D-4E26-A7E8-5F9607F3238C@mac.com> I've got some huge test data that I need to access as C arrays inside a command line test app. I don't want use file I/O at runtime and the compiler is groaning under the weight if I generate source files with the data in hex or what have you. Does anyone know a way to simply link the data into my executable? It seems that most ELF systems allow this using GNU objcopy or even ld (ld -r) but apple's tools aren't playing ball. ta, pt. From spongelavapaul at mac.com Mon Jun 2 12:02:26 2008 From: spongelavapaul at mac.com (Paul Thomas) Date: Mon Jun 2 12:02:32 2008 Subject: Getting binary data linked into an executable In-Reply-To: References: <39C41E9D-072D-4E26-A7E8-5F9607F3238C@mac.com> Message-ID: <1FCBA17A-86CB-4CF2-AFCD-6AEA19E48F1D@mac.com> On 2 Jun 2008, at 19:55, SD wrote: > Would memory mapping the files work for you? It's not the particular API, I want to avoid accessing the disk at all to get the data. I want the data linked into the executable in the data segment. (it's a unit test) > > > ______________________________________________________________________ > Previous message from Paul Thomas on 6/2/08 at 7:53 PM +0100 > ********************************************************************** >> I've got some huge test data that I need to access as C arrays >> inside a command line test app. I don't want use file I/O at >> runtime and the compiler is groaning under the weight if I generate >> source files with the data in hex or what have you. >> >> Does anyone know a way to simply link the data into my executable? >> >> It seems that most ELF systems allow this using GNU objcopy or even >> ld (ld -r) but apple's tools aren't playing ball. >> >> ta, >> pt. >> _______________________________________________ >> MacOSX-dev mailing list >> MacOSX-dev@omnigroup.com >> http://www.omnigroup.com/mailman/listinfo/macosx-dev > > > -- > ========================================== > SD > > WARNING: Programming may be habit forming. From edward.patel at memention.com Mon Jun 2 12:20:52 2008 From: edward.patel at memention.com (Edward Patel) Date: Mon Jun 2 12:31:16 2008 Subject: Getting binary data linked into an executable In-Reply-To: <1FCBA17A-86CB-4CF2-AFCD-6AEA19E48F1D@mac.com> References: <39C41E9D-072D-4E26-A7E8-5F9607F3238C@mac.com> <1FCBA17A-86CB-4CF2-AFCD-6AEA19E48F1D@mac.com> Message-ID: <6B0776F6-9666-4367-A7F2-C2FCA1020266@memention.com> Checkout xxd. It's a versatile hexdump tool that can output in C language man xxd example xxd -i somefile.dat > someheader.h /Edward On 2 jun 2008, at 21.02, Paul Thomas wrote: > > On 2 Jun 2008, at 19:55, SD wrote: > >> Would memory mapping the files work for you? > > It's not the particular API, I want to avoid accessing the disk at > all to get the data. > I want the data linked into the executable in the data segment. > (it's a unit test) > >> >> >> ______________________________________________________________________ >> Previous message from Paul Thomas on 6/2/08 at 7:53 PM +0100 >> ********************************************************************** >>> I've got some huge test data that I need to access as C arrays >>> inside a command line test app. I don't want use file I/O at >>> runtime and the compiler is groaning under the weight if I >>> generate source files with the data in hex or what have you. >>> >>> Does anyone know a way to simply link the data into my executable? >>> >>> It seems that most ELF systems allow this using GNU objcopy or >>> even ld (ld -r) but apple's tools aren't playing ball. >>> >>> ta, >>> pt. >>> _______________________________________________ >>> MacOSX-dev mailing list >>> MacOSX-dev@omnigroup.com >>> http://www.omnigroup.com/mailman/listinfo/macosx-dev >> >> >> -- >> ========================================== >> SD >> >> WARNING: Programming may be habit forming. > > _______________________________________________ > MacOSX-dev mailing list > MacOSX-dev@omnigroup.com > http://www.omnigroup.com/mailman/listinfo/macosx-dev From jamie at montgomerie.net Tue Jun 3 02:17:53 2008 From: jamie at montgomerie.net (James Montgomerie) Date: Tue Jun 3 02:44:49 2008 Subject: Getting binary data linked into an executable In-Reply-To: <1FCBA17A-86CB-4CF2-AFCD-6AEA19E48F1D@mac.com> References: <39C41E9D-072D-4E26-A7E8-5F9607F3238C@mac.com> <1FCBA17A-86CB-4CF2-AFCD-6AEA19E48F1D@mac.com> Message-ID: <2944FFF1-42C2-419D-AD6D-B976B53BAD98@montgomerie.net> Perhaps I'm taking you too literally here and therefore stating the obvious, but if it's latency you're worried about, just because it's in the data section of the executable it doesn't mean that the disk will not be accessed to get it. The VM system may not page in from disk the pages containing your data until they're actually accessed by your code. Anyway, to answer the question, I have seen people using ld to put arbitrary data in the executable, I think with the '-sectcreate' flag. I believe you access the data using the APIs in , but I haven't personally used them. Jamie. On 2 Jun 2008, at 20:02, Paul Thomas wrote: > > On 2 Jun 2008, at 19:55, SD wrote: > >> Would memory mapping the files work for you? > > It's not the particular API, I want to avoid accessing the disk at > all to get the data. > I want the data linked into the executable in the data segment. > (it's a unit test) > >> >> >> ______________________________________________________________________ >> Previous message from Paul Thomas on 6/2/08 at 7:53 PM +0100 >> ********************************************************************** >>> I've got some huge test data that I need to access as C arrays >>> inside a command line test app. I don't want use file I/O at >>> runtime and the compiler is groaning under the weight if I >>> generate source files with the data in hex or what have you. >>> >>> Does anyone know a way to simply link the data into my executable? >>> >>> It seems that most ELF systems allow this using GNU objcopy or >>> even ld (ld -r) but apple's tools aren't playing ball. >>> >>> ta, >>> pt. From mikevann at gmail.com Tue Jun 3 02:56:00 2008 From: mikevann at gmail.com (Michael Vannorsdel) Date: Tue Jun 3 02:56:18 2008 Subject: Getting binary data linked into an executable In-Reply-To: <2944FFF1-42C2-419D-AD6D-B976B53BAD98@montgomerie.net> References: <39C41E9D-072D-4E26-A7E8-5F9607F3238C@mac.com> <1FCBA17A-86CB-4CF2-AFCD-6AEA19E48F1D@mac.com> <2944FFF1-42C2-419D-AD6D-B976B53BAD98@montgomerie.net> Message-ID: This is true; even though your data is in the binary image, it will still take file I/O to get it into memory either at launch or when the data is accessed. There's no way that I know that you can avoid file I/O unless you can build the data array using immediate loads and bit ops (probably via assembly) and storing each element to memory. In essence, build the data array programatically at runtime. On Jun 3, 2008, at 3:17 AM, James Montgomerie wrote: > Perhaps I'm taking you too literally here and therefore stating the > obvious, but if it's latency you're worried about, just because it's > in the data section of the executable it doesn't mean that the disk > will not be accessed to get it. The VM system may not page in from > disk the pages containing your data until they're actually accessed > by your code. From mah at jump-ing.de Tue Jun 3 04:16:53 2008 From: mah at jump-ing.de (Markus Hitter) Date: Tue Jun 3 04:17:01 2008 Subject: Getting binary data linked into an executable In-Reply-To: References: <39C41E9D-072D-4E26-A7E8-5F9607F3238C@mac.com> <1FCBA17A-86CB-4CF2-AFCD-6AEA19E48F1D@mac.com> <2944FFF1-42C2-419D-AD6D-B976B53BAD98@montgomerie.net> Message-ID: <9C1EF3E5-C1CF-4FFD-A621-B3630ED78763@jump-ing.de> Am 03.06.2008 um 11:56 schrieb Michael Vannorsdel: > There's no way that I know that you can avoid file I/O Well, you can simply access the data by reading it (e.g. compare it to zero). Reading small amounts on each memory page should be sufficient. This technique is also known as "preheating". MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From gehacktes1 at gmail.com Tue Jun 3 15:21:22 2008 From: gehacktes1 at gmail.com (Tomas) Date: Tue Jun 3 15:21:28 2008 Subject: Foundation Tool as Daemon? Message-ID: Hello, I'm really new to Obj-C/Cocoa have come from WinTel world mainly using VB. I have read the Programming in Objective-C by Stephen Kochan and Thought it was a great book to start and I have ordered Cocoa Programming for Mac OS X (3rd Edition). So with that behind me I'm trying to write a small Foundation tool that will run as a daemon that will wake up every hour and run a NSTask to collect a version number from a Unix tool and post the results via a SOAP request. I thought this sounded like a easy little beginner project since this sort of thing was easy in VB, but I'm not finding very much examples on daemons that call NSTask and I'm also not sure if I should be using NSRunLoop instead. Does anyone have an example for doing this? Thanks, tomas From macosxdevlist at personal.fishh2o.com Tue Jun 3 15:33:47 2008 From: macosxdevlist at personal.fishh2o.com (SD) Date: Tue Jun 3 15:34:24 2008 Subject: Foundation Tool as Daemon? Message-ID: Here's some code for using an NSTask, you'll have to clean it up probably: NSString *pathToTool = ...; NSTask *task = [[[NSTask alloc] init] autorelease]; [task setLaunchPath:pathToTool]; [task setArguments:[NSArray arrayWithObjects: pathToTool, @"arg1", @"arg2", nil]]; NSPipe *writePipe = [NSPipe pipe]; NSFileHandle *writeHandle = [writePipe fileHandleForWriting]; [task setStandardInput:writePipe]; NSPipe *readPipe = [NSPipe pipe]; NSFileHandle *readHandle = [readPipe fileHandleForReading]; [task setStandardOutput:readPipe]; NSPipe *readErrorPipe = [NSPipe pipe]; NSFileHandle *readErrorHandle = [readErrorPipe fileHandleForReading]; [task setStandardError:readErrorPipe]; [task launch]; //need to write user and pass then post data //size then data NSString *userAndPass = [[proxyController userName] stringByAppendingFormat:@":%@", [proxyController password]]; NSMutableData* postData = [NSMutableData data]; //username and pass int32_t size = strlen([userAndPass UTF8String])*sizeof(char); [postData appendBytes:&size length:sizeof(int32_t)]; [postData appendBytes:[userAndPass UTF8String] length:size]; //post data if(postDictionary != nil) { NSString *postDictionaryStr = [postDictionary formatForHTTPUsingEncoding:NSUTF8StringEncoding]; size = strlen([postDictionaryStr UTF8String])*sizeof(char); [postData appendBytes:&size length:sizeof(int32_t)]; [postData appendBytes:[postDictionaryStr UTF8String] length:size]; } [writeHandle writeData:postData]; [task waitUntilExit]; NSData* URLdata = [readHandle readDataToEndOfFile]; NSData* errorData = [readErrorHandle readDataToEndOfFile]; IFDEBUG( NSLog(@"URLdata = '%@'", URLdata); NSLog(@"errorData = '%@'", errorData); ) if(debugInfo != nil) [debugInfo appendFormat:@"\t URLdata = '%@'\n", URLdata]; if(debugInfo != nil) [debugInfo appendFormat:@"\t errorData = '%@'\n", errorData]; if(debugInfo != nil) [debugInfo appendFormat:@"\t URLHandle status = N/A\n"]; if(debugInfo != nil) [debugInfo appendFormat:@"\t httpCode N/A\n"]; NSString *returnStr = [[[NSString alloc] initWithData:([errorData length] == 0 ? URLdata : errorData) encoding:NSUTF8StringEncoding] autorelease]; if(debugInfo != nil) [debugInfo appendFormat:@"\t returnStr = '%@'\n", returnStr]; IFDEBUG(NSLog(@"returnStr = '%@'", returnStr);) return returnStr; SD -- ========================================== SD WARNING: Programming may be habit forming. From macosxdevlist at personal.fishh2o.com Tue Jun 3 15:33:51 2008 From: macosxdevlist at personal.fishh2o.com (SD) Date: Tue Jun 3 15:34:39 2008 Subject: Foundation Tool as Daemon? In-Reply-To: References: Message-ID: For running your tool on the hour you should read: http://developer.apple.com/macosx/launchd.html SD ______________________________________________________________________ Previous message on 6/3/08 at 3:21 PM -0700 ********************************************************************** >Hello, >I'm really new to Obj-C/Cocoa have come from WinTel world mainly using >VB. I have read the Programming in Objective-C by Stephen Kochan and >Thought it was a great book to start and I have ordered Cocoa >Programming for Mac OS X (3rd Edition). > >So with that behind me I'm trying to write a small Foundation tool >that will run as a daemon that will wake up every hour and run a >NSTask to collect a version number from a Unix tool and post the >results via a SOAP request. I thought this sounded like a easy little >beginner project since this sort of thing was easy in VB, but I'm not >finding very much examples on daemons that call NSTask and I'm also >not sure if I should be using NSRunLoop instead. > >Does anyone have an example for doing this? > >Thanks, >tomas >_______________________________________________ >MacOSX-dev mailing list >MacOSX-dev@omnigroup.com >http://www.omnigroup.com/mailman/listinfo/macosx-dev -- ========================================== SD WARNING: Programming may be habit forming. From macosxdevlist at personal.fishh2o.com Tue Jun 3 15:35:27 2008 From: macosxdevlist at personal.fishh2o.com (SD) Date: Tue Jun 3 15:35:35 2008 Subject: Foundation Tool as Daemon? Message-ID: Also check out the application Lingon for building the launchd files (version 1.x was better than 2.x); --------------- For running your tool on the hour you should read: http://developer.apple.com/macosx/launchd.html SD ______________________________________________________________________ Previous message on 6/3/08 at 3:21 PM -0700 ********************************************************************** >Hello, >I'm really new to Obj-C/Cocoa have come from WinTel world mainly using >VB. I have read the Programming in Objective-C by Stephen Kochan and >Thought it was a great book to start and I have ordered Cocoa >Programming for Mac OS X (3rd Edition). > >So with that behind me I'm trying to write a small Foundation tool >that will run as a daemon that will wake up every hour and run a >NSTask to collect a version number from a Unix tool and post the >results via a SOAP request. I thought this sounded like a easy little >beginner project since this sort of thing was easy in VB, but I'm not >finding very much examples on daemons that call NSTask and I'm also >not sure if I should be using NSRunLoop instead. > >Does anyone have an example for doing this? > >Thanks, >tomas >_______________________________________________ >MacOSX-dev mailing list >MacOSX-dev@omnigroup.com >http://www.omnigroup.com/mailman/listinfo/macosx-dev -- ========================================== SD WARNING: Programming may be habit forming. From mikevann at gmail.com Wed Jun 4 03:24:56 2008 From: mikevann at gmail.com (Michael Vannorsdel) Date: Wed Jun 4 03:25:03 2008 Subject: how to run my app in privileged mode In-Reply-To: <7626EC53-0C90-479F-AB2C-404EF9BDB4D6@charlessoft.com> References: <1D0AAA93-33CF-4A6E-B1BC-C5EEC6705C61@mac.com> <543A1E10-9058-42E9-A9A2-EF7B1146DE04@gmail.com> <7626EC53-0C90-479F-AB2C-404EF9BDB4D6@charlessoft.com> Message-ID: <3F7B67B1-B1B1-4E25-B745-C20AE7523692@gmail.com> There's programmer mistakes to be made for any kind of privileged program, AppKit or not. Foundation has NSTask which allows you to run shell scripts, scripts that can be modified to do other unintended and damaging things. But I don't see this as a reason Foundation tools should never be used as a privileged process. Any privileged process can be labeled as "evil" given theoretical possibilities. In the end privileged AppKit processes are fully supported on Mac OS X and it's ultimately up to the programmer to ensure every effort has been made to protect against abuse. AppKit does add some different gotchas but I wouldn't go as far to say it will always be "evil". To the OP: the AppleScript issues should be taken seriously of course. But until he says otherwise I don't want to assume he's incapable of properly handling a privileged application. On Jun 3, 2008, at 7:16 PM, Charles Srstka wrote: > Just to explain a bit *why* this is evil and why you absolutely > should not do this, here's a little demonstration which you can try > on your own machine if you like: > > my-machine:~ me$ sudo -s > Password: > bash-3.2# /Applications/TextEdit.app/Contents/MacOS/TextEdit & > [1] 51668 > bash-3.2# exit > exit > my-machine:~ me$ mkdir testfolder > my-machine:~ me$ touch testfolder/testfile > my-machine:~ me$ sudo chown root:wheel testfolder > my-machine:~ me$ sudo chmod 700 testfolder > my-machine:~ me$ ls -l testfolder > ls: testfolder: Permission denied > my-machine:~ me$ osascript -e 'tell application "TextEdit" to do > shell script "ls -l ~/testfolder"' > -rw-r--r-- 1 me me 0 Jun 3 20:09 testfile > > As you can see from the above example, if a Cocoa app is running as > root, AppleScript combined with "do shell script" can be used by any > unprivileged user to run commands as root. Effectively this means > that if even a single Cocoa app is running as root, you've > effectively given root access to every other binary on the entire > system. Needless to say, that's a bad thing. > > Personally, I consider this a large security flaw in OS X, since > it's easily possible for a developer to do what the OP here is > thinking of doing, and the user could run this without necessarily > realizing what is going on, and it would open the door for any virus > or trojan to become root and take over the whole system. However, > every time I report this, it gets flagged as "Behaves Correctly" > because GUI apps aren't supposed to run as root anyway. Well yes, > they're not. But what if they *do* somehow? :-/ From rbarris at blizzard.com Thu Jun 5 18:14:04 2008 From: rbarris at blizzard.com (Rob Barris) Date: Thu Jun 5 18:14:43 2008 Subject: [job spam] Blizzard Mac Team = Hiring Message-ID: <320C89B2-B98D-46C3-9BE9-34B7BF8731CB@blizzard.com> (Reposting on new list to reach some more folks) If you think you can help us bring StarCraft II, more WoW follow-ons, and other fun Blizzard games to the Mac, please apply! If you have questions please reply to me directly and avoid list clutter - rbarris "at" blizzard.com. http://www.blizzard.com/us/jobopp/mac-senior-software-engineer.html > Blizzard Entertainment's Mac team is looking for an accomplished, > skilled developer to participate in the porting and optimization of > games for the Apple OS X platform. This position will encompass work > across multiple titles, including World of Warcraft, StarCraft II, > and future titles. > > Blizzard Entertainment offers a fun, creative, and technically > challenging environment with excellent compensation and a full range > of benefits. > > Responsibilities > > > ? Port, debug, tune, and maintain multiple Blizzard Entertainment > titles on Mac OS X. > ? Develop technical solutions for challenges faced in porting, > including custom tools. > ? Work directly with our Windows development teams to track and > respond to technical needs. > Requirements > > ? Bachelor's degree in computer science > ? Knowledge of C/C++, debugging, and code optimization > ? Detailed understanding of Mac OS X APIs and infrastructure > ? Strong passion for Blizzard Entertainment franchises > ? Passion for creating great Mac software > ? Good spoken and written communication skills > Plusses > > > ? Experience shipping commercial or shareware game titles > ? Experience porting and optimizing Win32 game software for Mac OS X > ? Experience using Xcode and GCC on Mac OS X > ? Experience in Perl or Lua > ? Knowledge of OpenGL or Direct3D graphics APIs > ? Project management skills > No follow-up calls or e-mails, please. This is a full-time position > in Irvine, CA; internships and part-time positions are not available > at this time. > > To apply, please send a cover letter, resume, salary history/ > requirements in separate Word or RTF format documents and code > samples in text files to: resumes@blizzard.com > From ahoesch at smartsoft.de Fri Jun 6 07:26:29 2008 From: ahoesch at smartsoft.de (=?ISO-8859-1?Q?Andreas_H=F6schler?=) Date: Fri Jun 6 07:26:41 2008 Subject: Leopard weirdness Message-ID: <8DF96B2C-33D4-11DD-9C62-000393CA0072@smartsoft.de> Hi all, we are in the process of migrating our software from MacOSX 10.2 and GNUstep to MacOSX 10.5 and figured out a bunch of weird issues [modifications to AppKit we dislike to say the least, or that we don't understand yet] that prevent our apps from working properly. Our apps build NSTableViews programmatically (based on a property list) and sets the columns to editable or not using [tableColumn setEditable:flag]. All our tableviews also get [tableView setDoubleAction:@selector(performDoubleActions)]; [tableView setTarget:self]; The behaviour we expect and are used to since the old OPENSTEP days (the same on MacOSX 10.2 and GNUstep) is that a doubleclick in an editable column starts editing the cell, a doubleclick on a non-editable column invokes the doubleaction of the tableview. On MacoSX 10.5 the action is always invoked, no cell is editable anymore whether setEditable:YES was invoked or not. :-( Is this supposed to be a feature? If so I don't understand the reasoning. Or am I missing anything. We commented out the line that sets the action for now. Now the columns that got a setEditable:YES are editable. However, one has to do a direct hit on the text to start editing. If one doubleclicks slightly to the right of the text (but still within the cell) editing is not started anymore. This is pretty annoying!! :-( Please tell me that I am doing things wrong and that these incompatibilities can be overcome with a few #ifdefs! I can't believe what I see... Thanks, Andreas From cmhofman at gmail.com Fri Jun 6 07:51:44 2008 From: cmhofman at gmail.com (Christiaan Hofman) Date: Fri Jun 6 07:51:51 2008 Subject: Leopard weirdness In-Reply-To: <8DF96B2C-33D4-11DD-9C62-000393CA0072@smartsoft.de> References: <8DF96B2C-33D4-11DD-9C62-000393CA0072@smartsoft.de> Message-ID: On 6 Jun 2008, at 4:26 PM, Andreas H?schler wrote: > Hi all, > > we are in the process of migrating our software from MacOSX 10.2 and > GNUstep to MacOSX 10.5 and figured out a bunch of weird issues > [modifications to AppKit we dislike to say the least, or that we > don't understand yet] that prevent our apps from working properly. > > Our apps build NSTableViews programmatically (based on a property > list) and sets the columns to editable or not using [tableColumn > setEditable:flag]. All our tableviews also get > > [tableView setDoubleAction:@selector(performDoubleActions)]; > [tableView setTarget:self]; > > The behaviour we expect and are used to since the old OPENSTEP days > (the same on MacOSX 10.2 and GNUstep) is that a doubleclick in an > editable column starts editing the cell, a doubleclick on a non- > editable column invokes the doubleaction of the tableview. On MacoSX > 10.5 the action is always invoked, no cell is editable anymore > whether setEditable:YES was invoked or not. :-( That's probably not correct. Initiating an edit has changed on 10.5 though. You have to single click the cell in the selected row to edit, rather than double click. This means you first have to select the row, then wait at least the double-click time, and then click again. So it works like changing a file name in Finder. I personally also feel this is annoying, but it's something we'll have to get used to, as it's now the reality. On the other hand, this allows you to have both an editable cell and a double click action for the same cell. > Is this supposed to be a feature? If so I don't understand the > reasoning. Or am I missing anything. Yes for both questions. > > We commented out the line that sets the action for now. Now the > columns that got a setEditable:YES are editable. However, one has to > do a direct hit on the text to start editing. If one doubleclicks > slightly to the right of the text (but still within the cell) > editing is not started anymore. This is pretty annoying!! :-( > I also think that the need to click on the text is annoying behavior. I'm not sure if it's a bug though, but I truly fail to see any reason for this (AOT single-click editing I described above). Especially for still empty cells it makes it really hard to edit. I do believe this is cause for a bug report (or at least an enhancement request). > Please tell me that I am doing things wrong and that these > incompatibilities can be overcome with a few #ifdefs! I can't > believe what I see... > > Thanks, > > Andreas So it's not an incompatibility you're seeing. Everything you could do in the past you can still do now. And in fact you can do more. It just works differently. You can't simply revert back to the old editing behavior, it would require you to override several methods in NSTableView, like mouseDown:. It's very tricky to do that correctly. Moreover, this is now the standard behavior, so better be consistent. So I advice you to get used to it. Christiaan From ahoesch at smartsoft.de Fri Jun 6 09:05:49 2008 From: ahoesch at smartsoft.de (=?ISO-8859-1?Q?Andreas_H=F6schler?=) Date: Fri Jun 6 09:05:59 2008 Subject: Leopard weirdness In-Reply-To: Message-ID: <6E360243-33E2-11DD-9C62-000393CA0072@smartsoft.de> Hi Christiaan, >> we are in the process of migrating our software from MacOSX 10.2 and >> GNUstep to MacOSX 10.5 and figured out a bunch of weird issues >> [modifications to AppKit we dislike to say the least, or that we >> don't understand yet] that prevent our apps from working properly. >> >> Our apps build NSTableViews programmatically (based on a property >> list) and sets the columns to editable or not using [tableColumn >> setEditable:flag]. All our tableviews also get >> >> [tableView setDoubleAction:@selector(performDoubleActions)]; >> [tableView setTarget:self]; >> >> The behaviour we expect and are used to since the old OPENSTEP days >> (the same on MacOSX 10.2 and GNUstep) is that a doubleclick in an >> editable column starts editing the cell, a doubleclick on a >> non-editable column invokes the doubleaction of the tableview. On >> MacoSX 10.5 the action is always invoked, no cell is editable anymore >> whether setEditable:YES was invoked or not. :-( > > That's probably not correct. Initiating an edit has changed on 10.5 > though. You have to single click the cell in the selected row to edit, > rather than double click. This means you first have to select the row, > then wait at least the double-click time, and then click again. I checked that and can confirm this behaviour. However, editing the cell is started only whit a short-single-click on the cell. Editing is not started when it takes me more than half a second to release the mouse button again!? > So it works like changing a file name in Finder. > > I personally also feel this is annoying, but it's something we'll have > to get used to, as it's now the reality. > > On the other hand, this allows you to have both an editable cell and a > double click action for the same cell. I see the ratio. Thanks for the explanation. I would prefer to be able to modify this (switch back to old) behaviour in System Preferences though. :-( The new approach has the above mentioned advantage but is simply less efficient. :-( >> Is this supposed to be a feature? If so I don't understand the >> reasoning. Or am I missing anything. > > Yes for both questions. > >> >> We commented out the line that sets the action for now. Now the >> columns that got a setEditable:YES are editable. However, one has to >> do a direct hit on the text to start editing. If one doubleclicks >> slightly to the right of the text (but still within the cell) editing >> is not started anymore. This is pretty annoying!! :-( >> > > I also think that the need to click on the text is annoying behavior. > I'm not sure if it's a bug though, but I truly fail to see any reason > for this (AOT single-click editing I described above). Especially for > still empty cells it makes it really hard to edit. I do believe this > is cause for a bug report (or at least an enhancement request). For empty cells I see the old behaviour. You can click anywhere within the cell and editing gets started! When I remove the doubleaction from the tableview I get the old behaviour back (doubleclick on a cell starts editing). I slowly get the idea ... >> Please tell me that I am doing things wrong and that these >> incompatibilities can be overcome with a few #ifdefs! I can't believe >> what I see... > > So it's not an incompatibility you're seeing. Everything you could do > in the past you can still do now. And in fact you can do more. It just > works differently. Yes, in the past one could not have a doubleaction on a tableview with all cells being editable (at least on cell had to be non-editable and the user had to doubleclick on that to invoke the doubleaction). The new approach allows to have a doubleclickable tableview with all cells being editable. > You can't simply revert back to the old editing behavior, it would > require you to override several methods in NSTableView, like > mouseDown:. It's very tricky to do that correctly. Moreover, this is > now the standard behavior, so better be consistent. So I advice you to > get used to it. It's actually an incompatibility issue for us since some users are working on Macs, others (most) are working on Sun Rays (GNUstep/Solaris). But that's our problem and Apple couldn't care less. :-) It might make sense for GNUstep to adopt the new behaviour. Anyway, thanks for the helpful discussion. My faith in Apple just returned. :-) Regards, Andreas From cmhofman at gmail.com Fri Jun 6 10:18:40 2008 From: cmhofman at gmail.com (Christiaan Hofman) Date: Fri Jun 6 10:18:50 2008 Subject: Leopard weirdness In-Reply-To: <6E360243-33E2-11DD-9C62-000393CA0072@smartsoft.de> References: <6E360243-33E2-11DD-9C62-000393CA0072@smartsoft.de> Message-ID: <841EA088-20E8-4E6D-9A75-68B30C0DFA9F@gmail.com> On 6 Jun 2008, at 6:05 PM, Andreas H?schler wrote: > Hi Christiaan, > >>> we are in the process of migrating our software from MacOSX 10.2 >>> and GNUstep to MacOSX 10.5 and figured out a bunch of weird issues >>> [modifications to AppKit we dislike to say the least, or that we >>> don't understand yet] that prevent our apps from working properly. >>> >>> Our apps build NSTableViews programmatically (based on a property >>> list) and sets the columns to editable or not using [tableColumn >>> setEditable:flag]. All our tableviews also get >>> >>> [tableView setDoubleAction:@selector(performDoubleActions)]; >>> [tableView setTarget:self]; >>> >>> The behaviour we expect and are used to since the old OPENSTEP >>> days (the same on MacOSX 10.2 and GNUstep) is that a doubleclick >>> in an editable column starts editing the cell, a doubleclick on a >>> non-editable column invokes the doubleaction of the tableview. On >>> MacoSX 10.5 the action is always invoked, no cell is editable >>> anymore whether setEditable:YES was invoked or not. :-( >> >> That's probably not correct. Initiating an edit has changed on 10.5 >> though. You have to single click the cell in the selected row to >> edit, rather than double click. This means you first have to select >> the row, then wait at least the double-click time, and then click >> again. > > I checked that and can confirm this behaviour. However, editing the > cell is started only whit a short-single-click on the cell. Editing > is not started when it takes me more than half a second to release > the mouse button again!? > I see that also. I don't think it's a serious problem, as you typically would click fast anyway. Probably it has to do with the time it checks for a double-click. >> So it works like changing a file name in Finder. >> >> I personally also feel this is annoying, but it's something we'll >> have to get used to, as it's now the reality. >> >> On the other hand, this allows you to have both an editable cell >> and a double click action for the same cell. > > I see the ratio. Thanks for the explanation. I would prefer to be > able to modify this (switch back to old) behaviour in System > Preferences though. :-( > > The new approach has the above mentioned advantage but is simply > less efficient. :-( > >>> Is this supposed to be a feature? If so I don't understand the >>> reasoning. Or am I missing anything. >> >> Yes for both questions. >> >>> >>> We commented out the line that sets the action for now. Now the >>> columns that got a setEditable:YES are editable. However, one has >>> to do a direct hit on the text to start editing. If one >>> doubleclicks slightly to the right of the text (but still within >>> the cell) editing is not started anymore. This is pretty >>> annoying!! :-( >>> >> >> I also think that the need to click on the text is annoying >> behavior. I'm not sure if it's a bug though, but I truly fail to >> see any reason for this (AOT single-click editing I described >> above). Especially for still empty cells it makes it really hard to >> edit. I do believe this is cause for a bug report (or at least an >> enhancement request). > > For empty cells I see the old behaviour. You can click anywhere > within the cell and editing gets started! > I seem to remember seeing tables where empty cells have a very small area to start editing. Though that may have been custom cells. But this sounds a bit inconsistent. > When I remove the doubleaction from the tableview I get the old > behaviour back (doubleclick on a cell starts editing). I slowly get > the idea ... > >>> Please tell me that I am doing things wrong and that these >>> incompatibilities can be overcome with a few #ifdefs! I can't >>> believe what I see... >> >> So it's not an incompatibility you're seeing. Everything you could >> do in the past you can still do now. And in fact you can do more. >> It just works differently. > > Yes, in the past one could not have a doubleaction on a tableview > with all cells being editable (at least on cell had to be non- > editable and the user had to doubleclick on that to invoke the > doubleaction). The new approach allows to have a doubleclickable > tableview with all cells being editable. > Another change in behavior is tabbing. Previously tabbing would go through a column and would be circular. Now it will go through a row, and leave the table after the last column. I'm personally not sure if going through a row was a good choice (I would have liked to have a setting for that, as now I have to override it in some tableviews). But being able to leave the table using tab is an improvement IMO. >> You can't simply revert back to the old editing behavior, it would >> require you to override several methods in NSTableView, like >> mouseDown:. It's very tricky to do that correctly. Moreover, this >> is now the standard behavior, so better be consistent. So I advice >> you to get used to it. > > It's actually an incompatibility issue for us since some users are > working on Macs, others (most) are working on Sun Rays (GNUstep/ > Solaris). But that's our problem and Apple couldn't care less. :-) > That's not an incompatibility. When you implement it correctly, it will just work on both systems. It will just work differently on the different systems. On Leopard it will behave as I described, while on Tiger or GNUstep/Solaris it will behave as before. Without the need to have separate code paths or special overrides. Christiaan > It might make sense for GNUstep to adopt the new behaviour. Anyway, > thanks for the helpful discussion. My faith in Apple just > returned. :-) > > Regards, > > Andreas > From ahoesch at smartsoft.de Fri Jun 6 11:41:34 2008 From: ahoesch at smartsoft.de (=?ISO-8859-1?Q?Andreas_H=F6schler?=) Date: Fri Jun 6 11:42:18 2008 Subject: Leopard weirdness In-Reply-To: <841EA088-20E8-4E6D-9A75-68B30C0DFA9F@gmail.com> Message-ID: <302833B2-33F8-11DD-B3A7-000393CA0072@smartsoft.de> Hi Christiaan > Another change in behavior is tabbing. Previously tabbing would go > through a column and would be circular. Now it will go through a row, > and leave the table after the last column. I'm personally not sure if > going through a row was a good choice (I would have liked to have a > setting for that, as now I have to override it in some tableviews). > But being able to leave the table using tab is an improvement IMO. The current (old) behaviour is that after editing the last column cell, pressing tab will bring you into the first cell/column of the next row. That's how it's supposed to be. I just realized that they have changed the behaviour to what your describe above. This is a very bad modification IMHO!!! :-( Filling in a bunch of cells in a tableview is now close to impossible (terribly inefficient). One has to use the mouse to get into the tableview (again) after each row. And since a doubleclick no longer works one first has to select the next row manually, wait a second and then select the cell to be edited with another single-click. It could hardly be worse! Who has come up with that?? :-( > >>> You can't simply revert back to the old editing behavior, it would >>> require you to override several methods in NSTableView, like >>> mouseDown:. It's very tricky to do that correctly. Moreover, this is >>> now the standard behavior, so better be consistent. So I advice you >>> to get used to it. >> >> It's actually an incompatibility issue for us since some users are >> working on Macs, others (most) are working on Sun Rays >> (GNUstep/Solaris). But that's our problem and Apple couldn't care >> less. :-) >> > > That's not an incompatibility. When you implement it correctly, it > will just work on both systems. It will just work differently on the > different systems. That's the problem. If user switch between Mac and Sun Ray desktops they will get confused. But we can live with that. What concerns me more is this new tabbing behaviour. :-( Can that at least be modified with a default (old behaviour)? > On Leopard it will behave as I described, while on Tiger or > GNUstep/Solaris it will behave as before. Without the need to have > separate code paths or special overrides Regards, Andreas From cmhofman at gmail.com Sat Jun 7 05:22:15 2008 From: cmhofman at gmail.com (Christiaan Hofman) Date: Sat Jun 7 05:22:24 2008 Subject: Frameworks, categories and shared namespace Message-ID: <7DDA17A8-90AD-4855-AD6B-AE6E1862BA17@gmail.com> I have a general question about proper implementation of frameworks, in particular for categories on standard Cocoa objects. As we all know, Obj-C has the general limitation that it does not support name spaces. So defining categories internal to a framework is potentially dangerous, as method names in the categories can be the same as method names defined in the main application, or perhaps in another framework loaded by the app. This is particularly likely for convenience method with obvious and intuitive names. Note that I'm talking about drop-in frameworks, that have a limited interface with the main app (AOT general toolbox frameworks such as the Omi frameworks). Think of updater frameworks, crashreporter frameworks, and the likes. The point is that the extensions are supposed to be for internal usage of the framework, not for use by the main app. So now to the main question. What is the proper way to avoid conflicts in these situations? It seems to me that the obvious way to define a (convenience) category in the usual way is actually wrong in this situation. Some solutions I can think of is to define method names starting with a unique prefix. It's a bit annoying though. Another possibility is to use utility functions (with names starting with a unique prefix) rather than methods in a category. that's also a bit annoying, as you abandon the OOP. So what is the proper way to work around this Obj-C limitation? Christiaan From amaxwell at mac.com Sat Jun 7 08:25:26 2008 From: amaxwell at mac.com (Adam R. Maxwell) Date: Sat Jun 7 08:26:14 2008 Subject: Frameworks, categories and shared namespace In-Reply-To: <7DDA17A8-90AD-4855-AD6B-AE6E1862BA17@gmail.com> References: <7DDA17A8-90AD-4855-AD6B-AE6E1862BA17@gmail.com> Message-ID: <252EB9AB-213A-48DB-A4AD-82B77611DEAA@mac.com> On Jun 7, 2008, at 5:22 AM, Christiaan Hofman wrote: > So now to the main question. What is the proper way to avoid > conflicts in these situations? It seems to me that the obvious way > to define a (convenience) category in the usual way is actually > wrong in this situation. Some solutions I can think of is to define > method names starting with a unique prefix. It's a bit annoying > though. Another possibility is to use utility functions (with names > starting with a unique prefix) rather than methods in a category. > that's also a bit annoying, as you abandon the OOP. So what is the > proper way to work around this Obj-C limitation? I use something like xx_ prepended to method names in that case, but I borrowed the idea from Apple. Some of the runtime exploring tools show that there's an ABCompare protocol on NSObject, and that uses _abCompare as a prefix. NSURL has a bunch of category additions with _web_ and _webkit_ prefixes. If you're adding a lot of methods to an Apple-supplied class, I think it's preferable to use a subclass, framework or not (but that doesn't work with some objects, e.g. singletons). -- Adam From blair at millhr.com Sat Jun 7 11:39:14 2008 From: blair at millhr.com (Blair Mandell) Date: Sat Jun 7 12:39:20 2008 Subject: Cocoa Developer Job (full time / contract) Message-ID: <51D61989-5CD6-47BA-9412-66458CB2A5F6@millhr.com> macosx, doubleTwist is a venture funded startup in San Francisco founded by DVD Jon and Monique Farantzos. We help people move media between their computer, devices and friends. Want to send a video shot on your cell phone to a Facebook friend or sync your iTunes library to your PSP? doubleTwist takes care of protocols and format conversions so that you can enjoy your media without technical headaches. We are looking for Cocoa-addicted developers (one full-time in SF and one contractor) to work on the Swiss army knife for media. Contact: blair@millhr.com Please send a resume and a time we can call you. From Gerben.Wierda at rna.nl Sun Jun 8 00:03:50 2008 From: Gerben.Wierda at rna.nl (Gerben Wierda) Date: Sun Jun 8 00:19:11 2008 Subject: Unix tool. Compiling on Leopard, deploying on Tiger, using Python Message-ID: <7096D8D3-6B36-4C29-A1B3-36DB24F242E8@rna.nl> OK, here is my problem. I want to create a binary (compiled from open source on Leopard) that works on both Tiger and Leopard, so backward compatible. Most of the time, this is no problem, but now it is. I compile and link the binary by giving this to configure: CFLAGS="-mmacosx-version-min=10.4" LDFLAGS="-mmacosx-version-min=10.4" which normally is all I have to do. But now I have a binary that uses Python. And though python is available in /usr/lib as symlink $ ls -l /usr/lib/*pyth* lrwxr-xr-x 1 root wheel 16 Dec 31 13:21 /usr/lib/libpython.dylib -> libpython2.dylib lrwxr-xr-x 1 root wheel 16 Dec 31 13:21 /usr/lib/libpython2.5.dylib -> libpython2.dylib lrwxr-xr-x 1 root wheel 68 Dec 31 13:21 /usr/lib/libpython2.dylib - > ../../System/Library/Frameworks/Python.framework/Versions/2.5/Python lrwxr-xr-x 1 root wheel 75 Dec 31 13:31 /usr/lib/python2.5 -> ../../ System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5 the resulting binary is linked hard against the python 2.5 library. Basically, at this stage I do not care if it is compiled and linked against 2.5 and when run on Tiger it is running against 2.3 (which may give problems). The resulting library is linked against /System/Library/Frameworks/Python.framework/Versions/2.5/Python (compatibility version 2.5.0, current version 2.5.1) which is not avaiable on Tiger and not against /usr/lib/libpython2.dylib which is. Is there a way to tell the binary to link against /usr/lib/ libpython2.dylib and not have it turn that into the actual 2.5 lib in / System? Thanks, G From cmhofman at gmail.com Sun Jun 8 03:37:07 2008 From: cmhofman at gmail.com (Christiaan Hofman) Date: Sun Jun 8 03:37:18 2008 Subject: Unix tool. Compiling on Leopard, deploying on Tiger, using Python In-Reply-To: <7096D8D3-6B36-4C29-A1B3-36DB24F242E8@rna.nl> References: <7096D8D3-6B36-4C29-A1B3-36DB24F242E8@rna.nl> Message-ID: <41D1947B-0E79-4744-B2E5-CA6106E47291@gmail.com> Have you tried adding an -dylib_file option to OTHER_LD_FLAGS? Christiaan On 8 Jun 2008, at 9:03 AM, Gerben Wierda wrote: > OK, here is my problem. I want to create a binary (compiled from > open source on Leopard) that works on both Tiger and Leopard, so > backward compatible. Most of the time, this is no problem, but now > it is. I compile and link the binary by giving this to configure: > > CFLAGS="-mmacosx-version-min=10.4" > LDFLAGS="-mmacosx-version-min=10.4" > > which normally is all I have to do. But now I have a binary that > uses Python. And though python is available in /usr/lib as symlink > > $ ls -l /usr/lib/*pyth* > lrwxr-xr-x 1 root wheel 16 Dec 31 13:21 /usr/lib/libpython.dylib - > > libpython2.dylib > lrwxr-xr-x 1 root wheel 16 Dec 31 13:21 /usr/lib/ > libpython2.5.dylib -> libpython2.dylib > lrwxr-xr-x 1 root wheel 68 Dec 31 13:21 /usr/lib/libpython2.dylib > -> ../../System/Library/Frameworks/Python.framework/Versions/2.5/ > Python > lrwxr-xr-x 1 root wheel 75 Dec 31 13:31 /usr/lib/python2.5 - > > ../../System/Library/Frameworks/Python.framework/Versions/2.5/lib/ > python2.5 > > the resulting binary is linked hard against the python 2.5 library. > Basically, at this stage I do not care if it is compiled and linked > against 2.5 and when run on Tiger it is running against 2.3 (which > may give problems). > > The resulting library is linked against > > /System/Library/Frameworks/Python.framework/Versions/2.5/Python > (compatibility version 2.5.0, current version 2.5.1) > > which is not avaiable on Tiger and not against > > /usr/lib/libpython2.dylib > > which is. > > Is there a way to tell the binary to link against /usr/lib/ > libpython2.dylib and not have it turn that into the actual 2.5 lib > in /System? > > Thanks, > > G > _______________________________________________ > MacOSX-dev mailing list > MacOSX-dev@omnigroup.com > http://www.omnigroup.com/mailman/listinfo/macosx-dev From kusterer at gmail.com Sun Jun 8 07:50:07 2008 From: kusterer at gmail.com (Uli Kusterer) Date: Sun Jun 8 07:50:14 2008 Subject: Frameworks, categories and shared namespace In-Reply-To: <252EB9AB-213A-48DB-A4AD-82B77611DEAA@mac.com> References: <7DDA17A8-90AD-4855-AD6B-AE6E1862BA17@gmail.com> <252EB9AB-213A-48DB-A4AD-82B77611DEAA@mac.com> Message-ID: Am 07.06.2008 um 08:25 schrieb Adam R. Maxwell: > If you're adding a lot of methods to an Apple-supplied class, I > think it's preferable to use a subclass, framework or not (but that > doesn't work with some objects, e.g. singletons). It also doesn't help when you're not the one creating the object, e.g. you get it from a system library. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de From cmhofman at gmail.com Sun Jun 8 07:54:47 2008 From: cmhofman at gmail.com (Christiaan Hofman) Date: Sun Jun 8 07:54:56 2008 Subject: Frameworks, categories and shared namespace In-Reply-To: References: <7DDA17A8-90AD-4855-AD6B-AE6E1862BA17@gmail.com> <252EB9AB-213A-48DB-A4AD-82B77611DEAA@mac.com> Message-ID: On 8 Jun 2008, at 4:50 PM, Uli Kusterer wrote: > Am 07.06.2008 um 08:25 schrieb Adam R. Maxwell: >> If you're adding a lot of methods to an Apple-supplied class, I >> think it's preferable to use a subclass, framework or not (but that >> doesn't work with some objects, e.g. singletons). > > > It also doesn't help when you're not the one creating the object, > e.g. you get it from a system library. > > Cheers, > -- Uli Kusterer > "The Witnesses of TeachText are everywhere..." > http://www.zathras.de That's basically the situation I'm asking about. When the class is defined in the framework I don't really care. Christiaan From amaxwell at mac.com Sun Jun 8 17:35:01 2008 From: amaxwell at mac.com (Adam R. Maxwell) Date: Sun Jun 8 17:35:15 2008 Subject: Frameworks, categories and shared namespace In-Reply-To: References: <7DDA17A8-90AD-4855-AD6B-AE6E1862BA17@gmail.com> <252EB9AB-213A-48DB-A4AD-82B77611DEAA@mac.com> Message-ID: <8C4EA2CA-5CD9-448E-BB48-B3BB54F4DD8F@mac.com> On Jun 8, 2008, at 7:54 AM, Christiaan Hofman wrote: > On 8 Jun 2008, at 4:50 PM, Uli Kusterer wrote: > >> Am 07.06.2008 um 08:25 schrieb Adam R. Maxwell: >>> If you're adding a lot of methods to an Apple-supplied class, I >>> think it's preferable to use a subclass, framework or not (but >>> that doesn't work with some objects, e.g. singletons). >> >> >> It also doesn't help when you're not the one creating the object, >> e.g. you get it from a system library. >> >> Cheers, >> -- Uli Kusterer >> "The Witnesses of TeachText are everywhere..." >> http://www.zathras.de > > That's basically the situation I'm asking about. When the class is > defined in the framework I don't really care. Not sure what Christiaan's thinking of in particular, but here's a concrete example based on my interpretation of his question. Sparkle 1.5b1 (popular application updating framework) includes various categories, including one on NSBundle: - (NSString *)name; - (NSString *)version; - (NSString *)displayVersion; - (NSImage *)icon; - (BOOL)isRunningFromDiskImage; - (NSArray *)systemProfile; - (NSString *)publicDSAKey; Any of these could be added by Apple in some future version of OS X, and Sparkle's implementation will most likely override Foundation's implementation. Worse, some of these may exist now as private methods with different semantics. If I write a category like this and compile it into my app, it's my own fault if it breaks; if you're writing a framework that other people will use, they may not even realize that all of these categories exist. Suppose that in a future release of OS X, Apple implements -[NSBundle systemProfile] to return an XML string; what are the implications for all the clients of the Sparkle framework? Worse, if Apple implements it in a category on NSBundle, it's not even clear whose implementation will win out. So if I understand correctly, Christiaan is asking what the best practice is in this case for framework developers. (And I'm not singling out Sparkle...it's just a convenient example that was brought to mind recently). -- adam From hamish at gmail.com Mon Jun 9 15:57:18 2008 From: hamish at gmail.com (Hamish Allan) Date: Mon Jun 9 15:57:21 2008 Subject: Frameworks, categories and shared namespace In-Reply-To: <8C4EA2CA-5CD9-448E-BB48-B3BB54F4DD8F@mac.com> References: <7DDA17A8-90AD-4855-AD6B-AE6E1862BA17@gmail.com> <252EB9AB-213A-48DB-A4AD-82B77611DEAA@mac.com> <8C4EA2CA-5CD9-448E-BB48-B3BB54F4DD8F@mac.com> Message-ID: <597e7edb0806091557k214b5850u60f21462b3cd2d94@mail.gmail.com> On Mon, Jun 9, 2008 at 1:35 AM, Adam R. Maxwell wrote: > So if I understand correctly, Christiaan is asking what the best practice is > in this case for framework developers. My answer to this question would be: "file a bug requesting namespaces". Hamish From bbum at mac.com Mon Jun 9 16:02:08 2008 From: bbum at mac.com (Bill Bumgarner) Date: Mon Jun 9 16:02:14 2008 Subject: Frameworks, categories and shared namespace In-Reply-To: <597e7edb0806091557k214b5850u60f21462b3cd2d94@mail.gmail.com> References: <7DDA17A8-90AD-4855-AD6B-AE6E1862BA17@gmail.com> <252EB9AB-213A-48DB-A4AD-82B77611DEAA@mac.com> <8C4EA2CA-5CD9-448E-BB48-B3BB54F4DD8F@mac.com> <597e7edb0806091557k214b5850u60f21462b3cd2d94@mail.gmail.com> Message-ID: On Jun 9, 2008, at 3:57 PM, Hamish Allan wrote: > On Mon, Jun 9, 2008 at 1:35 AM, Adam R. Maxwell > wrote: > >> So if I understand correctly, Christiaan is asking what the best >> practice is >> in this case for framework developers. > > My answer to this question would be: "file a bug requesting > namespaces". Normally that would be the correct answer, but not in this case... We have plenty of dupes of the "namespaces, please?" feature request radar. No need for more. It is definitely a very desirable feature and is also surprisingly hard to fix in an elegant fashion befitting Objective-C. thanks, b.bum From hamish at gmail.com Mon Jun 9 16:09:21 2008 From: hamish at gmail.com (Hamish Allan) Date: Mon Jun 9 16:09:25 2008 Subject: Frameworks, categories and shared namespace In-Reply-To: References: <7DDA17A8-90AD-4855-AD6B-AE6E1862BA17@gmail.com> <252EB9AB-213A-48DB-A4AD-82B77611DEAA@mac.com> <8C4EA2CA-5CD9-448E-BB48-B3BB54F4DD8F@mac.com> <597e7edb0806091557k214b5850u60f21462b3cd2d94@mail.gmail.com> Message-ID: <597e7edb0806091609v2f9baea9u598ddee7ee1d0678@mail.gmail.com> On Tue, Jun 10, 2008 at 12:02 AM, Bill Bumgarner wrote: > We have plenty of dupes of the "namespaces, please?" feature request radar. > No need for more. It is definitely a very desirable feature and is also > surprisingly hard to fix in an elegant fashion befitting Objective-C. I find it hard to believe that the fix could be less elegant than the workarounds we currently have to implement :) Hamish From amaxwell at mac.com Mon Jun 9 16:25:04 2008 From: amaxwell at mac.com (Adam R. Maxwell) Date: Mon Jun 9 16:25:10 2008 Subject: Frameworks, categories and shared namespace In-Reply-To: References: <7DDA17A8-90AD-4855-AD6B-AE6E1862BA17@gmail.com> <252EB9AB-213A-48DB-A4AD-82B77611DEAA@mac.com> <8C4EA2CA-5CD9-448E-BB48-B3BB54F4DD8F@mac.com> <597e7edb0806091557k214b5850u60f21462b3cd2d94@mail.gmail.com> Message-ID: <116F395F-011A-1000-C215-19C56A18C4C0-Webmail-10025@mac.com> On Monday, June 09, 2008, at 04:02PM, "Bill Bumgarner" wrote: >On Jun 9, 2008, at 3:57 PM, Hamish Allan wrote: >> On Mon, Jun 9, 2008 at 1:35 AM, Adam R. Maxwell >> wrote: >> >>> So if I understand correctly, Christiaan is asking what the best >>> practice is >>> in this case for framework developers. >> >> My answer to this question would be: "file a bug requesting >> namespaces". > >Normally that would be the correct answer, but not in this case... And I'd add that it still does not answer the question of best practice at the present time, since the chances of getting a response other than "Duplicate" to that bug report are less than epsilon. We all know that messages to bugreport.apple.com are oneway void :). -- Adam From kdyke at apple.com Mon Jun 9 17:03:04 2008 From: kdyke at apple.com (Kenneth Dyke) Date: Mon Jun 9 17:03:08 2008 Subject: Frameworks, categories and shared namespace In-Reply-To: References: <7DDA17A8-90AD-4855-AD6B-AE6E1862BA17@gmail.com> <252EB9AB-213A-48DB-A4AD-82B77611DEAA@mac.com> <8C4EA2CA-5CD9-448E-BB48-B3BB54F4DD8F@mac.com> <597e7edb0806091557k214b5850u60f21462b3cd2d94@mail.gmail.com> Message-ID: <7478EDF4-237E-4C25-AC5B-5692B80BA90C@apple.com> On Jun 9, 2008, at 4:02 PM, Bill Bumgarner wrote: > > Normally that would be the correct answer, but not in this case... > > We have plenty of dupes of the "namespaces, please?" feature request > radar. No need for more. It is definitely a very desirable feature > and is also surprisingly hard to fix in an elegant fashion befitting > Objective-C. You mean like garbage collection? ;) -Ken Kenneth Dyke, kcd@jumpgate.com (personal), kdyke@apple.com (work) Sr Engineer, Graphics and Imaging Team, Apple Computer, Inc. C++: The power, elegance and simplicity of a hand grenade. From mdpb at gmx.net Mon Jun 9 19:12:36 2008 From: mdpb at gmx.net (mdpb@gmx.net) Date: Mon Jun 9 19:12:44 2008 Subject: CGContextDrawImage drawing only once Message-ID: <36AC4694-BC75-48AF-96B7-ABE138A2E75B@gmx.net> Hi New to the list but I think this is a relative easy question for any coregraphics developer (which is I guess not me). I am displaying a series of bitmaps in a window (every so many seconds), almost like an animation. I am using CGContextDrawImage to draw the CGImage (created by CGBitmapContextCreateImage) to the context of my NSView. I got the CGContextRef of my NSView from the drawRect of my NSView. Here are the symptoms I run into: -I can draw one image like this to my NSView -I can draw another image but it won't get displayed/updated on my NSView -if I put my terminal at this point on top of my NSView then the correct picture shows up (my terminal is set to transparent so I see the NSView getting updated) -if I use a counter to display the pictures then I also get the correct picture displayed (there is no bug in reading the images, its the displaying part) What am I doing wrong, is there some kind of flag not set? Thanks Matt From mikevann at gmail.com Tue Jun 10 01:59:13 2008 From: mikevann at gmail.com (Michael Vannorsdel) Date: Tue Jun 10 01:59:20 2008 Subject: CGContextDrawImage drawing only once In-Reply-To: <36AC4694-BC75-48AF-96B7-ABE138A2E75B@gmx.net> References: <36AC4694-BC75-48AF-96B7-ABE138A2E75B@gmx.net> Message-ID: <711CC72E-7E8F-4DDA-AC11-7EDD8A1F36D5@gmail.com> Could you give some more information on how and where you do your drawing and perhaps show some code? What kind of backing store your window is using (Buffered, Retained, Nonretained)? On Jun 9, 2008, at 8:12 PM, mdpb@gmx.net wrote: > New to the list but I think this is a relative easy question for any > coregraphics developer (which is I guess not me). > > I am displaying a series of bitmaps in a window (every so many > seconds), almost like an animation. > > I am using CGContextDrawImage to draw the CGImage (created by > CGBitmapContextCreateImage) to the context of my NSView. > I got the CGContextRef of my NSView from the drawRect of my NSView. > > Here are the symptoms I run into: > -I can draw one image like this to my NSView > -I can draw another image but it won't get displayed/updated on my > NSView > -if I put my terminal at this point on top of my NSView then the > correct picture shows up (my terminal is set to transparent so I see > the NSView getting updated) > -if I use a counter to display the pictures then I also get the > correct picture displayed (there is no bug in reading the images, > its the displaying part) > > What am I doing wrong, is there some kind of flag not set? Thanks From cmhofman at gmail.com Tue Jun 10 03:05:03 2008 From: cmhofman at gmail.com (Christiaan Hofman) Date: Tue Jun 10 03:05:18 2008 Subject: Frameworks, categories and shared namespace In-Reply-To: <7478EDF4-237E-4C25-AC5B-5692B80BA90C@apple.com> References: <7DDA17A8-90AD-4855-AD6B-AE6E1862BA17@gmail.com> <252EB9AB-213A-48DB-A4AD-82B77611DEAA@mac.com> <8C4EA2CA-5CD9-448E-BB48-B3BB54F4DD8F@mac.com> <597e7edb0806091557k214b5850u60f21462b3cd2d94@mail.gmail.com> <7478EDF4-237E-4C25-AC5B-5692B80BA90C@apple.com> Message-ID: On 10 Jun 2008, at 2:03 AM, Kenneth Dyke wrote: > > On Jun 9, 2008, at 4:02 PM, Bill Bumgarner wrote: > >> >> Normally that would be the correct answer, but not in this case... >> >> We have plenty of dupes of the "namespaces, please?" feature >> request radar. No need for more. It is definitely a very >> desirable feature and is also surprisingly hard to fix in an >> elegant fashion befitting Objective-C. > > You mean like garbage collection? ;) > > > > -Ken Right, I think Apple missed an enormous opportunity here, that may not present itself anymore for about a decade (judging on the timespan between Obj-C 1.0 and Obj-C 2.0). BTW, I did not add a dupe to this request, but I did file a documentation bug, as I consider this issue important enough to consider lack of proper documentation (warnings and guidance) a bug, also considering the number of times I've seen it occur in 3rd party frameworks (as Adam also illustrated). Anyway, I'd still be interested in answers to my question ;) Christiaan From cmhofman at gmail.com Tue Jun 10 03:08:08 2008 From: cmhofman at gmail.com (Christiaan Hofman) Date: Tue Jun 10 03:08:15 2008 Subject: CGContextDrawImage drawing only once In-Reply-To: <36AC4694-BC75-48AF-96B7-ABE138A2E75B@gmx.net> References: <36AC4694-BC75-48AF-96B7-ABE138A2E75B@gmx.net> Message-ID: On 10 Jun 2008, at 4:12 AM, mdpb@gmx.net wrote: > Hi > > New to the list but I think this is a relative easy question for any > coregraphics developer (which is I guess not me). > > I am displaying a series of bitmaps in a window (every so many > seconds), almost like an animation. > > I am using CGContextDrawImage to draw the CGImage (created by > CGBitmapContextCreateImage) to the context of my NSView. > I got the CGContextRef of my NSView from the drawRect of my NSView. > > Here are the symptoms I run into: > -I can draw one image like this to my NSView > -I can draw another image but it won't get displayed/updated on my > NSView > -if I put my terminal at this point on top of my NSView then the > correct picture shows up (my terminal is set to transparent so I see > the NSView getting updated) > -if I use a counter to display the pictures then I also get the > correct picture displayed (there is no bug in reading the images, > its the displaying part) > > What am I doing wrong, is there some kind of flag not set? Thanks > > Matt What are you doing? It seems to me that you're drawing to the view's context directly outside the drawRect: method, is that correct? In that case, it's not a GC question but a Cocoa drawing question, and you should read . Christiaan From jswitte at bloomington.in.us Tue Jun 10 08:44:32 2008 From: jswitte at bloomington.in.us (Jim Witte) Date: Tue Jun 10 08:44:43 2008 Subject: Leopard weirdness In-Reply-To: References: <8DF96B2C-33D4-11DD-9C62-000393CA0072@smartsoft.de> Message-ID: On Jun 6, 2008, at 10:51 AM, Christiaan Hofman wrote: > However, one has to do a direct hit on the text to start editing. > I also think that the need to click on the text is annoying > behavior. I'm not sure if it's a bug though I would say it's a bug, because users who don't click directly on the text could get a behavior they don't expect - although I don't have Leopard installed. Also, if the cell is empty, from the user's POV there is no 'text' in the cell, so no indication of where to click - the obvious click target for editing is anywhere in the cell as there is nothing preexisting to edit. > I truly fail to see any reason for this (AOT single-click editing I > described above). Especially for still empty cells it makes it > really hard to edit. I do believe this is cause for a bug report > (or at least an enhancement request). What about having a "hidden feature" (Apple loves these) where if you command-clicked on a cell or something, it would automatically go into edit mode on the cell. Or for that matter, a haxie to do the same (although that would be sure to break, especially if Apple changed the TableView code in an update) > You can't simply revert back to the old editing behavior, it would > require you to override several methods in NSTableView, like > mouseDown:. It's very tricky to do that correctly. Moreover, this > is now the standard behavior, so better be consistent. So I advice > you to get used to it. That too.. Although a command click in a cell would preserve the existing behavior, while adding a way to get the the old behavior. Jim From jswitte at bloomington.in.us Tue Jun 10 08:49:03 2008 From: jswitte at bloomington.in.us (Jim Witte) Date: Tue Jun 10 08:49:14 2008 Subject: Leopard weirdness In-Reply-To: <6E360243-33E2-11DD-9C62-000393CA0072@smartsoft.de> References: <6E360243-33E2-11DD-9C62-000393CA0072@smartsoft.de> Message-ID: On Jun 6, 2008, at 12:05 PM, Andreas H?schler wrote: >> On the other hand, this allows you to have both an editable cell >> and a double click action for the same cell. > I see the ratio. Thanks for the explanation. I would prefer to be > able to modify this (switch back to old) behaviour in System > Preferences though. :-( Haxie? (but sure to break if they change anything). Or a triple click on a cell to edit. Why couldn't you just start editing directly from the doubleClick method for editable cells? You still have the problem of it not being standard behavior though. I wonder, how often is a doubleClick action on an editable cells actually USED by developers? Was this 'feature' requested because people wanted to put doubleClick actions on editable cells independent of editing them? Jim From cmhofman at gmail.com Tue Jun 10 10:11:34 2008 From: cmhofman at gmail.com (Christiaan Hofman) Date: Tue Jun 10 10:11:42 2008 Subject: Leopard weirdness In-Reply-To: References: <8DF96B2C-33D4-11DD-9C62-000393CA0072@smartsoft.de> Message-ID: On 10 Jun 2008, at 5:44 PM, Jim Witte wrote: > > On Jun 6, 2008, at 10:51 AM, Christiaan Hofman wrote: >> However, one has to do a direct hit on the text to start editing. >> I also think that the need to click on the text is annoying >> behavior. I'm not sure if it's a bug though > > I would say it's a bug, because users who don't click directly on > the text could get a behavior they don't expect - although I don't > have Leopard installed. Also, if the cell is empty, from the user's > POV there is no 'text' in the cell, so no indication of where to > click - the obvious click target for editing is anywhere in the cell > as there is nothing preexisting to edit. I did some testing, and I don't believe this is a bug (though you can file a bug report and see what Apple says). The actual behavior for an editable NSTextFieldCell is this: - empty cell: double-click anywhere in the cell starts editing - cell with text: double-click on the text always starts editing, double-click outside the text calls the double-click action if present, otherwise does nothing This seems to me intended behavior, the point being that you can call the double-click action by double-clicking an empty area in the cell, unless there's text, in which case you want to be able to edit. >> I truly fail to see any reason for this (AOT single-click editing I >> described above). Especially for still empty cells it makes it >> really hard to edit. I do believe this is cause for a bug report >> (or at least an enhancement request). > > What about having a "hidden feature" (Apple loves these) where if > you command-clicked on a cell or something, it would automatically > go into edit mode on the cell. Or for that matter, a haxie to do > the same (although that would be sure to break, especially if Apple > changed the TableView code in an update) > Certainly command-click is wrong, as that's used to extend a selection. The de-facto standard for this on Tiger is Option-click. >> You can't simply revert back to the old editing behavior, it would >> require you to override several methods in NSTableView, like >> mouseDown:. It's very tricky to do that correctly. Moreover, this >> is now the standard behavior, so better be consistent. So I advice >> you to get used to it. > > That too.. Although a command click in a cell would preserve the > existing behavior, while adding a way to get the the old behavior. > > Jim There really is no need to preserve the old behavior. It is more important to be consistent within the OS than to be consistent within an app (you normally don't switch back and forth between OS's, but you do switch back and forth between different apps). Christiaan From Gerben.Wierda at rna.nl Fri Jun 13 06:22:12 2008 From: Gerben.Wierda at rna.nl (Gerben Wierda) Date: Fri Jun 13 06:22:37 2008 Subject: Unix tool. Compiling on Leopard, deploying on Tiger, using Python In-Reply-To: <41D1947B-0E79-4744-B2E5-CA6106E47291@gmail.com> References: <7096D8D3-6B36-4C29-A1B3-36DB24F242E8@rna.nl> <41D1947B-0E79-4744-B2E5-CA6106E47291@gmail.com> Message-ID: <9C1AF3F7-A422-4FBC-994D-23EE1DCD7F4C@rna.nl> On Jun 8, 2008, at 12:37 PM, Christiaan Hofman wrote: > Have you tried adding an -dylib_file option to OTHER_LD_FLAGS? I added -dylib_file=/System/Library/Frameworks/Python.framework/ Versions/2.5/Python:/usr/lib/libpython2.dylib to the link command via configure (the OTHER_LD_FLAGS is for XCode projects), but what happens is: /bin/sh ../libtool --mode=link gcc -mmacosx-version-min=10.4 - dylib_file=/System/Library/Frameworks/Python.framework/Versions/2.5/ Python:/usr/lib/libpython2.dylib -L/usr/local/lib -L/sw/lib -o fontforge \ startnoui.o stamp.o exelibstamp.lo ../libfontforge.la -rpath /usr/ local/lib ../libgutils.la ../libgunicode.la -lpython2.5 -liconv - Wl,/System/Library/Frameworks/CoreServices.framework/CoreServices - lpthread -lm gcc -mmacosx-version-min=10.4 -dylib_file=/System/Library/Frameworks/ Python.framework/Versions/2.5/Python:/usr/lib/libpython2.dylib - o .libs/fontforge startnoui.o stamp.o .libs/exelibstamp.o -Wl,/System/ Library/Frameworks/CoreServices.framework/CoreServices -L/usr/local/ lib -L/sw/lib ../.libs/libfontforge.dylib /usr/local/src/ fontforge-20080429/.libs/libgutils.dylib ../.libs/libgutils.dylib /usr/ local/src/fontforge-20080429/.libs/libgunicode.dylib ../.libs/ libgunicode.dylib -lpython2.5 /usr/lib/libiconv.dylib -lpthread -lm And otool tells me: hermione-a:pfaedit gerben$ otool -L /usr/local/Build/i386/pfaedit/usr/ local/bin/fontforge /usr/local/Build/i386/pfaedit/usr/local/bin/fontforge: /System/Library/Frameworks/CoreServices.framework/Versions/A/ CoreServices (compatibility version 1.0.0, current version 32.0.0) /usr/local/lib/libfontforge.1.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/local/lib/libgutils.1.dylib (compatibility version 2.0.0, current version 2.1.0) /usr/local/lib/libgunicode.3.dylib (compatibility version 4.0.0, current version 4.0.0) /System/Library/Frameworks/Python.framework/Versions/2.5/Python (compatibility version 2.5.0, current version 2.5.1) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.1) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) In other words, I can tell it to use /usr/lib/libpython2.dlib but that does get translated to the actual file (/usr/lib/libpyton2.dlib) G > > Christiaan > > On 8 Jun 2008, at 9:03 AM, Gerben Wierda wrote: > >> OK, here is my problem. I want to create a binary (compiled from >> open source on Leopard) that works on both Tiger and Leopard, so >> backward compatible. Most of the time, this is no problem, but now >> it is. I compile and link the binary by giving this to configure: >> >> CFLAGS="-mmacosx-version-min=10.4" >> LDFLAGS="-mmacosx-version-min=10.4" >> >> which normally is all I have to do. But now I have a binary that >> uses Python. And though python is available in /usr/lib as symlink >> >> $ ls -l /usr/lib/*pyth* >> lrwxr-xr-x 1 root wheel 16 Dec 31 13:21 /usr/lib/libpython.dylib >> -> libpython2.dylib >> lrwxr-xr-x 1 root wheel 16 Dec 31 13:21 /usr/lib/ >> libpython2.5.dylib -> libpython2.dylib >> lrwxr-xr-x 1 root wheel 68 Dec 31 13:21 /usr/lib/ >> libpython2.dylib -> ../../System/Library/Frameworks/ >> Python.framework/Versions/2.5/Python >> lrwxr-xr-x 1 root wheel 75 Dec 31 13:31 /usr/lib/python2.5 - >> > ../../System/Library/Frameworks/Python.framework/Versions/2.5/lib/ >> python2.5 >> >> the resulting binary is linked hard against the python 2.5 library. >> Basically, at this stage I do not care if it is compiled and linked >> against 2.5 and when run on Tiger it is running against 2.3 (which >> may give problems). >> >> The resulting library is linked against >> >> /System/Library/Frameworks/Python.framework/Versions/2.5/Python >> (compatibility version 2.5.0, current version 2.5.1) >> >> which is not avaiable on Tiger and not against >> >> /usr/lib/libpython2.dylib >> >> which is. >> >> Is there a way to tell the binary to link against /usr/lib/ >> libpython2.dylib and not have it turn that into the actual 2.5 lib >> in /System? >> >> Thanks, >> >> G >> _______________________________________________ >> MacOSX-dev mailing list >> MacOSX-dev@omnigroup.com >> http://www.omnigroup.com/mailman/listinfo/macosx-dev > From cmhofman at gmail.com Fri Jun 13 08:23:18 2008 From: cmhofman at gmail.com (Christiaan Hofman) Date: Fri Jun 13 08:23:29 2008 Subject: Unix tool. Compiling on Leopard, deploying on Tiger, using Python In-Reply-To: <9C1AF3F7-A422-4FBC-994D-23EE1DCD7F4C@rna.nl> References: <7096D8D3-6B36-4C29-A1B3-36DB24F242E8@rna.nl> <41D1947B-0E79-4744-B2E5-CA6106E47291@gmail.com> <9C1AF3F7-A422-4FBC-994D-23EE1DCD7F4C@rna.nl> Message-ID: You're right, it does not change the install name, only the library it links to. The install name itself comes from the linked python library. You can change the install name using the install_name_tool, so you should use that. I am not an expert on linking, so be aware I may be wrong here. But I think you have 2 choices. Either change the install name in the python library. You can do that in the stub library. If you don't want to affect other projects you could make another version of the python library with your preferred install name and link to that (either build it from source or make a copy with the changed install name). Or you can change the install name of the python library in your executable, using an extra script build phase. HTH, Christiaan On 13 Jun 2008, at 3:22 PM, Gerben Wierda wrote: > On Jun 8, 2008, at 12:37 PM, Christiaan Hofman wrote: > >> Have you tried adding an -dylib_file option to OTHER_LD_FLAGS? > > I added -dylib_file=/System/Library/Frameworks/Python.framework/ > Versions/2.5/Python:/usr/lib/libpython2.dylib to the link command > via configure (the OTHER_LD_FLAGS is for XCode projects), but what > happens is: > > /bin/sh ../libtool --mode=link gcc -mmacosx-version-min=10.4 - > dylib_file=/System/Library/Frameworks/Python.framework/Versions/2.5/ > Python:/usr/lib/libpython2.dylib -L/usr/local/lib -L/sw/lib -o > fontforge \ > startnoui.o stamp.o exelibstamp.lo ../libfontforge.la -rpath / > usr/local/lib ../libgutils.la ../libgunicode.la -lpython2.5 - > liconv -Wl,/System/Library/Frameworks/CoreServices.framework/ > CoreServices -lpthread -lm > gcc -mmacosx-version-min=10.4 -dylib_file=/System/Library/Frameworks/ > Python.framework/Versions/2.5/Python:/usr/lib/libpython2.dylib - > o .libs/fontforge startnoui.o stamp.o .libs/exelibstamp.o -Wl,/ > System/Library/Frameworks/CoreServices.framework/CoreServices -L/ > usr/local/lib -L/sw/lib ../.libs/libfontforge.dylib /usr/local/src/ > fontforge-20080429/.libs/libgutils.dylib ../.libs/libgutils.dylib / > usr/local/src/fontforge-20080429/.libs/libgunicode.dylib ../.libs/ > libgunicode.dylib -lpython2.5 /usr/lib/libiconv.dylib -lpthread -lm > > And otool tells me: > > hermione-a:pfaedit gerben$ otool -L /usr/local/Build/i386/pfaedit/ > usr/local/bin/fontforge > /usr/local/Build/i386/pfaedit/usr/local/bin/fontforge: > /System/Library/Frameworks/CoreServices.framework/Versions/A/ > CoreServices (compatibility version 1.0.0, current version 32.0.0) > /usr/local/lib/libfontforge.1.dylib (compatibility version 2.0.0, > current version 2.0.0) > /usr/local/lib/libgutils.1.dylib (compatibility version 2.0.0, > current version 2.1.0) > /usr/local/lib/libgunicode.3.dylib (compatibility version 4.0.0, > current version 4.0.0) > /System/Library/Frameworks/Python.framework/Versions/2.5/Python > (compatibility version 2.5.0, current version 2.5.1) > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current > version 7.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 111.1.1) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current > version 1.0.0) > > In other words, I can tell it to use /usr/lib/libpython2.dlib but > that does get translated to the actual file (/usr/lib/libpyton2.dlib) > > G > >> >> Christiaan >> >> On 8 Jun 2008, at 9:03 AM, Gerben Wierda wrote: >> >>> OK, here is my problem. I want to create a binary (compiled from >>> open source on Leopard) that works on both Tiger and Leopard, so >>> backward compatible. Most of the time, this is no problem, but now >>> it is. I compile and link the binary by giving this to configure: >>> >>> CFLAGS="-mmacosx-version-min=10.4" >>> LDFLAGS="-mmacosx-version-min=10.4" >>> >>> which normally is all I have to do. But now I have a binary that >>> uses Python. And though python is available in /usr/lib as symlink >>> >>> $ ls -l /usr/lib/*pyth* >>> lrwxr-xr-x 1 root wheel 16 Dec 31 13:21 /usr/lib/ >>> libpython.dylib -> libpython2.dylib >>> lrwxr-xr-x 1 root wheel 16 Dec 31 13:21 /usr/lib/ >>> libpython2.5.dylib -> libpython2.dylib >>> lrwxr-xr-x 1 root wheel 68 Dec 31 13:21 /usr/lib/ >>> libpython2.dylib -> ../../System/Library/Frameworks/ >>> Python.framework/Versions/2.5/Python >>> lrwxr-xr-x 1 root wheel 75 Dec 31 13:31 /usr/lib/python2.5 - >>> > ../../System/Library/Frameworks/Python.framework/Versions/2.5/ >>> lib/python2.5 >>> >>> the resulting binary is linked hard against the python 2.5 >>> library. Basically, at this stage I do not care if it is compiled >>> and linked against 2.5 and when run on Tiger it is running against >>> 2.3 (which may give problems). >>> >>> The resulting library is linked against >>> >>> /System/Library/Frameworks/Python.framework/Versions/2.5/Python >>> (compatibility version 2.5.0, current version 2.5.1) >>> >>> which is not avaiable on Tiger and not against >>> >>> /usr/lib/libpython2.dylib >>> >>> which is. >>> >>> Is there a way to tell the binary to link against /usr/lib/ >>> libpython2.dylib and not have it turn that into the actual 2.5 lib >>> in /System? >>> >>> Thanks, >>> >>> G >>> _______________________________________________ >>> MacOSX-dev mailing list >>> MacOSX-dev@omnigroup.com >>> http://www.omnigroup.com/mailman/listinfo/macosx-dev >> > From cmhofman at gmail.com Fri Jun 13 10:10:46 2008 From: cmhofman at gmail.com (Christiaan Hofman) Date: Fri Jun 13 10:10:49 2008 Subject: Unix tool. Compiling on Leopard, deploying on Tiger, using Python In-Reply-To: References: <7096D8D3-6B36-4C29-A1B3-36DB24F242E8@rna.nl> <41D1947B-0E79-4744-B2E5-CA6106E47291@gmail.com> <9C1AF3F7-A422-4FBC-994D-23EE1DCD7F4C@rna.nl> Message-ID: <20166d560806131010v59d86880iff108a0d1a2efe8c@mail.gmail.com> BTW, unless you build your own version of libpython to link against, this may still not work. The reason is that install_name_tool does not change the compatibility version of the library, which therefore remains 2.5.0. So Tiger's version 2.3 would still not link, now because the dlopen deems it too old. Unfortunately I don't know how to change that part. I guess there's some other tool around to do that, but I never could find any myself. I would like to have it though, as I run into problems there when linking the libiconv library, which has incompatible versions on Leopard and Tiger. So if anyone could add this piece of the puzzle, I would also be grateful. Christiaan On Fri, Jun 13, 2008 at 5:23 PM, Christiaan Hofman wrote: > You're right, it does not change the install name, only the library it > links to. The install name itself comes from the linked python library. You > can change the install name using the install_name_tool, so you should use > that. > I am not an expert on linking, so be aware I may be wrong here. But I think > you have 2 choices. Either change the install name in the python library. > You can do that in the stub library. If you don't want to affect other > projects you could make another version of the python library with your > preferred install name and link to that (either build it from source or make > a copy with the changed install name). Or you can change the install name of > the python library in your executable, using an extra script build phase. > HTH, > Christiaan > > > On 13 Jun 2008, at 3:22 PM, Gerben Wierda wrote: > > On Jun 8, 2008, at 12:37 PM, Christiaan Hofman wrote: > > Have you tried adding an -dylib_file option to OTHER_LD_FLAGS? > > > I > added -dylib_file=/System/Library/Frameworks/Python.framework/Versions/2.5/Python:/usr/lib/libpython2.dylib > to the link command via configure (the OTHER_LD_FLAGS is for XCode > projects), but what happens is: > > /bin/sh ../libtool --mode=link gcc -mmacosx-version-min=10.4 > -dylib_file=/System/Library/Frameworks/Python.framework/Versions/2.5/Python:/usr/lib/libpython2.dylib > -L/usr/local/lib -L/sw/lib -o fontforge \ > startnoui.o stamp.o exelibstamp.lo ../libfontforge.la -rpath > /usr/local/lib ../libgutils.la ../libgunicode.la -lpython2.5 -liconv > -Wl,/System/Library/Frameworks/CoreServices.framework/CoreServices > -lpthread -lm > gcc -mmacosx-version-min=10.4 > -dylib_file=/System/Library/Frameworks/Python.framework/Versions/2.5/Python:/usr/lib/libpython2.dylib > -o .libs/fontforge startnoui.o stamp.o .libs/exelibstamp.o > -Wl,/System/Library/Frameworks/CoreServices.framework/CoreServices > -L/usr/local/lib -L/sw/lib ../.libs/libfontforge.dylib > /usr/local/src/fontforge-20080429/.libs/libgutils.dylib > ../.libs/libgutils.dylib > /usr/local/src/fontforge-20080429/.libs/libgunicode.dylib > ../.libs/libgunicode.dylib -lpython2.5 /usr/lib/libiconv.dylib -lpthread -lm > > And otool tells me: > > hermione-a:pfaedit gerben$ otool -L > /usr/local/Build/i386/pfaedit/usr/local/bin/fontforge > /usr/local/Build/i386/pfaedit/usr/local/bin/fontforge: > /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices > (compatibility version 1.0.0, current version 32.0.0) > /usr/local/lib/libfontforge.1.dylib (compatibility version 2.0.0, current > version 2.0.0) > /usr/local/lib/libgutils.1.dylib (compatibility version 2.0.0, current > version 2.1.0) > /usr/local/lib/libgunicode.3.dylib (compatibility version 4.0.0, current > version 4.0.0) > /System/Library/Frameworks/Python.framework/Versions/2.5/Python > (compatibility version 2.5.0, current version 2.5.1) > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version > 7.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 111.1.1) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version > 1.0.0) > > In other words, I can tell it to use /usr/lib/libpython2.dlib but that does > get translated to the actual file (/usr/lib/libpyton2.dlib) > > G > > > Christiaan > > On 8 Jun 2008, at 9:03 AM, Gerben Wierda wrote: > > OK, here is my problem. I want to create a binary (compiled from open > source on Leopard) that works on both Tiger and Leopard, so backward > compatible. Most of the time, this is no problem, but now it is. I compile > and link the binary by giving this to configure: > > CFLAGS="-mmacosx-version-min=10.4" > LDFLAGS="-mmacosx-version-min=10.4" > > which normally is all I have to do. But now I have a binary that uses > Python. And though python is available in /usr/lib as symlink > > $ ls -l /usr/lib/*pyth* > lrwxr-xr-x 1 root wheel 16 Dec 31 13:21 /usr/lib/libpython.dylib -> > libpython2.dylib > lrwxr-xr-x 1 root wheel 16 Dec 31 13:21 /usr/lib/libpython2.5.dylib -> > libpython2.dylib > lrwxr-xr-x 1 root wheel 68 Dec 31 13:21 /usr/lib/libpython2.dylib -> > ../../System/Library/Frameworks/Python.framework/Versions/2.5/Python > lrwxr-xr-x 1 root wheel 75 Dec 31 13:31 /usr/lib/python2.5 -> > ../../System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5 > > the resulting binary is linked hard against the python 2.5 library. > Basically, at this stage I do not care if it is compiled and linked against > 2.5 and when run on Tiger it is running against 2.3 (which may give > problems). > > The resulting library is linked against > > /System/Library/Frameworks/Python.framework/Versions/2.5/Python > (compatibility version 2.5.0, current version 2.5.1) > > which is not avaiable on Tiger and not against > > /usr/lib/libpython2.dylib > > which is. > > Is there a way to tell the binary to link against /usr/lib/libpython2.dylib > and not have it turn that into the actual 2.5 lib in /System? > > Thanks, > > G > _______________________________________________ > MacOSX-dev mailing list > MacOSX-dev@omnigroup.com > http://www.omnigroup.com/mailman/listinfo/macosx-dev > > > > > From brianarthur at nc.rr.com Sat Jun 14 08:07:43 2008 From: brianarthur at nc.rr.com (Anthony B Arthur) Date: Sat Jun 14 08:07:54 2008 Subject: iPhone Message-ID: Anyone out there doing iPhone dev? Sorry, I don't see an iPhone specific discussion covering this topic. If you are aware of one, sponsored by Apple, please advise. My question: Is there a published list of URL schemes for iPhone apps that support this feature, especially interested in safari. Is there a way to access registered URL schemes programmatically? But the best (and easiest) solution to what I need to do is -- is there a class or an API interface to the iPhone safari app whereby I can submit a google search from within my app, which transitions my app out, and brings in safari with the google search started? Any ideas? --Brian From alastair at alastairs-place.net Sat Jun 14 08:26:56 2008 From: alastair at alastairs-place.net (Alastair Houghton) Date: Sat Jun 14 08:27:00 2008 Subject: iPhone In-Reply-To: References: Message-ID: <9E70BECC-A125-4C78-BC0F-4AC95D41D6C1@alastairs-place.net> On 14 Jun 2008, at 16:07, Anthony B Arthur wrote: > Anyone out there doing iPhone dev? Sorry, I don't see an iPhone > specific discussion covering this topic. iPhone SDK is still under NDA. Nobody can answer your question without breaking their NDA, and Apple hasn't provided any way around that restriction. When the SDK is officially released, the NDA will probably end and we'll all be able to talk about the iPhone. Until then, publicly answering questions would be foolish because breaking your NDA *could* lead to you being locked out of distributing apps through the App Store. Kind regards, Alastair. -- http://alastairs-place.net From brianarthur at nc.rr.com Sat Jun 14 08:35:34 2008 From: brianarthur at nc.rr.com (Anthony B Arthur) Date: Sat Jun 14 08:35:45 2008 Subject: iPhone In-Reply-To: <9E70BECC-A125-4C78-BC0F-4AC95D41D6C1@alastairs-place.net> References: <9E70BECC-A125-4C78-BC0F-4AC95D41D6C1@alastairs-place.net> Message-ID: Apologies. I thought we could discuss it here, but not anywhere else. -b On Jun 14, 2008, at 11:26 AM, Alastair Houghton wrote: > On 14 Jun 2008, at 16:07, Anthony B Arthur wrote: > >> Anyone out there doing iPhone dev? Sorry, I don't see an iPhone >> specific discussion covering this topic. > > iPhone SDK is still under NDA. Nobody can answer your question > without breaking their NDA, and Apple hasn't provided any way > around that restriction. > > When the SDK is officially released, the NDA will probably end and > we'll all be able to talk about the iPhone. Until then, publicly > answering questions would be foolish because breaking your NDA > *could* lead to you being locked out of distributing apps through > the App Store. > > Kind regards, > > Alastair. > > -- > http://alastairs-place.net > > From sherm.pendley at gmail.com Sat Jun 14 11:39:14 2008 From: sherm.pendley at gmail.com (Sherm Pendley) Date: Sat Jun 14 11:39:17 2008 Subject: iPhone In-Reply-To: References: Message-ID: On Sat, Jun 14, 2008 at 11:07 AM, Anthony B Arthur wrote: > > solution to what I need to do is -- is there a class or an API interface to > the iPhone safari app whereby I can submit a google search from within my > app, which transitions my app out, and brings in safari with the google > search started? Any ideas? Well, the iPhone details are (as others have said) subject to NDA. But the general idea of doing a Google search is pretty much the same, regardless of the specific API. Google expects a GET request with search terms in the query argument "q", so one builds an appropriate URL string or object. Most any modern API is going to have a function or method that accepts a URL and opens it with the default app for its scheme. For example, in Cocoa you'd create an NSURL object with a query string: NSURL *url = [NSURL URLWithString:@"http://www.google.com/search?q=wv+trout+fishing"]; You can do all kinds of advanced searching and filtering with Google this way. Just do the search manually in your browser, and look at the address bar to see what arguments you need to generate to do that kind of search from your app. For example, if you only wanted family-friendly youtube videos: NSURL *url = [NSURL URLWithString:@"http://www.google.com/search?safe=on&q=wv+trout+fishing+site%3Ayoutube.com"]; Then you'd use NSWorkspace to launch the query in the user's default browser for http:// URLs: [[NSWorkspace sharedWorkspace] openURL:url]; I haven't downloaded the iPhone SDK, but it is public knowledge that it's based on Cocoa. That said, I'd expect it to work similarly to the above, although maybe with different class names. But even if the API is completely different, the general principle still holds true - create a URL (string or object) with a query string to drive the Google options, and pass it to a toolkit function (or method) to open it. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net From pelorus at mac.com Sat Jun 14 11:55:42 2008 From: pelorus at mac.com (Matt Johnston) Date: Sat Jun 14 11:55:51 2008 Subject: iPhone In-Reply-To: References: Message-ID: On 14 Jun 2008, at 19:39, Sherm Pendley wrote: > On Sat, Jun 14, 2008 at 11:07 AM, Anthony B Arthur > wrote: >> >> solution to what I need to do is -- is there a class or an API >> interface to >> the iPhone safari app whereby I can submit a google search from >> within my >> app, which transitions my app out, and brings in safari with the >> google >> search started? Any ideas? > > Well, the iPhone details are (as others have said) subject to NDA. Yeah, pain in the butt. No-one to ask if you have difficulties. Thanks, Apple. From wave at pixar.com Sat Jun 14 12:49:46 2008 From: wave at pixar.com (Michael B Johnson) Date: Sat Jun 14 12:50:24 2008 Subject: iPhone In-Reply-To: References: Message-ID: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> On Jun 14, 2008, at 11:55 AM, Matt Johnston wrote: > > On 14 Jun 2008, at 19:39, Sherm Pendley wrote: > >> On Sat, Jun 14, 2008 at 11:07 AM, Anthony B Arthur >> wrote: >>> >>> solution to what I need to do is -- is there a class or an API >>> interface to >>> the iPhone safari app whereby I can submit a google search from >>> within my >>> app, which transitions my app out, and brings in safari with the >>> google >>> search started? Any ideas? >> >> Well, the iPhone details are (as others have said) subject to NDA. > > Yeah, pain in the butt. No-one to ask if you have difficulties. > > Thanks, Apple. Yea, no on-line documentation, or tutorials, or sample code. No NDA'ed conference where 5,000 developers and 1,000 Apple engineers can talk about developing for the iPhone. hey - wait a minute... oh. Thanks, Apple. > > _______________________________________________ > MacOSX-dev mailing list > MacOSX-dev@omnigroup.com > http://www.omnigroup.com/mailman/listinfo/macosx-dev From brianarthur at nc.rr.com Sat Jun 14 15:22:40 2008 From: brianarthur at nc.rr.com (Anthony B Arthur) Date: Sat Jun 14 15:22:51 2008 Subject: iPhone In-Reply-To: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> Message-ID: Ok, I never meant for this to spill over into an argument. There is an NDA, and I will positively honor that, there is sample code and that is great, and there is already lots of documentation, also great. I do think it is a bit misleading to post a link to this mailing list inside the iPhone Dev Center pages: http://developer.apple.com/information/ this is the information link found at the top of the iPhone DevCenter main page. -b On Jun 14, 2008, at 3:49 PM, Michael B Johnson wrote: > > On Jun 14, 2008, at 11:55 AM, Matt Johnston wrote: > >> >> On 14 Jun 2008, at 19:39, Sherm Pendley wrote: >> >>> On Sat, Jun 14, 2008 at 11:07 AM, Anthony B Arthur >>> wrote: >>>> >>>> solution to what I need to do is -- is there a class or an API >>>> interface to >>>> the iPhone safari app whereby I can submit a google search from >>>> within my >>>> app, which transitions my app out, and brings in safari with the >>>> google >>>> search started? Any ideas? >>> >>> Well, the iPhone details are (as others have said) subject to NDA. >> >> Yeah, pain in the butt. No-one to ask if you have difficulties. >> >> Thanks, Apple. > > Yea, no on-line documentation, or tutorials, or sample code. > > No NDA'ed conference where 5,000 developers and 1,000 Apple > engineers can talk about developing for the iPhone. > > hey - wait a minute... > > oh. > > Thanks, Apple. > > > >> >> _______________________________________________ >> MacOSX-dev mailing list >> MacOSX-dev@omnigroup.com >> http://www.omnigroup.com/mailman/listinfo/macosx-dev > > _______________________________________________ > MacOSX-dev mailing list > MacOSX-dev@omnigroup.com > http://www.omnigroup.com/mailman/listinfo/macosx-dev From bbum at mac.com Sat Jun 14 16:10:43 2008 From: bbum at mac.com (Bill Bumgarner) Date: Sat Jun 14 16:10:47 2008 Subject: iPhone In-Reply-To: References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> Message-ID: <15B70DBC-B56F-494A-8138-E20F555ABAE1@mac.com> On Jun 14, 2008, at 3:22 PM, Anthony B Arthur wrote: > Ok, I never meant for this to spill over into an argument. There is > an NDA, and I will positively honor that, there is sample code and > that is great, and there is already lots of documentation, also > great. I do think it is a bit misleading to post a link to this > mailing list inside the iPhone Dev Center pages: > > http://developer.apple.com/information/ > > this is the information link found at the top of the iPhone > DevCenter main page. The mailing lists are extremely useful, regardless of NDA. Much of iPhone development is an identical experience to Coca development. Thus, many relevant questions can be posed (and typically answered) via objc-lang, cocoa-dev, xcode-users and other mailing lists. b.bum From sstevenson at mac.com Sat Jun 14 16:10:47 2008 From: sstevenson at mac.com (Scott Stevenson) Date: Sat Jun 14 16:11:35 2008 Subject: iPhone In-Reply-To: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> Message-ID: <52C2DA5B-108B-4C60-9030-12E75D906370@mac.com> On Jun 14, 2008, at 12:49 PM, Michael B Johnson wrote: > Yea, no on-line documentation, or tutorials, or sample code. > > No NDA'ed conference where 5,000 developers and 1,000 Apple > engineers can talk about developing for the iPhone. > > hey - wait a minute... iPhone developer support is also available from DTS: http://developer.apple.com/technicalsupport/ - Scott From adam.q.salter at gmail.com Sat Jun 14 22:12:35 2008 From: adam.q.salter at gmail.com (Adam Salter) Date: Sat Jun 14 22:23:05 2008 Subject: iPhone In-Reply-To: <15B70DBC-B56F-494A-8138-E20F555ABAE1@mac.com> References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> <15B70DBC-B56F-494A-8138-E20F555ABAE1@mac.com> Message-ID: <8225A9D7-3E54-4BFE-BB4B-AFC375B1CBC6@gmail.com> It's not 'illegal' for two developers under NDA to talk to each other either... so if the original poster wanted to talk to another developer under NDA just email him directly and open up communications... -Adam On 15/06/2008, at 9:10 AM, Bill Bumgarner wrote: > On Jun 14, 2008, at 3:22 PM, Anthony B Arthur wrote: >> Ok, I never meant for this to spill over into an argument. There >> is an NDA, and I will positively honor that, there is sample code >> and that is great, and there is already lots of documentation, also >> great. I do think it is a bit misleading to post a link to this >> mailing list inside the iPhone Dev Center pages: >> >> http://developer.apple.com/information/ >> >> this is the information link found at the top of the iPhone >> DevCenter main page. > > The mailing lists are extremely useful, regardless of NDA. Much of > iPhone development is an identical experience to Coca development. > > Thus, many relevant questions can be posed (and typically answered) > via objc-lang, cocoa-dev, xcode-users and other mailing lists. > > b.bum > > > _______________________________________________ > MacOSX-dev mailing list > MacOSX-dev@omnigroup.com > http://www.omnigroup.com/mailman/listinfo/macosx-dev From joar at joar.com Sat Jun 14 22:33:19 2008 From: joar at joar.com (j o a r) Date: Sat Jun 14 22:33:23 2008 Subject: iPhone In-Reply-To: <8225A9D7-3E54-4BFE-BB4B-AFC375B1CBC6@gmail.com> References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> <15B70DBC-B56F-494A-8138-E20F555ABAE1@mac.com> <8225A9D7-3E54-4BFE-BB4B-AFC375B1CBC6@gmail.com> Message-ID: <5C8EC637-DAAE-4C79-B6A6-8E69937B89DC@joar.com> On Jun 14, 2008, at 10:12 PM, Adam Salter wrote: > It's not 'illegal' for two developers under NDA to talk to each > other either... so if the original poster wanted to talk to another > developer under NDA just email him directly and open up > communications... Provided that what you say is true, how do you propose that they verify that both are covered by the same NDA? j o a r From pelorus at mac.com Sat Jun 14 23:23:19 2008 From: pelorus at mac.com (Matt Johnston) Date: Sat Jun 14 23:23:31 2008 Subject: iPhone In-Reply-To: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> Message-ID: Hey Michael - a friend of mine WAS at WWDC and spoke very enthusiastically about your Project Management presentation. Kudos. Back to the subject..... On 14 Jun 2008, at 20:49, Michael B Johnson wrote: >> Yeah, pain in the butt. No-one to ask if you have difficulties. >> >> Thanks, Apple. > > Yea, no on-line documentation, or tutorials, or sample code. And if you have difficulties.... > No NDA'ed conference where 5,000 developers and 1,000 Apple > engineers can talk about developing for the iPhone. And don't have a spare 5 grand to drop on a weeks holiday in San Francisco that was sold out and, ahem, last week? I also have three instances of DTS but I don't want to go to them with my issues because I'd be turning up to WWDC next year and I'd be the red-headed stepchild :( > hey - wait a minute... > > oh. > > Thanks, Apple. I'm only getting started in Mac development [1], so it's just frustrating that there's contractual restrictions on who I can talk to and no way to actually verify that someone is NDA'ed. This isn't a criticism of Apple but rather a criticism of a process. And I'm not alone in this. M [1] as a result of "If you want it done properly, do it yourself." From alastair at alastairs-place.net Sun Jun 15 04:32:29 2008 From: alastair at alastairs-place.net (Alastair Houghton) Date: Sun Jun 15 04:32:34 2008 Subject: iPhone In-Reply-To: <8225A9D7-3E54-4BFE-BB4B-AFC375B1CBC6@gmail.com> References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> <15B70DBC-B56F-494A-8138-E20F555ABAE1@mac.com> <8225A9D7-3E54-4BFE-BB4B-AFC375B1CBC6@gmail.com> Message-ID: On 15 Jun 2008, at 06:12, Adam Salter wrote: > It's not 'illegal' for two developers under NDA to talk to each > other either... Unfortunately the NDA itself is marked "Apple Confidential" and so we can't really discuss that either. But in general you cannot assume that any given NDA allows signatories to talk to each other. You need to check the terms and conditions to see if that is the case. My impression is that Apple's NDAs generally do *not* allow signatories to discuss amongst themselves. Obviously you will need to examine any NDAs you are subject to and you may require the services of a lawyer to do that. Kind regards, Alastair. -- http://alastairs-place.net From aglee at mac.com Sun Jun 15 04:37:54 2008 From: aglee at mac.com (Andy Lee) Date: Sun Jun 15 04:37:57 2008 Subject: iPhone In-Reply-To: References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> <15B70DBC-B56F-494A-8138-E20F555ABAE1@mac.com> <8225A9D7-3E54-4BFE-BB4B-AFC375B1CBC6@gmail.com> Message-ID: On Jun 15, 2008, at 7:32 AM, Alastair Houghton wrote: > My impression is that Apple's NDAs generally do *not* allow > signatories to discuss amongst themselves. Obviously you will need > to examine any NDAs you are subject to and you may require the > services of a lawyer to do that. Someone remarked last year that technically, two people sitting next to each other at a WWDC lecture couldn't turn to each other and discuss it. --Andy From pelorus at mac.com Sun Jun 15 04:48:22 2008 From: pelorus at mac.com (Matt Johnston) Date: Sun Jun 15 04:48:27 2008 Subject: iPhone In-Reply-To: References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> <15B70DBC-B56F-494A-8138-E20F555ABAE1@mac.com> <8225A9D7-3E54-4BFE-BB4B-AFC375B1CBC6@gmail.com> Message-ID: <717EAA55-EBF6-4A32-875B-F042FE103199@mac.com> On 15 Jun 2008, at 12:37, Andy Lee wrote: > On Jun 15, 2008, at 7:32 AM, Alastair Houghton wrote: >> My impression is that Apple's NDAs generally do *not* allow >> signatories to discuss amongst themselves. Obviously you will need >> to examine any NDAs you are subject to and you may require the >> services of a lawyer to do that. > > Someone remarked last year that technically, two people sitting next > to each other at a WWDC lecture couldn't turn to each other and > discuss it. It's a funny old world.... From pelorus at mac.com Sun Jun 15 05:03:36 2008 From: pelorus at mac.com (Matt Johnston) Date: Sun Jun 15 05:03:41 2008 Subject: iPhone In-Reply-To: <20486174-8D20-4235-ACB4-EA777A87ADB0@growler.net> References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> <15B70DBC-B56F-494A-8138-E20F555ABAE1@mac.com> <8225A9D7-3E54-4BFE-BB4B-AFC375B1CBC6@gmail.com> <717EAA55-EBF6-4A32-875B-F042FE103199@mac.com> <20486174-8D20-4235-ACB4-EA777A87ADB0@growler.net> Message-ID: <451511AA-42C1-431F-9F2F-E3008E129241@mac.com> On 15 Jun 2008, at 12:57, John Chandler wrote: > > On Jun 15, 2008, at 7:48 AM, Matt Johnston wrote: >>> >>> Someone remarked last year that technically, two people sitting >>> next to each other at a WWDC lecture couldn't turn to each other >>> and discuss it. > >> It's a funny old world.... > > Yeah, can anyone hazard a guess as to an actual, well-thought-out > *reason* > behind a restriction like that, or is it just "the new cruelty?" You cannot guarantee that two people at WWDC are both bound by NDA. This is the thing with secrets and trust. From aglee at mac.com Sun Jun 15 05:04:41 2008 From: aglee at mac.com (Andy Lee) Date: Sun Jun 15 05:04:45 2008 Subject: iPhone In-Reply-To: <717EAA55-EBF6-4A32-875B-F042FE103199@mac.com> References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> <15B70DBC-B56F-494A-8138-E20F555ABAE1@mac.com> <8225A9D7-3E54-4BFE-BB4B-AFC375B1CBC6@gmail.com> <717EAA55-EBF6-4A32-875B-F042FE103199@mac.com> Message-ID: <188CE4A9-3CC9-4B9A-934D-F9CAD11FE059@mac.com> On Jun 15, 2008, at 7:48 AM, Matt Johnston wrote: > On 15 Jun 2008, at 12:37, Andy Lee wrote: >> [...] >> Someone remarked last year that technically, two people sitting >> next to each other at a WWDC lecture couldn't turn to each other >> and discuss it. > > It's a funny old world.... Note that I'm not vouching for the legal accuracy of that statement, and obviously Apple is willing to look the other way if it is accurate. I just remember the comment because it sounded both plausible and funny. --Andy From morph at growler.net Sun Jun 15 04:57:48 2008 From: morph at growler.net (John Chandler) Date: Sun Jun 15 05:23:28 2008 Subject: iPhone In-Reply-To: <717EAA55-EBF6-4A32-875B-F042FE103199@mac.com> References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> <15B70DBC-B56F-494A-8138-E20F555ABAE1@mac.com> <8225A9D7-3E54-4BFE-BB4B-AFC375B1CBC6@gmail.com> <717EAA55-EBF6-4A32-875B-F042FE103199@mac.com> Message-ID: <20486174-8D20-4235-ACB4-EA777A87ADB0@growler.net> On Jun 15, 2008, at 7:48 AM, Matt Johnston wrote: > > On 15 Jun 2008, at 12:37, Andy Lee wrote: > >> On Jun 15, 2008, at 7:32 AM, Alastair Houghton wrote: >>> My impression is that Apple's NDAs generally do *not* allow >>> signatories to discuss amongst themselves. Obviously you will >>> need to examine any NDAs you are subject to and you may require >>> the services of a lawyer to do that. >> >> Someone remarked last year that technically, two people sitting >> next to each other at a WWDC lecture couldn't turn to each other >> and discuss it. > It's a funny old world.... Yeah, can anyone hazard a guess as to an actual, well-thought-out *reason* behind a restriction like that, or is it just "the new cruelty?" -jmc From mah at jump-ing.de Sun Jun 15 08:20:41 2008 From: mah at jump-ing.de (Markus Hitter) Date: Sun Jun 15 08:20:47 2008 Subject: iPhone In-Reply-To: <20486174-8D20-4235-ACB4-EA777A87ADB0@growler.net> References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> <15B70DBC-B56F-494A-8138-E20F555ABAE1@mac.com> <8225A9D7-3E54-4BFE-BB4B-AFC375B1CBC6@gmail.com> <717EAA55-EBF6-4A32-875B-F042FE103199@mac.com> <20486174-8D20-4235-ACB4-EA777A87ADB0@growler.net> Message-ID: <614CD371-8C07-45BD-B1F1-506155CF85C5@jump-ing.de> Am 15.06.2008 um 13:57 schrieb John Chandler: > Yeah, can anyone hazard a guess as to an actual, well-thought-out > *reason* > behind a restriction like that, or is it just "the new cruelty?" - They can sell you more support incidents, as each developer has to ask individually. - No sign in the public wether the iPhone SDK is useful at all. Everybody has to believe the marketing stuff. - Test how much they can stretch a developers loyalty before he jumps ship for Java, QT or myStep on another platform. - They can alomst always complain (and sue) about leaks. - They prohibit community building which could make a counterweight to their own opinion. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From pelorus at mac.com Sun Jun 15 08:26:49 2008 From: pelorus at mac.com (Matt Johnston) Date: Sun Jun 15 08:26:54 2008 Subject: iPhone In-Reply-To: <614CD371-8C07-45BD-B1F1-506155CF85C5@jump-ing.de> References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> <15B70DBC-B56F-494A-8138-E20F555ABAE1@mac.com> <8225A9D7-3E54-4BFE-BB4B-AFC375B1CBC6@gmail.com> <717EAA55-EBF6-4A32-875B-F042FE103199@mac.com> <20486174-8D20-4235-ACB4-EA777A87ADB0@growler.net> <614CD371-8C07-45BD-B1F1-506155CF85C5@jump-ing.de> Message-ID: <0E02B62B-8AD4-4E28-91AF-D187D9F6B69C@mac.com> On 15 Jun 2008, at 16:20, Markus Hitter wrote: > > Am 15.06.2008 um 13:57 schrieb John Chandler: >> Yeah, can anyone hazard a guess as to an actual, well-thought-out >> *reason* >> behind a restriction like that, or is it just "the new cruelty?" > > - They can sell you more support incidents, as each developer has to > ask individually. > - No sign in the public wether the iPhone SDK is useful at all. > Everybody has to believe the marketing stuff > - Test how much they can stretch a developers loyalty before he > jumps ship for Java, QT or myStep on another platform. > - They can alomst always complain (and sue) about leaks. > - They prohibit community building which could make a counterweight > to their own opinion. Wow, you're a ray of sunshine :) I'm less cynical. I see where Apple excels so well that it shows the disparity when they fall below my (inflated, opinionated) expectations. I have to assume there are good reasons. Just stings me that Redmond is more 'open'. M From cmhofman at gmail.com Sun Jun 15 14:25:40 2008 From: cmhofman at gmail.com (Christiaan Hofman) Date: Sun Jun 15 14:25:47 2008 Subject: Copying directories as resources Message-ID: When Xcode copies directories in a resources build phase, it leaves so all kinds of stuff you normaly don't want (such as version control info, .DS_STORE, etc). However I could not find a tool that can do this in an easy way. Is this tool somehow publicly available on the system, so I can use it in a custom script build phase? thanks, Christiaan From gsslist+osxdev at anthropohedron.net Sun Jun 15 15:03:44 2008 From: gsslist+osxdev at anthropohedron.net (Gregory Seidman) Date: Sun Jun 15 15:06:09 2008 Subject: iPhone In-Reply-To: <614CD371-8C07-45BD-B1F1-506155CF85C5@jump-ing.de> References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> <15B70DBC-B56F-494A-8138-E20F555ABAE1@mac.com> <8225A9D7-3E54-4BFE-BB4B-AFC375B1CBC6@gmail.com> <717EAA55-EBF6-4A32-875B-F042FE103199@mac.com> <20486174-8D20-4235-ACB4-EA777A87ADB0@growler.net> <614CD371-8C07-45BD-B1F1-506155CF85C5@jump-ing.de> Message-ID: <20080615220343.GA23710@anthropohedron.net> On Sun, Jun 15, 2008 at 05:20:41PM +0200, Markus Hitter wrote: > > Am 15.06.2008 um 13:57 schrieb John Chandler: >> Yeah, can anyone hazard a guess as to an actual, well-thought-out >> *reason* >> behind a restriction like that, or is it just "the new cruelty?" > > - They can sell you more support incidents, as each developer has to ask > individually. > > - No sign in the public wether the iPhone SDK is useful at all. > Everybody has to believe the marketing stuff. > > - Test how much they can stretch a developers loyalty before he jumps > ship for Java, QT or myStep on another platform. > > - They can alomst always complain (and sue) about leaks. > > - They prohibit community building which could make a counterweight to > their own opinion. This is complete garbage, and you know it. The NDA for the iPhone SDK beta exists because it's a beta. Anything one can say about the SDK now could be wholly inaccurate in a week. Apple can and does change APIs, behavior, etc. to a greater or lesser extent with each beta. Are you in the beta? Have you tried following any of the original videos with the current SDK beta? It's in Apple's best interest to avoid having misleading information out there. They enforce this with an NDA. When the SDK is released, with stable APIs, the NDA will be over. At that point there will be a community and public discussion and developers helping one another. > Markus --Greg From pelorus at mac.com Mon Jun 16 23:30:06 2008 From: pelorus at mac.com (Matt Johnston) Date: Mon Jun 16 23:30:13 2008 Subject: iPhone In-Reply-To: <20080615220343.GA23710@anthropohedron.net> References: <76015586-D15D-418B-BDA6-97B591AE483F@pixar.com> <15B70DBC-B56F-494A-8138-E20F555ABAE1@mac.com> <8225A9D7-3E54-4BFE-BB4B-AFC375B1CBC6@gmail.com> <717EAA55-EBF6-4A32-875B-F042FE103199@mac.com> <20486174-8D20-4235-ACB4-EA777A87ADB0@growler.net> <614CD371-8C07-45BD-B1F1-506155CF85C5@jump-ing.de> <20080615220343.GA23710@anthropohedron.net> Message-ID: Hey guys, Bringing this back to the positive (with a non-NDA related question) Apart from iPhone Open Development, are there any iPhone specific development books on the horizon? Matt -- http://xcake.org - XCode development on the island of Ireland - just launched! From aya at animes.de Tue Jun 17 01:50:45 2008 From: aya at animes.de (Aya Koshigaya) Date: Tue Jun 17 02:23:18 2008 Subject: Creating windows and menus without Interface Builder in C++ Message-ID: <5746D210-0914-409F-8C3F-89713F6A85B6@animes.de> Hi, I want to write an application where I need to build the Window myself, WITHOUT InterfaceBuilder... What I want to do is to create an OpenGL application, but without the use of GLUT. So, is there any way to create a windows with c++ (or Obj-C if I can use it then in my C++ code)? I also need to listen to any keystrokes and mouse events etc. And a second problem is, I need a popup-men?.. means, I have to create this without the InterfaceBuilder too. How do I do this? Thanks Aya From mah at jump-ing.de Tue Jun 17 02:45:36 2008 From: mah at jump-ing.de (Markus Hitter) Date: Tue Jun 17 02:45:44 2008 Subject: Creating windows and menus without Interface Builder in C++ In-Reply-To: <5746D210-0914-409F-8C3F-89713F6A85B6@animes.de> References: <5746D210-0914-409F-8C3F-89713F6A85B6@animes.de> Message-ID: <6334E2D1-32EB-490E-A454-D4D419310248@jump-ing.de> Am 17.06.2008 um 10:50 schrieb Aya Koshigaya: > So, is there any way to create a windows with c++ Sure, you can recreate Cocoa from scratch, using solely Quartz. I doubt you really want this, though. Creating an useable OpenGL window with Interface Builder is a matter of minutes and by doinf it yourself you loose all the tiny functions which make the Mac OS experience. If you still insist in avoiding IB, there's Renaissance If you still insist in using C++ for the viewing part ... I've heard openoffice.org took a similar approach by wrapping Cocoa in a C++ layer (and becoming as slow as the former Cocoa/Java). Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From aya at animes.de Tue Jun 17 02:57:07 2008 From: aya at animes.de (Aya Koshigaya) Date: Tue Jun 17 02:57:33 2008 Subject: Creating windows and menus without Interface Builder in C++ In-Reply-To: <6334E2D1-32EB-490E-A454-D4D419310248@jump-ing.de> References: <5746D210-0914-409F-8C3F-89713F6A85B6@animes.de> <6334E2D1-32EB-490E-A454-D4D419310248@jump-ing.de> Message-ID: <8EF09F24-05B6-43C0-8371-438A142299BC@animes.de> Hi, the reason I want to do this without the InterfaceBuilder is, my tool is platform independant and comes from Windows/Linux... Here I just create the Windows in my c++ code and draw OpenGL stuff on them.. and the best way for me would be to just replace my createWindow-function with the one for OSX. (Sure there's a bit more then the createWindow- function, but I think you know what I meant) And the same thing goes for the popup menu.. I know it's very easy with InterfaceBuilder, but I don't want to create a special solution for OSX.. Aya~ On Jun 17, 2008, at 11:45, Markus Hitter wrote: > > Am 17.06.2008 um 10:50 schrieb Aya Koshigaya: >> So, is there any way to create a windows with c++ > > Sure, you can recreate Cocoa from scratch, using solely Quartz. > > I doubt you really want this, though. Creating an useable OpenGL > window with Interface Builder is a matter of minutes and by doinf it > yourself you loose all the tiny functions which make the Mac OS > experience. > > If you still insist in avoiding IB, there's Renaissance > > > > If you still insist in using C++ for the viewing part ... I've heard > openoffice.org took a similar approach by wrapping Cocoa in a C++ > layer (and becoming as slow as the former Cocoa/Java). > > > Markus > > - - - - - - - - - - - - - - - - - - - > Dipl. Ing. Markus Hitter > http://www.jump-ing.de/ > > > > From edward.patel at memention.com Tue Jun 17 03:15:59 2008 From: edward.patel at memention.com (Edward Patel) Date: Tue Jun 17 03:16:05 2008 Subject: Creating windows and menus without Interface Builder in C++ In-Reply-To: <8EF09F24-05B6-43C0-8371-438A142299BC@animes.de> Message-ID: <20080617101559.8C7B94C089@nmail2.ballou.se> Why not look at the GLUT sources? http://developer.apple.com/samplecode/glut/listing81.html Think there are a lot of meaty things for you there... /Edward -----Ursprungligt meddelande----- Fr?n: Aya Koshigaya Skickat: Till: Markus Hitter Kopia: MacOS List ?mne: Re: Creating windows and menus without Interface Builder in C++ Hi, the reason I want to do this without the InterfaceBuilder is, my tool is platform independant and comes from Windows/Linux... Here I just create the Windows in my c++ code and draw OpenGL stuff on them.. and the best way for me would be to just replace my createWindow-function with the one for OSX. (Sure there's a bit more then the createWindow- function, but I think you know what I meant) And the same thing goes for the popup menu.. I know it's very easy with InterfaceBuilder, but I don't want to create a special solution for OSX.. Aya~ On Jun 17, 2008, at 11:45, Markus Hitter wrote: > > Am 17.06.2008 um 10:50 schrieb Aya Koshigaya: >> So, is there any way to create a windows with c++ > > Sure, you can recreate Cocoa from scratch, using solely Quartz. > > I doubt you really want this, though. Creating an useable OpenGL > window with Interface Builder is a matter of minutes and by doinf it > yourself you loose all the tiny functions which make the Mac OS > experience. > > If you still insist in avoiding IB, there's Renaissance > > > > If you still insist in using C++ for the viewing part ... I've heard > openoffice.org took a similar approach by wrapping Cocoa in a C++ > layer (and becoming as slow as the former Cocoa/Java). > > > Markus > > - - - - - - - - - - - - - - - - - - - > Dipl. Ing. Markus Hitter > http://www.jump-ing.de/ > > > > _______________________________________________ MacOSX-dev mailing list MacOSX-dev@omnigroup.com http://www.omnigroup.com/mailman/listinfo/macosx-dev From colding at 42tools.com Tue Jun 17 05:12:14 2008 From: colding at 42tools.com (Jules Colding) Date: Tue Jun 17 05:17:27 2008 Subject: Xcode and static linking - not possible? Message-ID: Hi, I can not get Xcode 3.0 to link statically. I have (among others) the following libraries in "/opt/local/lib": -rwxr-xr-x 2 root admin 371916 4 Jun 13:59 libORBit-2.0.1.0.dylib lrwxr-xr-x 1 root admin 22 4 Jun 13:59 libORBit-2.0.dylib -> libORBit-2.0.1.0.dylib -rw-r--r-- 2 root admin 523632 4 Jun 13:59 libORBit-2.a lrwxr-xr-x 1 root admin 22 4 Jun 13:59 libORBit-2.dylib -> libORBit-2.0.1.0.dylib -rwxr-xr-x 2 root admin 1077 4 Jun 13:59 libORBit-2.la I want to link with "libORBit-2.a". I went about doing that by adding the library to the "External Frameworks and Libraries" folder in my Xcode project. Building the binary goes fine but when inspected with "otool -L" it is shown that it links against "libORBit-2.0.dylib" - not the static library. Is there any way I can persuade Xcode to link the binary with the static library? Thanks a lot in advance, jules From jnutting at gmail.com Tue Jun 17 07:46:45 2008 From: jnutting at gmail.com (Jack Nutting) Date: Tue Jun 17 07:46:49 2008 Subject: Creating windows and menus without Interface Builder in C++ In-Reply-To: <8EF09F24-05B6-43C0-8371-438A142299BC@animes.de> References: <5746D210-0914-409F-8C3F-89713F6A85B6@animes.de> <6334E2D1-32EB-490E-A454-D4D419310248@jump-ing.de> <8EF09F24-05B6-43C0-8371-438A142299BC@animes.de> Message-ID: On Tue, Jun 17, 2008 at 11:57 AM, Aya Koshigaya wrote: > I know it's very easy with > InterfaceBuilder, but I don't want to create a special solution for OSX.. Frankly, I think that avoiding InterfaceBuilder probably *is* a "special solution" that should be avoided. IMHO a cross-platform application that needs to use native GUI widgets should use the facilities provided by the native platform as much as possible. It's easy enough to make an Objective-C++ "bridge" between your C++ app and the Cocoa GUI, and in fact doing so will probably make you think about your interfaces a bit and help in the overall design of your cross-platform system. -- // jack // http://www.nuthole.com From aya at animes.de Tue Jun 17 07:58:17 2008 From: aya at animes.de (Aya Koshigaya) Date: Tue Jun 17 07:58:21 2008 Subject: Creating windows and menus without Interface Builder in C++ In-Reply-To: References: <5746D210-0914-409F-8C3F-89713F6A85B6@animes.de> <6334E2D1-32EB-490E-A454-D4D419310248@jump-ing.de> <8EF09F24-05B6-43C0-8371-438A142299BC@animes.de> Message-ID: <2CAB4F7D-7BC5-40F8-93D3-784D4759EA53@animes.de> Hi, the only thing I need from OSX are windows for my OpenGL Context! I can't and won't believe it's not possbile (or only in a very difficult way) to just create an window without InterfaceBuilder! Also, my appli