From slittle at free.fr Mon Oct 1 02:38:24 2007 From: slittle at free.fr (scott little) Date: Mon Oct 1 02:38:31 2007 Subject: embedded frameworks and dyld failure In-Reply-To: <4B7761D0-CEE7-4155-9E3B-75A77A973C26@gmail.com> References: <764557B4-9A9D-4EBD-BEEB-8EF3198FF94A@tanjero.com> <11CB8B38-5623-4183-A259-FAE19596B280@nc.rr.com> <19DAEA9C-9432-4796-82CA-76D1811300F3@free.fr> <4B7761D0-CEE7-4155-9E3B-75A77A973C26@gmail.com> Message-ID: <95EFDB8E-8490-4393-A7F6-DDD4C01F174A@free.fr> Uli, Thanks for this information, it helped a lot, because in searching for other @executable_path options (which I was aware of from the first time I looked at this) I found that the Tiger Release Notes actually DO provide a @loader_path! http://developer.apple.com/releasenotes/DeveloperTools/RN-dyld/ Works fine now. Note that I have already taken into account the other points that you mention here. scott -- "Only the curious will learn and only the resolute overcome the obstacles to learning. The quest quotient has always excited me more than the intelligence quotient." Eugene S. Wilson -- scott little slittle@free.fr -- sadly no music right now: iTunes is Stopped On 29 Sep, 2007, at 19:51, Uli Kusterer wrote: > Am 29.09.2007 um 11:53 schrieb scott little: >> I have found that the exact same issue occurs for Mail Plugins >> that I have written. I was trying to use RBSplitView as a >> framework from within a plugin and at run time it would always >> complain about that framework not being there. I could not get the >> linker to change where it would look at run time no matter what I >> did. In the end I used the static library supplied for RBSplitView. >> >> I would love to know how to solve this one as well. > > @executable_path literally means the path of the *executable* > launched. It won't point to the loader of a particular library, it > will point to the root application in whose memory space all those > libraries were launched. You'd need something like an @loader_path > if you want to embed one framework in the other. Since, AFAIK, that > isn't available yet, you may have to change the path of a bundle > that is loaded by another bundle so it points at the correct path > *relative to the application*, not relative to its containing > framework. > > Does that help in any way? You'd definitely want to make sure you > have unique identifiers, too, because frameworks get loaded based > on their identifier, I think, so it may be possible that if one > framework got loaded with a particular identifier, the OS may not > actually load the others. > > Also, make sure your Cocoa class names are unique across *all* > frameworks. There's only a single namespace for classes, so if you > load a framework with a class named the same as one already loaded, > your new class will not be loaded, and your code will use the > already loaded class instead, which may implement a completely > different API. > > Cheers, > -- M. Uli Kusterer > http://www.zathras.de > > > > From kusterer at gmail.com Mon Oct 1 02:40:14 2007 From: kusterer at gmail.com (Uli Kusterer) Date: Mon Oct 1 02:40:26 2007 Subject: embedded frameworks and dyld failure In-Reply-To: <95EFDB8E-8490-4393-A7F6-DDD4C01F174A@free.fr> References: <764557B4-9A9D-4EBD-BEEB-8EF3198FF94A@tanjero.com> <11CB8B38-5623-4183-A259-FAE19596B280@nc.rr.com> <19DAEA9C-9432-4796-82CA-76D1811300F3@free.fr> <4B7761D0-CEE7-4155-9E3B-75A77A973C26@gmail.com> <95EFDB8E-8490-4393-A7F6-DDD4C01F174A@free.fr> Message-ID: <2C7B6B94-3E43-4777-ACA4-C0FBD16256DA@gmail.com> Am 01.10.2007 um 11:38 schrieb scott little: > Thanks for this information, it helped a lot, because in searching > for other @executable_path options (which I was aware of from the > first time I looked at this) I found that the Tiger Release Notes > actually DO provide a @loader_path! Ah, good to know. I used the name because I remembered I'd read it somewhere, but didn't say more because I wasn't sure whether it had been in Leopard :-) Cheers, -- M. Uli Kusterer http://www.zathras.de From marc at boxstudios.com Wed Oct 3 08:39:06 2007 From: marc at boxstudios.com (Marc Van Olmen) Date: Wed Oct 3 08:59:54 2007 Subject: Job Opportunity: Box Services is hiring a full-time cocoa Developer, New York City Message-ID: <6BE9E42C-CE6F-457B-B038-FA851A2996BD@boxstudios.com> Boxwork, the digital division of Box Services LLC, is responsible for research, software development, and digital photography capture. Boxwork is looking to expand our MacOS X Software development team. The job opening is more specific to developing the next generation of our Media Asset Management software solution. Please send resumes to: marc@boxstudios.com Software Engineer (full time position) Job qualifications include: * Good knowledge of Cocoa/Objective-C * SQL Database experience, in particular MySQL * Ability to work in a team environment * Good communication skills (reporting/documentation) * Able to develop specific parts of the software by following strict guidelines * Work at our New York location in the meat-packing district (no remote working * Understanding XML specifications Plus: * REST/SOAP experience * XSLT * PHP and server development experience Regards, Marc Van Olmen Senior Software Architect Box Services LLC 412W 14th Street, New York, NY 10014 http://www.boxwork.com http://www.boxstudios.com From ivan at myrvold.org Thu Oct 4 08:38:35 2007 From: ivan at myrvold.org (Ivan C Myrvold) Date: Thu Oct 4 08:59:01 2007 Subject: Nested SOAP parameters Message-ID: <2175419D-307D-4855-806D-E3879D07971F@myrvold.org> How do I make nested SOAP parameters in Cocoa? If I want to send a parameter like ivan I can simply set WSMethodInvocationSetParameters(soapCall, (CFDictionaryRef)params, nil); where params = [NSDictionary dictionaryWithObjectsAndKeys:@"ivan", @"name", nil); But what if I have a parameter like: ivan How do I pass that to WSMethodInvocationSetParameters? Ivan From publicity2005 at adhocconference.com Fri Oct 5 11:15:38 2007 From: publicity2005 at adhocconference.com (Michael Dautermann) Date: Fri Oct 5 11:22:19 2007 Subject: Nested SOAP parameters In-Reply-To: <20071004190009.D05061BDD9B@forums.omnigroup.com> References: <20071004190009.D05061BDD9B@forums.omnigroup.com> Message-ID: On Oct 4, 2007, at 12:00 PM, macosx-dev-request@omnigroup.com wrote: > > How do I make nested SOAP parameters in Cocoa? > > If I want to send a parameter like > > ivan > > I can simply set > WSMethodInvocationSetParameters(soapCall, (CFDictionaryRef)params, > nil); > where > params = [NSDictionary dictionaryWithObjectsAndKeys:@"ivan", @"name", > nil); > > But what if I have a parameter like: > > > ivan > > > How do I pass that to WSMethodInvocationSetParameters? How about params = [ NSDictionary dictionaryWithObject: [ NSDictionary dictionaryWithObject: @"ivan" forKey: @"name" ] forKey: @"person" ]; ???? From johnyatforums at gmail.com Fri Oct 5 11:53:36 2007 From: johnyatforums at gmail.com (JanakiRam) Date: Fri Oct 5 11:53:40 2007 Subject: Uninstaller for Mac OSX Application Message-ID: <3f7852640710051153n12456b67o2830712b6c86cc0a@mail.gmail.com> Hi All, I'm new to installer / uninstaller stuff in Mac OS X. I'm doing a port of Windows application to Mac.My Application has kext , mac application and some files in /opt folder. I've managed to create an installer using Package Maker in Mac OS X Tiger. But couldn't find any application which creates Uninstaller for my application. I've googled for it , many blogs say that there is no Uninstaller in Mac till now. Is it True ? My application installer should have an UI which should be similar to installer and delete the required files in background. Can any one provider some pointers for creating uninstaller for my application. Are there any third party freeware/sharewares uninstaller applications available in Mac OS X. Please help me to solve this. Thanks in Advance. -JanakiRam. From mzarra at zarrastudios.com Fri Oct 5 12:07:32 2007 From: mzarra at zarrastudios.com (Marcus S. Zarra) Date: Fri Oct 5 12:08:03 2007 Subject: Uninstaller for Mac OSX Application In-Reply-To: <3f7852640710051153n12456b67o2830712b6c86cc0a@mail.gmail.com> References: <3f7852640710051153n12456b67o2830712b6c86cc0a@mail.gmail.com> Message-ID: Unless you are installing something at the system level, you should not be using an installer at all. And yes, there is no uninstaller for I'd X because you should not be using an installer. Marcus S. Zarra Zarra Studios LLC www.zarrastudios.com On Oct 5, 2007, at 12:53 PM, JanakiRam wrote: > Hi All, > I'm new to installer / uninstaller stuff in Mac OS X. I'm doing > a port > of Windows application to Mac.My Application has kext , mac > application and > some files in /opt folder. > > I've managed to create an installer using Package Maker in Mac > OS X > Tiger. But couldn't find any application which creates Uninstaller > for my > application. > > I've googled for it , many blogs say that there is no > Uninstaller in > Mac till now. Is it True ? > > > My application installer should have an UI which should be > similar to > installer and delete the required files in background. > > Can any one provider some pointers for creating uninstaller for my > application. > > Are there any third party freeware/sharewares uninstaller > applications > available in Mac OS X. > > Please help me to solve this. Thanks in Advance. > > -JanakiRam. > _______________________________________________ > MacOSX-dev mailing list > MacOSX-dev@omnigroup.com > http://www.omnigroup.com/mailman/listinfo/macosx-dev From atomicbird at gmail.com Fri Oct 5 13:33:56 2007 From: atomicbird at gmail.com (Tom Harrington) Date: Fri Oct 5 13:34:06 2007 Subject: Uninstaller for Mac OSX Application In-Reply-To: References: <3f7852640710051153n12456b67o2830712b6c86cc0a@mail.gmail.com> Message-ID: <68162e550710051333r7e219923g8860a1fab266fb34@mail.gmail.com> > On Oct 5, 2007, at 12:53 PM, JanakiRam wrote: > > Hi All, > > I'm new to installer / uninstaller stuff in Mac OS X. I'm doing a port > > of Windows application to Mac.My Application has kext , mac > > application and some files in /opt folder. Please be careful about putting things in /opt/. Anyone who uses MacPorts is likely to have a lot there already, so make sure you're not clobbering existing software. > > I've googled for it , many blogs say that there is no Uninstaller in > > Mac till now. Is it True ? That's true. You can either roll your own or look at third party solutions like FileStorm, which can create both installers and uninstallers. On 10/5/07, Marcus S. Zarra wrote: > Unless you are installing something at the system level, you should > not be using an installer at all. Installing kexts is probably one of the cases where it's justified, being as they have specific needs regarding where they're installed and how they're loaded. -- Tom Harrington atomicbird@gmail.com AIM: atomicbird1 From chad+macosx at objectwerks.com Fri Oct 5 15:18:04 2007 From: chad+macosx at objectwerks.com (Chad Leigh) Date: Fri Oct 5 15:18:12 2007 Subject: Uninstaller for Mac OSX Application In-Reply-To: <68162e550710051333r7e219923g8860a1fab266fb34@mail.gmail.com> References: <3f7852640710051153n12456b67o2830712b6c86cc0a@mail.gmail.com> <68162e550710051333r7e219923g8860a1fab266fb34@mail.gmail.com> Message-ID: <4119EB6D-C9EF-4556-8D44-BB01815514C1@objectwerks.com> On Oct 5, 2007, at 2:33 PM, Tom Harrington wrote: > > Installing kexts is probably one of the cases where it's justified, > being as they have specific needs regarding where they're installed > and how they're loaded. I have not done this and am not a whiz but wouldn't a simple applescript or something that can trigger a shellscript be enough to unload and get rid of the kext? Chad From dunham at mac.com Sun Oct 7 14:21:06 2007 From: dunham at mac.com (David Dunham) Date: Sun Oct 7 14:21:12 2007 Subject: Printing vs Cocoa Autosave?? Message-ID: <02F57B69-93B6-4783-B9F3-AE1858122572@mac.com> I'm kind of grasping at straws, but are there strange freezes or crashes in my NSDocument-based application when a user prints to PDF. He originally reported that this happened in documents he had edited, so I'm wondering if it might be autosave kicking in during printing. It looks like printing is handled in its own thread, and it's possible something not thread-safe is happening? Has anyone else had problems along these lines? David Dunham A Sharp, LLC Voice/Fax: 206 783 7404 http://a-sharp.com Efficiency is intelligent laziness. From edenwaith at mac.com Sun Oct 7 15:19:04 2007 From: edenwaith at mac.com (Chad Armstrong) Date: Sun Oct 7 15:19:11 2007 Subject: Uninstaller for Mac OSX Application In-Reply-To: <20071006190007.904921BED5A@forums.omnigroup.com> References: <20071006190007.904921BED5A@forums.omnigroup.com> Message-ID: I agree with others' comments, that whenever possible, avoid using an installer. However, there are cases when an application needs to place a number of items in a variety of locations, and requiring the user to manually move each of the files to their required spot seems like unnecessary work, and this is a good situation where an installer is useful. But it definitely does seem like a glaring hole that an uninstaller wasn't also included. Is it possible to use Apple's installer program to create a script which will just uninstall the application? From what I've read, it appears that an uninstaller can look in the Receipts folder and read the list of files that were installed for a particular application, and then use that list of files to search out the files to erase. Has anyone tried this? Otherwise, installing applications that don't also include an uninstaller makes me suspicious and weary. Regards, Chad From mah at jump-ing.de Mon Oct 8 02:59:55 2007 From: mah at jump-ing.de (Markus Hitter) Date: Mon Oct 8 03:00:05 2007 Subject: Uninstaller for Mac OSX Application In-Reply-To: References: <20071006190007.904921BED5A@forums.omnigroup.com> Message-ID: <7708FD2A-7FDD-4FDD-8DBC-21C8CB99BD3C@jump-ing.de> Am 08.10.2007 um 00:19 schrieb Chad Armstrong: > But it definitely does seem like a glaring hole that an uninstaller > wasn't also included. ... especially, as all the prerequisites are there already. > Is it possible to use Apple's installer program to create a script > which will just uninstall the application? Get started with lsbom -s -f /Library/Receipts/MyPackage.pkg/Contents/Archive.bom lsbom -d /Library/Receipts/MyPackage.pkg/Contents/Archive.bom Another approach is to create an update installer which upgrades to zero files and removes it's self in the postinstall script. I've seen it with one of the ghostscript packages (at linuxprinting.org?). > Otherwise, installing applications that don't also include an > uninstaller makes me suspicious and weary. Just yesterday I removed some 20 GB of automatically downloaded upgraders and installers which filled up about 50% of the main hard drive. All belonging to software of three big manufacturers. Obviously, your company is small enough to take better care of such details. Congratulations. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From cmhofman at gmail.com Mon Oct 8 14:32:32 2007 From: cmhofman at gmail.com (Christiaan Hofman) Date: Mon Oct 8 14:32:26 2007 Subject: Binding NSTokenField Message-ID: <4366D757-DDB0-468F-8131-A076B2E3342D@gmail.com> Hi list, I'm having trouble binding an NSTokenField. I want to bind to an array of custom objects, which have a string representation for display. So I bind the value of the NSTokenField to a key for an NSArray of my controller. The controller is also the NSTokenField's delegate, and implements tokenField:displayStringForRepresentedObject: delegate method, to return the string representation of the custom object. However when I try to run this app, the tokenField is not filled and I get lots of log messages like the following: represented objects must either be an NSString or you must implement the displayStringForRepresentedObject: delegate method. Well, as I said I *did* implement this delegate method. Is this a (known) bug? Or did I miss something? Christiaan From bob at apple.com Mon Oct 8 14:51:43 2007 From: bob at apple.com (Bob Frank) Date: Mon Oct 8 14:52:18 2007 Subject: MEETING: Chicago CocoaHeads / CAWUG - Scripting CoreData - Tuesday October 9th 7:00 PM Message-ID: <56D99030-558E-4FAD-B4EB-AC84E8B032AC@apple.com> IMPORTANT NOTES: Our meeting tomorrow will start at ** 7:00 ** instead of 6:00 We have a new mailing list URL: http://groups.google.com/group/cawug Email Address: cawug@googlegroups.com You can email here to subscribe immediately: cawug-subscribe@googlegroups.com -------- Hi all, The Chicago CocoaHeads / Chicago Cocoa and WebObjects User Group (CAWUG) is holding our next meeting this coming Tuesday, September 11th, at 6:00 PM at the Apple Store on Michigan Ave. Agenda: - Introductions & Announcements - Don Briggs on the Scriptable Core Data Framework - adjournment to O'Toole's When: Tuesday, September 11th, 6:00 PM Where: Apple Store Michigan Avenue 679 North Michigan Ave. (at the corner of Huron & Michigan Ave.) Chicago, IL 60611 http://maps.yahoo.com/maps_result? ed=gYbE5Op_0Tokf_p7h61dwjbWtjC2r1YehzWw&csz=60611 http://tinyurl.com/26z5nb (in case long URL gets cut) - Don Briggs on the Scriptable Core Data Framework Don Briggs is presenting his Scriptable Core Data Framework: How to make your Core Data applications scriptable at the Core Data layer. Don started working on NextStep/OpenStep "back in the day" (1992) and has been working on various ObjC based apps on & off ever since (as well as a variety of non-Apple technologies). - O'Tooles We will continue the discussion at our local watering hold Timothy O'Toole's at 622 Fairbanks (2 blocks east of the store). We also wish to thank the folks who run the theater space at the Apple store for letting us have our meetings there, and Jonathan 'Wolf' Rentzsch for hosting the new and revived CAWUG web site. Thanks all. Also, if you are working on a project and would like to talk about it briefly / promote it, I think it would be fun for people to hear about other people's projects. Please email me off line and you can talk at a future meeting or would like a book to review. Future meetings dates: 11/13/07 & 12/11/07 CAWUG Resources Mail list: http://groups.google.com/group/cawug Google Site: http://groups.google.com/group/cawug Web Site: http://www.cawug.org/ RSS feed: http://www.cawug.org/rss.xml iCal: http://ical.mac.com/chicagobob/ Chicago-CocoaHeads-CAWUG (view on the web) iCal: webcal://ical.mac.com/chicagobob/Chicago-CocoaHeads-CAWUG.ics (subscribe to in iCal) Cocoa Heads web site: http://cocoaheads.org/us/ChicagoIllinois/index.html Hope to see you at the meeting. -Bob --- Bob Frank (312) 961 - 0509 [cell] bob@apple.com From bob at apple.com Mon Oct 8 15:17:04 2007 From: bob at apple.com (Bob Frank) Date: Mon Oct 8 15:17:43 2007 Subject: MEETING: Chicago CocoaHeads / CAWUG - Scripting CoreData - Tuesday October 9th 7:00 PM In-Reply-To: <56D99030-558E-4FAD-B4EB-AC84E8B032AC@apple.com> References: <56D99030-558E-4FAD-B4EB-AC84E8B032AC@apple.com> Message-ID: Hello All, Doh! Please forgive the few copy and paste errors in the previous message. Our meeting *is* tomorrow, Tuesday, October 9th at 7:00 at the Chicago Apple Store on Michigan Ave. Hope to see you there, Bob On Oct 8, 2007, at 4:51 PM, Bob Frank wrote: > IMPORTANT NOTES: > > Our meeting tomorrow will start at ** 7:00 ** instead of 6:00 > > We have a new mailing list > URL: http://groups.google.com/group/cawug > Email Address: cawug@googlegroups.com > You can email here to subscribe immediately: > cawug-subscribe@googlegroups.com > > -------- > > Hi all, > > The Chicago CocoaHeads / Chicago Cocoa and WebObjects User Group > (CAWUG) is holding our next meeting this coming Tuesday, October > 9th, 7:00 PM at the Apple Store on Michigan Ave. > > Agenda: > - Introductions & Announcements > - Don Briggs on the Scriptable Core Data Framework > - adjournment to O'Toole's > > When: > Tuesday, October 9th, 7:00 PM > > Where: > Apple Store Michigan Avenue > 679 North Michigan Ave. (at the corner of Huron & Michigan Ave.) > Chicago, IL 60611 > http://maps.yahoo.com/maps_result? > ed=gYbE5Op_0Tokf_p7h61dwjbWtjC2r1YehzWw&csz=60611 > http://tinyurl.com/26z5nb > (in case long URL gets cut) > > > - Don Briggs on the Scriptable Core Data Framework > > Don Briggs is presenting his Scriptable Core Data Framework: How to > make your Core Data applications scriptable at the Core Data layer. > > Don started working on NextStep/OpenStep "back in the day" (1992) > and has been working on various ObjC based apps on & off ever since > (as well as a variety of non-Apple technologies). > > > - O'Tooles > We will continue the discussion at our local watering hold Timothy > O'Toole's at 622 Fairbanks (2 blocks east of the store). > > > We also wish to thank the folks who run the theater space at the > Apple store for letting us have our meetings there, and Jonathan > 'Wolf' Rentzsch for hosting the new and revived CAWUG web site. > Thanks all. > > Also, if you are working on a project and would like to talk about > it briefly / promote it, I think it would be fun for people to > hear about other people's projects. Please email me off line and > you can talk at a future meeting or would like a book to review. > > > Future meetings dates: 11/13/07 & 12/11/07 > > > > CAWUG Resources > > Mail list: http://groups.google.com/group/cawug > Google Site: http://groups.google.com/group/cawug > Web Site: http://www.cawug.org/ > RSS feed: http://www.cawug.org/rss.xml > iCal: http://ical.mac.com/chicagobob/ Chicago-CocoaHeads-CAWUG > (view on the web) > iCal: webcal://ical.mac.com/chicagobob/Chicago-CocoaHeads- > CAWUG.ics (subscribe to in iCal) > > Cocoa Heads web site: > http://cocoaheads.org/us/ChicagoIllinois/index.html > > > Hope to see you at the meeting. > > -Bob > > > > --- > Bob Frank > (312) 961 - 0509 [cell] > bob@apple.com > > > --- Bob Frank (312) 961 - 0509 [cell] bob@apple.com From ivan.galic at gmail.com Mon Oct 15 12:08:40 2007 From: ivan.galic at gmail.com (Ivan Galic) Date: Mon Oct 15 12:08:52 2007 Subject: set_errno missing? Message-ID: Hello, I've searched but I couldn't find the function set_errno(), or something equivalent, to set the global errno variable used by the CRT. Or is there not need to set it directly (currently I want to set it to 0 to make sure that I don't catch any errors left from other function calls)? For example, the wcstol sets errno to some error value if an error occurs. I want to make sure that if errno is set to an error value, that it was this function which caused it, and not some call that happened who knows when... Does anyone have any ideas? Thanks, Ivan From daniel at highdesertchurch.com Mon Oct 15 12:10:09 2007 From: daniel at highdesertchurch.com (Daniel Hazelbaker) Date: Mon Oct 15 12:11:12 2007 Subject: File Path Tracking Message-ID: <71132DE1-3694-47CD-8C09-439A8F437D02@highdesertchurch.com> I have a program that keeps track of files by using the Unix Path to the file (as that is what is used to open and work with the files when the time comes). I have run into a problem where when the files are stored on a network volume my program can occasionally no longer find the files because the path might have changed (i.e. "/Volumes/ Data" becomes "/Volumes/Data 1"). This is particularly a problem with Fast User Switching as "Data" might be mounted a number of times. How might I deal with this type of issue? Daniel From kusterer at gmail.com Mon Oct 15 12:17:01 2007 From: kusterer at gmail.com (Uli Kusterer) Date: Mon Oct 15 12:17:08 2007 Subject: File Path Tracking In-Reply-To: <71132DE1-3694-47CD-8C09-439A8F437D02@highdesertchurch.com> References: <71132DE1-3694-47CD-8C09-439A8F437D02@highdesertchurch.com> Message-ID: Am 15.10.2007 um 21:10 schrieb Daniel Hazelbaker: > I have a program that keeps track of files by using the Unix Path > to the file (as that is what is used to open and work with the > files when the time comes). I have run into a problem where when > the files are stored on a network volume my program can > occasionally no longer find the files because the path might have > changed (i.e. "/Volumes/Data" becomes "/Volumes/Data 1"). This is > particularly a problem with Fast User Switching as "Data" might be > mounted a number of times. > > How might I deal with this type of issue? As you noticed, file paths are not suitable for referencing files reliably. Check out Aliases, which can be used for this and are reliable. There's the CoreFoundation/Carbon Alias Manager API for this, or alternately you can use one of the Cocoa wrappers, like Nathan Day's NDAlias. Cheers, -- M. Uli Kusterer http://www.zathras.de From erik.buck at sbcglobal.net Mon Oct 15 13:36:25 2007 From: erik.buck at sbcglobal.net (Erik Buck) Date: Mon Oct 15 13:43:10 2007 Subject: File Path Tracking Message-ID: <442669.25326.qm@web80501.mail.mud.yahoo.com> Correct me if I am wrong, but I don't think "Aliases" can cope with network mount name changes any better than Unix paths. In fact, "Aliases" basically only work better than paths when used within one partition of a local hard disk that is formatted as HFS+. In all other cases, an "Alias" is just a non-standard way to encode a path that adds complexity for no value. Am I wrong ? From kusterer at gmail.com Mon Oct 15 14:03:29 2007 From: kusterer at gmail.com (Uli Kusterer) Date: Mon Oct 15 14:03:39 2007 Subject: File Path Tracking In-Reply-To: <442669.25326.qm@web80501.mail.mud.yahoo.com> References: <442669.25326.qm@web80501.mail.mud.yahoo.com> Message-ID: <5732648A-8193-4ACE-9BCC-F12D924AC6B4@gmail.com> Am 15.10.2007 um 22:36 schrieb Erik Buck: > Correct me if I am wrong, but I don't think "Aliases" can cope with > network mount name changes any better than Unix paths. In fact, > "Aliases" basically only work better than paths when used within > one partition of a local hard disk that is formatted as HFS+. In > all other cases, an "Alias" is just a non-standard way to encode a > path that adds complexity for no value. Am I wrong ? You are. Aliases will search for a file when it can't be referenced through a path or name, and thus will generally locate a file even when the drive has been unmounted or renamed, because they look at the actual names of the drives, and not at the name of the mount point. Cheers, -- M. Uli Kusterer http://www.zathras.de From mah at jump-ing.de Mon Oct 15 14:29:18 2007 From: mah at jump-ing.de (Markus Hitter) Date: Mon Oct 15 14:29:32 2007 Subject: set_errno missing? In-Reply-To: References: Message-ID: Am 15.10.2007 um 21:08 schrieb Ivan Galic: > currently I want to set it to 0 to make sure that I don't catch any > errors left from other function calls errno = 0; ? Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From mah at jump-ing.de Mon Oct 15 14:58:23 2007 From: mah at jump-ing.de (Markus Hitter) Date: Mon Oct 15 14:58:32 2007 Subject: File Path Tracking In-Reply-To: References: <71132DE1-3694-47CD-8C09-439A8F437D02@highdesertchurch.com> Message-ID: Am 15.10.2007 um 21:17 schrieb Uli Kusterer: > Am 15.10.2007 um 21:10 schrieb Daniel Hazelbaker: >> I have a program that keeps track of files by using the Unix Path >> to the file (as that is what is used to open and work with the >> files when the time comes). > > Check out Aliases, which can be used for this and are reliable. Aliases don't work if you access the same file at the same path while one of the accesses is local while the other is remote, like: Machine 1: /Users/me/MyFile Machine 2: mount_afp machine1:/Users /Users /Users/me/MyFile An Alias created on machine 2 will hang on machine 1. I'm not aware of a reliable solution other than mounting shares at a fixed local path, e.g. by an entry in /etc/fstab. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From daniel at highdesertchurch.com Mon Oct 15 16:26:24 2007 From: daniel at highdesertchurch.com (Daniel Hazelbaker) Date: Mon Oct 15 16:27:53 2007 Subject: File Path Tracking In-Reply-To: References: <71132DE1-3694-47CD-8C09-439A8F437D02@highdesertchurch.com> Message-ID: On Oct 15, 2007, at 2:58 PM, Markus Hitter wrote: > > Am 15.10.2007 um 21:17 schrieb Uli Kusterer: > >> Am 15.10.2007 um 21:10 schrieb Daniel Hazelbaker: >>> I have a program that keeps track of files by using the Unix Path >>> to the file (as that is what is used to open and work with the >>> files when the time comes). >> >> Check out Aliases, which can be used for this and are reliable. > > Aliases don't work if you access the same file at the same path > while one of the accesses is local while the other is remote, like: Okay, well... here is the exact scenario I have: All media files (quicktime movies, still pictures, probably audio at some point, etc.) are stored on the network volume "HDCServer", which is shared from the server "fileserver". What I could potentially have happen is this (psuedo): Machine 1: mount fileserver:HDCServer /Volumes/HDCServer Machine 2: mount fileserver:HDCServer /Volumes/HDCServer Machine 3 (FUS): User 1: mount fileserver:HDCServer /Volumes/HDCServer User 2: mount fileserver:HDCServer /Volumes/HDCServer\ 2 The problem I run into is the final one. When the HDCServer gets mounted to a different "Volumes" path it doesn't know how to find it anymore (to be specific, it gets access denied errors as User 2 doesn't have access to User 1's HDCServer mount). Now all of these "mounts" will be network based, however, I could foresee in the future a use of dual local/network for other libraries. As I understand you, this scenario would work since all are network instead of local. If I try to mix local / network then I will run into issues. Is there a way I can store the "alias data" (i.e. see com.apple.recentitems.plist) and then have the alias "system" translate the alias back into a regular unix path which I can open? In this recent items example all it stores is the alias data, so it seems like if two people have an alias to the same file, one local another via network, and they try to open the same file from the alias in their recent list they would come up with some kind of hanged state, but I have never heard of that happening? It would be nice to have it automatically try to mount the server if it is not, but I can live without that ability if it lets me pick up a "traveling" mount path. > Markus Daniel From mah at jump-ing.de Tue Oct 16 00:43:09 2007 From: mah at jump-ing.de (Markus Hitter) Date: Tue Oct 16 00:43:01 2007 Subject: File Path Tracking In-Reply-To: References: <71132DE1-3694-47CD-8C09-439A8F437D02@highdesertchurch.com> Message-ID: Am 16.10.2007 um 01:26 schrieb Daniel Hazelbaker: > As I understand you, this scenario would work since all are network > instead of local. If I try to mix local / network then I will run > into issues. Right. > Is there a way I can store the "alias data" (i.e. see > com.apple.recentitems.plist) and then have the alias "system" > translate the alias back into a regular unix path which I can open? Like Uli mentioned, the Alias mechanism should include such functionality already. I'm not sure, since I've never used Aliases programmatically. > In this recent items example all it stores is the alias data, so it > seems like if two people have an alias to the same file, one local > another via network, and they try to open the same file from the > alias in their recent list they would come up with some kind of > hanged state, but I have never heard of that happening? Probably, because Apple recommends to work either all local or all network. The kind of setup to put a few Homes on each of the participating computers while mounting them remotely on the other machines is often seen in Unix-only networks but very rarely with Mac OS X. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From leeg at thaesofereode.info Tue Oct 16 01:25:08 2007 From: leeg at thaesofereode.info (Graham J Lee) Date: Tue Oct 16 01:50:51 2007 Subject: File Path Tracking In-Reply-To: References: <71132DE1-3694-47CD-8C09-439A8F437D02@highdesertchurch.com> Message-ID: <64803DCF-373E-4834-8D4F-B0F8F8D8A674@thaesofereode.info> On 16 Oct 2007, at 08:43, Markus Hitter wrote: > >> In this recent items example all it stores is the alias data, so >> it seems like if two people have an alias to the same file, one >> local another via network, and they try to open the same file from >> the alias in their recent list they would come up with some kind >> of hanged state, but I have never heard of that happening? > > Probably, because Apple recommends to work either all local or all > network. The kind of setup to put a few Homes on each of the > participating computers while mounting them remotely on the other > machines is often seen in Unix-only networks but very rarely with > Mac OS X. > I did this when I worked for a University (admin and root had local home directories, everyone else accessed a file server for theirs, which is actually less distributed (and less insane) than the NIS/NFS- style setup you describe) and never found any problems, but then I'm not sure what problems might be expected. I suppose the point is that sharing an alias between a 'local' and 'network' user is not guaranteed to work, but then that rarely if ever happened because [i] no-one logged in at the file server locally and [ii]sharing paths or files is much more intuitive than sharing aliases, because the former are descriptive and the latter is opaque. Cheers, Graham. From mah at jump-ing.de Tue Oct 16 02:23:08 2007 From: mah at jump-ing.de (Markus Hitter) Date: Tue Oct 16 02:23:04 2007 Subject: File Path Tracking In-Reply-To: <64803DCF-373E-4834-8D4F-B0F8F8D8A674@thaesofereode.info> References: <71132DE1-3694-47CD-8C09-439A8F437D02@highdesertchurch.com> <64803DCF-373E-4834-8D4F-B0F8F8D8A674@thaesofereode.info> Message-ID: <4BF2819B-BD13-402E-BA56-3B2E59109C7F@jump-ing.de> Am 16.10.2007 um 10:25 schrieb Graham J Lee: > (admin and root had local home directories, everyone else accessed > a file server for theirs, which is actually less distributed (and > less insane) than the NIS/NFS-style setup you describe) Thousands of Homes on a single server can be pretty hefty and distributing this evenly to all the workstations gives a long list of (auto)mounts, but makes a giant file server obsolete, as well. > I suppose the point is that sharing an alias between a 'local' and > 'network' user is not guaranteed to work, but then that rarely if > ever happened The Dock uses Aliases, for example. As do some of the right side menus, e.g. Classic. The latter stops the Finder from loading if it points to an unresolvable volume. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From leeg at thaesofereode.info Tue Oct 16 02:31:14 2007 From: leeg at thaesofereode.info (Graham J Lee) Date: Tue Oct 16 02:31:23 2007 Subject: File Path Tracking In-Reply-To: <4BF2819B-BD13-402E-BA56-3B2E59109C7F@jump-ing.de> References: <71132DE1-3694-47CD-8C09-439A8F437D02@highdesertchurch.com> <64803DCF-373E-4834-8D4F-B0F8F8D8A674@thaesofereode.info> <4BF2819B-BD13-402E-BA56-3B2E59109C7F@jump-ing.de> Message-ID: On 16 Oct 2007, at 10:23, Markus Hitter wrote: > > Am 16.10.2007 um 10:25 schrieb Graham J Lee: > >> (admin and root had local home directories, everyone else accessed >> a file server for theirs, which is actually less distributed (and >> less insane) than the NIS/NFS-style setup you describe) >> > > Thousands of Homes on a single server can be pretty hefty and > distributing this evenly to all the workstations gives a long list > of (auto)mounts, but makes a giant file server obsolete, as well. > It makes the administration easier though because there are fewer 'important' systems; the workstations are just like heavy Sun Rays. >> I suppose the point is that sharing an alias between a 'local' and >> 'network' user is not guaranteed to work, but then that rarely if >> ever happened > > The Dock uses Aliases, for example. I don't know if it's because the aliases also refer to the file by path or because MCX preferences do some magic rewriting, but that never caused a problem. > As do some of the right side menus, e.g. Classic. The latter stops > the Finder from loading if it points to an unresolvable volume. > Ah, well I had a simple and effective approach to Classic support ;-) Cheers, Graham. From daniel at highdesertchurch.com Tue Oct 16 12:15:49 2007 From: daniel at highdesertchurch.com (Daniel Hazelbaker) Date: Tue Oct 16 12:16:54 2007 Subject: File Path Tracking In-Reply-To: References: <71132DE1-3694-47CD-8C09-439A8F437D02@highdesertchurch.com> Message-ID: <7C9B4BD5-8BE2-4E01-A074-820C0560401D@highdesertchurch.com> Summary: Thanks all for the input. It is not optimal but it sounds like storing the alias data as well as the unix path is my solution. If the unix path does not work (most of the time it will) then attempt to use the alias functions to determine what the new path is. Regards, Daniel On Oct 16, 2007, at 12:43 AM, Markus Hitter wrote: > > Am 16.10.2007 um 01:26 schrieb Daniel Hazelbaker: > >> As I understand you, this scenario would work since all are >> network instead of local. If I try to mix local / network then I >> will run into issues. > > Right. > >> Is there a way I can store the "alias data" (i.e. see >> com.apple.recentitems.plist) and then have the alias "system" >> translate the alias back into a regular unix path which I can open? > > Like Uli mentioned, the Alias mechanism should include such > functionality already. I'm not sure, since I've never used Aliases > programmatically. > >> In this recent items example all it stores is the alias data, so >> it seems like if two people have an alias to the same file, one >> local another via network, and they try to open the same file from >> the alias in their recent list they would come up with some kind >> of hanged state, but I have never heard of that happening? > > Probably, because Apple recommends to work either all local or all > network. The kind of setup to put a few Homes on each of the > participating computers while mounting them remotely on the other > machines is often seen in Unix-only networks but very rarely with > Mac OS X. > > > Markus > > - - - - - - - - - - - - - - - - - - - > Dipl. Ing. Markus Hitter > http://www.jump-ing.de/ > > > > > From daniel at highdesertchurch.com Wed Oct 17 08:19:22 2007 From: daniel at highdesertchurch.com (Daniel Hazelbaker) Date: Wed Oct 17 08:21:56 2007 Subject: Identify monitors Message-ID: Those of you on quartz-dev will have seen a somewhat related post from me recently about multiple monitors. This came up in the same issue. I have a program that (can) renders to multiple displays over multiple video cards. To identify the displays uniquely I had been using the viewport of the display (origin and size). This works fairly well with only 2 displays. I recently moved to a machine with 4 displays and things get a little funky. Displays move, resize, swap positions, and things get all confused if a monitor is unplugged because that just shifts Everything around. Here is my setup: Display 1: DVI connection to Sceptre 22" Display 2: DVI connection to video switcher (shows up as a unique vendor/model) Display 3: VGA connection to video switcher (shows up as a generic VGA device) Display 4: VGA connection to projector (shows up as a generic VGA device, same #s as display 3) I have looked at using the Vendor ID, Model ID & Serial # of the displays, but none of the hooked up devices have serial #'s returned and, as I have seen with display 3 & 4, if I have 2 devices hooked up that are the same then I will get duplicate numbers. Is this my best bet to use the VendorID, ModelID and serial # and then if I have multiple matches use the viewport origin and hope they haven't moved any displays around or is there a better way that I have not found yet? I fear, though, that this is the best way. :/ Daniel From gweston at mac.com Wed Oct 17 14:53:58 2007 From: gweston at mac.com (Gregory Weston) Date: Wed Oct 17 14:54:03 2007 Subject: File Path Tracking In-Reply-To: <20071017190005.E22CF1C421C@forums.omnigroup.com> References: <20071017190005.E22CF1C421C@forums.omnigroup.com> Message-ID: Daniel Hazelbaker wrote: > Summary: Thanks all for the input. It is not optimal but it sounds > like storing the alias data as well as the unix path is my solution. > If the unix path does not work (most of the time it will) then > attempt to use the alias functions to determine what the new path is. Since the default behavior of alias resolution is to check the stored path first, why bother with an explicit path check beforehand? The whole point of the alias mechanism is to robustly track files over extended periods of time. Resolve the alias, and the system will tell you in the process of that resolution whether the file has moved (and thus the alias needs to be resaved for optimal efficiency). Bob's your metaphorical uncle. From mah at jump-ing.de Wed Oct 17 22:58:33 2007 From: mah at jump-ing.de (Markus Hitter) Date: Wed Oct 17 22:58:23 2007 Subject: File Path Tracking In-Reply-To: References: <20071017190005.E22CF1C421C@forums.omnigroup.com> Message-ID: Am 17.10.2007 um 23:53 schrieb Gregory Weston: > Since the default behavior of alias resolution is to check the > stored path first, why bother with an explicit path check beforehand? The default behaviour is to mount the server before checking the path. This works often, but not always. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From brianarthur at nc.rr.com Thu Oct 18 11:47:52 2007 From: brianarthur at nc.rr.com (Anthony B Arthur) Date: Thu Oct 18 11:48:14 2007 Subject: NSArrayController Message-ID: <80D35901-B1E6-415D-A15B-F3824CC2B231@nc.rr.com> My apologies if this has already been answered. I am trying to properly bind an NSTableView to a NSArrayController. The tableView has 3 columns, 2 of which use popup button cells as its data cells. It is these 2 columns that I am having trouble properly binding. The controller has an array of objects set as its content. I have entered keys to this content on the controller in its inspector. Each object in the content array has a list of strings that should display in the popup buttons. I am not using a model, didn't really feel I needed to go through all that. So in IB there are bindings for the column and bindings for the popup cell. It is unclear which of the two I should bind, one or the other or both, and exactly which binding aspects and controller keys I should bind to. Attempts to bind to the popup cell bindings causes errors while binding to the column alone looks better, but the popups are empty. Is there anyone who can offer some explanation. Many Thanks, --Brian From adaniels at peakrecruit.com Thu Oct 18 15:20:56 2007 From: adaniels at peakrecruit.com (adaniels@peakrecruit.com) Date: Thu Oct 18 15:27:41 2007 Subject: Mac Developer needed in Texas Message-ID: <20071018152056.88754f07fd98481561d7b9b6122c8f7c.0b22ac9887.wbe@email.secureserver.net> Mac Developer Required Skills - 2 years of experience coding with Cocoa and C++ on Mac OS X, at least one year professionally - Must be an excellent hands-on implementer with strong object oriented C++ programming skills - Strong analytical, diagnostic and problem-solving skills with ability to generate new ideas and work independently - Must be quick to learn and conquer new technologies and have a strong passion for building cutting-edge Mac applications in a team of OS internals experts - Knowledge of internet protocols such as TCP/IP, HTTP and HTTPS - Familiarity with the x86 and PowerPC architectures including virtual memory, privilege levels and assembly language - Ability to tackle complex software issues such as deadlocks and exceptions using gdb - Cross-platform development experience - Knowledge of OS X internals and/or device driver development - Degree in EE or computer science Please send inquiries to info@peakrecruit.com From edenwaith at mac.com Thu Oct 18 21:31:45 2007 From: edenwaith at mac.com (Chad Armstrong) Date: Thu Oct 18 21:31:51 2007 Subject: Shared User Defaults and NSStepper In-Reply-To: <20071016085054.65FA41C3656@forums.omnigroup.com> References: <20071016085054.65FA41C3656@forums.omnigroup.com> Message-ID: <54277112-7885-4A02-B0A3-DC05A7EEE3A7@mac.com> In my application, I have an NSSlider in the Preference window, which I want to be able to set the Increment Amount for an NSStepper. I'm making use of Shared Defaults bindings, however, it appears that the Increment Amount is not one of the values that is supported by bindings (however, the min value and max values are supported). What would be a good method for the NSStepper to adjust it's Increment Amount value whenever the NSSlider is changed in the Preference window? Should I avoid using the Shared Default bindings in this case and use a notification instead? Or is there a way to programatically bind the NSSlider's value to the NSStepper's Increment Amount value? Regards, Chad From brianarthur at nc.rr.com Fri Oct 19 11:19:38 2007 From: brianarthur at nc.rr.com (Anthony B Arthur) Date: Fri Oct 19 11:20:05 2007 Subject: NSArrayController Message-ID: <172E7628-1773-4AEC-A590-7D6881B706DE@nc.rr.com> I sent this yesterday but did not see it come through..... My apologies if this has already been answered. I am trying to properly bind an NSTableView to a NSArrayController. The tableView has 3 columns, 2 of which use popup button cells as its data cells. It is these 2 columns that I am having trouble properly binding. The controller has an array of objects set as its content. I have entered keys to this content on the controller in its inspector. Each object in the content array has a list of strings that should display in the popup buttons. I am not using a model, didn't really feel I needed to go through all that. So in IB there are bindings for the column and bindings for the popup cell. It is unclear which of the two I should bind, one or the other or both, and exactly which binding aspects and controller keys I should bind to. Attempts to bind to the popup cell bindings causes errors while binding to the column alone looks better, but the popups are empty. Is there anyone who can offer some explanation. Many Thanks, --Brian From dunham at mac.com Sun Oct 21 21:31:39 2007 From: dunham at mac.com (David Dunham) Date: Sun Oct 21 21:31:44 2007 Subject: [CocoaApp isThisTiger] Message-ID: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> I'd like to disable some UI if my Cocoa application is running under Tiger (as opposed to Leopard). Gestalt would work perfectly well, but I wonder what the hard core "no Carbon" Cocoa developers prefer to determine this. Or if AppKit version is preferred. David Dunham A Sharp, LLC Voice/Fax: 206 783 7404 http://a-sharp.com Efficiency is intelligent laziness. From shawnce at gmail.com Mon Oct 22 10:55:13 2007 From: shawnce at gmail.com (Shawn Erickson) Date: Mon Oct 22 10:55:22 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> Message-ID: On 10/21/07, David Dunham wrote: > I'd like to disable some UI if my Cocoa application is running under > Tiger (as opposed to Leopard). Gestalt would work perfectly well, but > I wonder what the hard core "no Carbon" Cocoa developers prefer to > determine this. Or if AppKit version is preferred. Check for the existance/lack of a feature that you need at runtime. Avoid testing for OS version if possible. Need to know more about why you want to disable an aspect of UI on Tiger to give specifics... -Shawn From cmhofman at gmail.com Mon Oct 22 10:55:39 2007 From: cmhofman at gmail.com (Christiaan Hofman) Date: Mon Oct 22 10:55:49 2007 Subject: Shared User Defaults and NSStepper In-Reply-To: <54277112-7885-4A02-B0A3-DC05A7EEE3A7@mac.com> References: <20071016085054.65FA41C3656@forums.omnigroup.com> <54277112-7885-4A02-B0A3-DC05A7EEE3A7@mac.com> Message-ID: Well, as you say, this binding is not available. So you'll have to use old fashioned methods. I don't know if you want the increment to be saved in the prefs, but if you want that, you should certainly bind the slider. Probably the easiest way to handle the stepper is to set the increment programatically in an action for the slider, and of course in awakeFromNib or windowDidLoad. Christiaan On 19 Oct 2007, at 6:31 AM, Chad Armstrong wrote: > In my application, I have an NSSlider in the Preference window, > which I want to be able to set the Increment Amount for an > NSStepper. I'm making use of Shared Defaults bindings, however, it > appears that the Increment Amount is not one of the values that is > supported by bindings (however, the min value and max values are > supported). > > What would be a good method for the NSStepper to adjust it's > Increment Amount value whenever the NSSlider is changed in the > Preference window? Should I avoid using the Shared Default > bindings in this case and use a notification instead? Or is there > a way to programatically bind the NSSlider's value to the > NSStepper's Increment Amount value? > > Regards, > > Chad From fabianschuiki at bluewin.ch Mon Oct 22 10:56:57 2007 From: fabianschuiki at bluewin.ch (Fabian Schuiki) Date: Mon Oct 22 10:57:05 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> Message-ID: <37CBB435-B444-4AF7-A62F-12D5A6C374C7@bluewin.ch> Hi, I'm usign the AppKit Version to get the system version (code was written for Tiger): LSESystemVersion LSECurrentSystemVersion() { switch ((int)floor(NSAppKitVersionNumber)) { case NSAppKitVersionNumber10_0: return LSESystemVersionCheetah; break; case NSAppKitVersionNumber10_1: return LSESystemVersionPuma; break; case NSAppKitVersionNumber10_2: return LSESystemVersionJaguar; break; case NSAppKitVersionNumber10_3: return LSESystemVersionPanther; break; } if ((int)floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_3) return LSESystemVersionTiger; return LSESystemVersionUnknown; } Best, Fabian Fabian Schuiki fabianschuiki@bluewin.ch Am 22.10.2007 um 06:31 schrieb David Dunham: > I'd like to disable some UI if my Cocoa application is running > under Tiger (as opposed to Leopard). Gestalt would work perfectly > well, but I wonder what the hard core "no Carbon" Cocoa developers > prefer to determine this. Or if AppKit version is preferred. > > David Dunham A Sharp, LLC > Voice/Fax: 206 783 7404 http://a-sharp.com > Efficiency is intelligent laziness. > > _______________________________________________ > MacOSX-dev mailing list > MacOSX-dev@omnigroup.com > http://www.omnigroup.com/mailman/listinfo/macosx-dev From cmhofman at gmail.com Mon Oct 22 11:01:08 2007 From: cmhofman at gmail.com (Christiaan Hofman) Date: Mon Oct 22 11:01:23 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> Message-ID: <8023849D-50B8-439A-9E0B-328ABCC04815@gmail.com> I'd say that can be dangerous.A feature (say method) being available does not mean that everything you need is available. What if some input manager or framework happens to add a method precisely with this name? This only works if you check for *every* method you would want to use, which is usually fragile and undoable. I would just check for the appkit version. That is a check that basically guarantees existence of a whole bunch of methods. Christiaan On 22 Oct 2007, at 7:55 PM, Shawn Erickson wrote: > On 10/21/07, David Dunham wrote: >> I'd like to disable some UI if my Cocoa application is running under >> Tiger (as opposed to Leopard). Gestalt would work perfectly well, but >> I wonder what the hard core "no Carbon" Cocoa developers prefer to >> determine this. Or if AppKit version is preferred. > > Check for the existance/lack of a feature that you need at runtime. > Avoid testing for OS version if possible. > > Need to know more about why you want to disable an aspect of UI on > Tiger to give specifics... > > -Shawn From gcerquant at gmail.com Mon Oct 22 11:01:43 2007 From: gcerquant at gmail.com (Guillaume CERQUANT) Date: Mon Oct 22 11:01:57 2007 Subject: Receive CFMessagePortSendRequest notifications Message-ID: <89123191-7A62-4FEC-9014-00CF1AEC53FE@gmail.com> Hello, I found that you can notify the screensaver to re-read the values of ~/Library/com.apple.screensaver.plist with this code: CFMessagePortRef port = CFMessagePortCreateRemote(NULL, CFSTR ("com.apple.loginwindow.notify")); CFMessagePortSendRequest(port, 500, 0, 0, 0, 0, 0); CFRelease(port); This part works as expected: the screensaver read the new settings. I'm now trying to subscribe to the notifications, in case the values change not due to my program and a notification is sent. Eg, if the user change the setting via System Preferences.app, I want to catch the notification sent by System Preferences.app. I tried this: static CFDataRef *consoleMessage(CFMessagePortRef local, SInt32 priority, CFDataRef data, void *info) { fprintf(stderr, "consoleMessage priority = %ld\n", priority); return NULL; } - (id)init { CFMessagePortContext context; context.version = 0; context.info = self; context.retain = 0; context.release = 0; context.copyDescription = 0; CFMessagePortRef port = CFMessagePortCreateLocal(NULL, kConsoleMessagePort, (CFMessagePortCallBack)&consoleMessage, &context, NULL); CFRunLoopSourceRef rls = CFMessagePortCreateRunLoopSource(NULL, port, 0); CFRunLoopAddSource(CFRunLoopGetCurrent(), rls, kCFRunLoopDefaultMode); CFRelease(rls); self = [super init]; return self; } It doesn't work. Here is the log: 2007-10-22 19:19:22.559 SystemUIServer[22311] CFLog (0): CFMessagePort: bootstrap_register(): failed 1103 (0x44f), port = 0x6403, name = 'com.apple.loginwindow.notify' See /usr/include/servers/bootstrap_defs.h for the error codes. 2007-10-22 19:19:22.563 SystemUIServer[22311] CFLog (99): CFMessagePortCreateLocal(): failed to name Mach port (com.apple.loginwindow.notify) From what I understand, the service is already active and can't be open twice. That seems normal, as the port is already open and used to receive the notifications by the screensaver engine (or whatever take care of this). How can I receive the notifications too? I hope I'm being clear about my problem. Let me know if not. Thank you for your time and help. It is appreciated. -- Guillaume Cerquant gcerquant@gmail.com From finlay.dobbie at gmail.com Mon Oct 22 11:26:19 2007 From: finlay.dobbie at gmail.com (Finlay Dobbie) Date: Mon Oct 22 11:26:26 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> Message-ID: On 22/10/2007, David Dunham wrote: > I'd like to disable some UI if my Cocoa application is running under > Tiger (as opposed to Leopard). Gestalt would work perfectly well, but > I wonder what the hard core "no Carbon" Cocoa developers prefer to > determine this. Or if AppKit version is preferred. You can use NSAppKitVersionNumber, but "hard core no Carbon Cocoa developers" need to grow up and stop being babies. -- Finlay From ben at tanjero.com Mon Oct 22 11:17:13 2007 From: ben at tanjero.com (Benjamin Stiglitz) Date: Mon Oct 22 11:26:59 2007 Subject: Receive CFMessagePortSendRequest notifications In-Reply-To: <89123191-7A62-4FEC-9014-00CF1AEC53FE@gmail.com> References: <89123191-7A62-4FEC-9014-00CF1AEC53FE@gmail.com> Message-ID: > I'm now trying to subscribe to the notifications, in case the values > change not due to my program and a notification is sent. > Eg, if the user change the setting via System Preferences.app, I want > to catch the notification sent by System Preferences.app. Unfortunately for you, these aren?t notifications at all; they?re messages sent directly to the port registered with that name. There?s no way to snoop the messages short of code injection. Since anything that changes the settings will update the plist, you might want to watch that instead. Good luck, -Ben From leeg at thaesofereode.info Mon Oct 22 11:33:49 2007 From: leeg at thaesofereode.info (Graham J Lee) Date: Mon Oct 22 11:34:23 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> Message-ID: <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> On 22 Oct 2007, at 05:31, David Dunham wrote: > I'd like to disable some UI if my Cocoa application is running > under Tiger (as opposed to Leopard). Gestalt would work perfectly > well, but I wonder what the hard core "no Carbon" Cocoa developers > prefer to determine this. Or if AppKit version is preferred. """ A better way to get version information on Mac OS X would be to read in the system version information from the file /System/Library/ CoreServices/System Version.plist. """ from the Gestalt documentation. Cheers, Graham. From cmhofman at gmail.com Mon Oct 22 11:34:57 2007 From: cmhofman at gmail.com (Christiaan Hofman) Date: Mon Oct 22 11:35:08 2007 Subject: NSArrayController In-Reply-To: <172E7628-1773-4AEC-A590-7D6881B706DE@nc.rr.com> References: <172E7628-1773-4AEC-A590-7D6881B706DE@nc.rr.com> Message-ID: <283C5AB9-4963-4441-B08C-857B250B2D95@gmail.com> On 19 Oct 2007, at 8:19 PM, Anthony B Arthur wrote: > I sent this yesterday but did not see it come through..... > > My apologies if this has already been answered. I am trying to > properly bind an NSTableView to a NSArrayController. The tableView > has 3 columns, 2 of which use popup button cells as its data > cells. It is these 2 columns that I am having trouble properly > binding. The controller has an array of objects set as its > content. I have entered keys to this content on the controller in > its inspector. Each object in the content array has a list of > strings that should display in the popup buttons. I am not using a > model, didn't really feel I needed to go through all that. So in > IB there are bindings for the column and bindings for the popup > cell. It is unclear which of the two I should bind, one or the > other or both, and exactly which binding aspects and controller > keys I should bind to. Attempts to bind to the popup cell bindings > causes errors while binding to the column alone looks better, but > the popups are empty. Is there anyone who can offer some explanation. > > Many Thanks, > > --Brian > You should bind the column, not the cell. You bind either contentValues, or the triple content + contentObjects + contentValues (in case the displayed values are not the same as the represented objects). You should bind to an array, which could be through the arrangedObjects of some arrayController, or directly to an array key of the controller object (in particular if it is a fixed array). Alternatively, you can bind to an array key of the objects you're displaying. In this case you bind to the same arrayController as the displayed/selected objects (but then these objects of course need to contain this array). This allows you to use varying sets of values in the different popups. But I guess you don't need this complexity. Christiaan From finlay.dobbie at gmail.com Mon Oct 22 15:54:58 2007 From: finlay.dobbie at gmail.com (Finlay Dobbie) Date: Mon Oct 22 15:55:02 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> Message-ID: On 22/10/2007, Graham J Lee wrote: > """ > A better way to get version information on Mac OS X would be to > read in the > system version information from the file /System/Library/ > CoreServices/System > Version.plist. > """ > from the Gestalt documentation. The documentation is wrong: -- Finlay From dunham at mac.com Mon Oct 22 16:22:07 2007 From: dunham at mac.com (David Dunham) Date: Mon Oct 22 16:35:24 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> Message-ID: On 22 Oct 2007, at 10:55, Shawn Erickson wrote: > Check for the existance/lack of a feature that you need at runtime. As in respondsToSelector? Finlay > "hard core no Carbon Cocoa > developers" need to grow up and stop being babies. I agree, but I was curious as to the diametrically opposite approach. Fabian > if ((int)floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_3) > return LSESystemVersionTiger; This doesn't actually work: NSAppKitVersionNumber10_3_5 The Application Kit framework included in Mac OS X v10.3.5 David Dunham Voice/Fax: 206 783 7404 http://www.pensee.com/dunham/ Imagination is more important than knowledge. -- Albert Einstein From dunham at mac.com Mon Oct 22 17:00:45 2007 From: dunham at mac.com (David Dunham) Date: Mon Oct 22 17:00:50 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> Message-ID: <80297E47-8BFA-4F64-AEB3-02D6AE35963D@mac.com> On 22 Oct 2007, at 16:22, David Dunham wrote: > Fabian > >> if ((int)floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_3) >> return LSESystemVersionTiger; > > This doesn't actually work: Whoops, I missed the "floor" there. Probably does work. It does seem odd there's no NSAppKitVersionNumber10_4 in the 10.4u SDK. David Dunham Voice/Fax: 206 783 7404 http://www.pensee.com/dunham/ Imagination is more important than knowledge. -- Albert Einstein From shawnce at gmail.com Mon Oct 22 17:48:23 2007 From: shawnce at gmail.com (Shawn Erickson) Date: Mon Oct 22 17:48:26 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> Message-ID: On 10/22/07, David Dunham wrote: > > On 22 Oct 2007, at 10:55, Shawn Erickson wrote: > > > Check for the existance/lack of a feature that you need at runtime. > > As in respondsToSelector? ...or checking for nil/NULL function pointers or checking for the existence of a class (NSClassFromString(...) != nil), etc. Again hard to be specific without knowing what you need to check for which you haven't yet talked about. If you cannot check for the specific feature then app kit version may make sense but IMHO it is best to check for the specific feature if you can. -Shawn From leeg at thaesofereode.info Mon Oct 22 18:52:19 2007 From: leeg at thaesofereode.info (Graham J Lee) Date: Mon Oct 22 18:52:26 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> Message-ID: On 22 Oct 2007, at 23:54, Finlay Dobbie wrote: > On 22/10/2007, Graham J Lee wrote: >> """ >> A better way to get version information on Mac OS X would be to >> read in the >> system version information from the file /System/Library/ >> CoreServices/System >> Version.plist. >> """ >> from the Gestalt documentation. > > The documentation is wrong: > ...but the original poster wanted to find out whether he was on Tiger, where the aforementioned approach _is_ documented as better. From rosyna at unsanity.com Mon Oct 22 19:00:50 2007 From: rosyna at unsanity.com (Rosyna) Date: Mon Oct 22 19:07:36 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> Message-ID: And the documentation on Tiger for reading that file is wrong. Very wrong. And you can see how wrong it is by every application that broke horribly in 10.4.10 because they didn't use Gestalt() like you're supposed to. Use Gestalt() and be done with it. It is the correct and most robust way to get the system version. Ack, at 10/23/07, Graham J Lee said: >...but the original poster wanted to find out whether he was on >Tiger, where the aforementioned approach _is_ documented as better. -- Sincerely, Rosyna Keller Technical Support/Carbon troll/Always needs a hug Unsanity: Unsane Tools for Insanely Great People It's either this, or imagining Phil Schiller in a thong. From leeg at thaesofereode.info Mon Oct 22 19:07:48 2007 From: leeg at thaesofereode.info (Graham J Lee) Date: Mon Oct 22 19:07:55 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> Message-ID: On 23 Oct 2007, at 03:00, Rosyna wrote: > And the documentation on Tiger for reading that file is wrong. Very > wrong. And you can see how wrong it is by every application that > broke horribly in 10.4.10 because they didn't use Gestalt() like > you're supposed to. On my system, SystemVersion.plist reports 10.4.10 so I don't see how that's distinct from 10.4.10. Cheers, Graham. From rosyna at unsanity.com Mon Oct 22 19:07:52 2007 From: rosyna at unsanity.com (Rosyna) Date: Mon Oct 22 19:07:57 2007 Subject: File Path Tracking In-Reply-To: References: <20071017190005.E22CF1C421C@forums.omnigroup.com> Message-ID: This is not the default behaviour when resolving an alias programmatically. You can choose how you want the alias to be resolved, the order in which alias matches are searched, and whether resolving/matching the alias mounts any file system (disk images, network shares, et cetera). Ack, at 10/18/07, Markus Hitter said: >The default behaviour is to mount the server before checking the >path. This works often, but not always. -- Sincerely, Rosyna Keller Technical Support/Carbon troll/Always needs a hug Unsanity: Unsane Tools for Insanely Great People It's either this, or imagining Phil Schiller in a thong. From rosyna at unsanity.com Mon Oct 22 19:20:05 2007 From: rosyna at unsanity.com (Rosyna) Date: Mon Oct 22 19:20:11 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> Message-ID: That is *exactly* the problem and why you should not parse SystemVersion.plist directly. How do you convert the string 10.4.10 into a numerical value you can compare against? And why are you even bothering to do that when Gestalt() gives you the numerical values correctly, no need to parse. Ack, at 10/23/07, Graham J Lee said: >On 23 Oct 2007, at 03:00, Rosyna wrote: > >>And the documentation on Tiger for reading that file is wrong. Very >>wrong. And you can see how wrong it is by every application that >>broke horribly in 10.4.10 because they didn't use Gestalt() like >>you're supposed to. > >On my system, SystemVersion.plist reports 10.4.10 so I don't see how >that's distinct from 10.4.10. -- Sincerely, Rosyna Keller Technical Support/Carbon troll/Always needs a hug Unsanity: Unsane Tools for Insanely Great People It's either this, or imagining Phil Schiller in a thong. From atomicbird at gmail.com Mon Oct 22 20:01:28 2007 From: atomicbird at gmail.com (Tom Harrington) Date: Mon Oct 22 20:01:34 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> Message-ID: <68162e550710222001i785c8aeam11e15b357278688e@mail.gmail.com> On 10/22/07, Rosyna wrote: > That is *exactly* the problem and why you should not parse > SystemVersion.plist directly. How do you convert the string 10.4.10 > into a numerical value you can compare against? And why are you even > bothering to do that when Gestalt() gives you the numerical values > correctly, no need to parse. Unless you care about 10.4.10 vs. 10.4.9, in which case Gestalt is broken. At least SystemVersion.plist has the right answer. -- Tom Harrington atomicbird@gmail.com AIM: atomicbird1 From rosyna at unsanity.com Mon Oct 22 20:08:11 2007 From: rosyna at unsanity.com (Rosyna) Date: Mon Oct 22 20:08:18 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <68162e550710222001i785c8aeam11e15b357278688e@mail.gmail.com> References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> <68162e550710222001i785c8aeam11e15b357278688e@mail.gmail.com> Message-ID: Please read the documentation for the Gestalt selectors thoroughly. You cannot miss it. It goes into great detail in the header about how to handle 10.4.17. Ack, at 10/22/07, Tom Harrington said: >Unless you care about 10.4.10 vs. 10.4.9, in which case Gestalt is >broken. -- Sincerely, Rosyna Keller Technical Support/Carbon troll/Always needs a hug Unsanity: Unsane Tools for Insanely Great People It's either this, or imagining Phil Schiller in a thong. From rob at menumachine.com Mon Oct 22 20:17:07 2007 From: rob at menumachine.com (Rob Keniger) Date: Mon Oct 22 20:23:53 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> <68162e550710222001i785c8aeam11e15b357278688e@mail.gmail.com> Message-ID: On 23/10/2007, at 1:08 PM, Rosyna wrote: > Please read the documentation for the Gestalt selectors thoroughly. > You cannot miss it. It goes into great detail in the header about > how to handle 10.4.17. To save everyone the pain, here's one way to do it: long majorVersion, minorVersion, bugFixVersion; Gestalt(gestaltSystemVersionMajor, &majorVersion); Gestalt(gestaltSystemVersionMinor, &minorVersion); Gestalt(gestaltSystemVersionBugFix, &bugFixVersion); NSLog(@"Running on Mac OS X %d.%d. %d",majorVersion,minorVersion,bugFixVersion); "Purist" Cocoa programmers should note that this is not a "Carbon" routine, you don't need to include Carbon.h. It's just a (very simple) C API. -- Rob Keniger From finlay.dobbie at gmail.com Mon Oct 22 23:57:08 2007 From: finlay.dobbie at gmail.com (Finlay Dobbie) Date: Mon Oct 22 23:57:13 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> Message-ID: On 23/10/2007, Graham J Lee wrote: > On 22 Oct 2007, at 23:54, Finlay Dobbie wrote: > > > On 22/10/2007, Graham J Lee wrote: > >> """ > >> A better way to get version information on Mac OS X would be to > >> read in the > >> system version information from the file /System/Library/ > >> CoreServices/System > >> Version.plist. > >> """ > >> from the Gestalt documentation. > > > > The documentation is wrong: > > > > ...but the original poster wanted to find out whether he was on > Tiger, where the aforementioned approach _is_ documented as better. Yes, but the documentation is wrong. The issue is not that something has changed on Leopard which means that parsing SystemVersion.plist is no longer "a better approach", but rather that the documentation on Tiger is incorrect. The documentation has been corrected in Leopard. Parsing SystemVersion.plist is probably more lines of code, and considered to be relying on an implementation detail. Just use Gestalt. -- Finlay From cmhofman at gmail.com Tue Oct 23 02:15:57 2007 From: cmhofman at gmail.com (Christiaan Hofman) Date: Tue Oct 23 02:16:06 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <80297E47-8BFA-4F64-AEB3-02D6AE35963D@mac.com> References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <80297E47-8BFA-4F64-AEB3-02D6AE35963D@mac.com> Message-ID: <7BD207E7-D60D-4C63-A7C0-7837EAFC3E1F@gmail.com> On 23 Oct 2007, at 2:00 AM, David Dunham wrote: > On 22 Oct 2007, at 16:22, David Dunham wrote: > >> Fabian >> >>> if ((int)floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_3) >>> return LSESystemVersionTiger; >> >> This doesn't actually work: > > Whoops, I missed the "floor" there. Probably does work. > > It does seem odd there's no NSAppKitVersionNumber10_4 in the 10.4u > SDK. > > David Dunham > Voice/Fax: 206 783 7404 http://www.pensee.com/dunham/ > Imagination is more important than knowledge. -- Albert Einstein That should be in the main System version of NSApplication.h on Leopard. Certainly not in the 10.4u SDK, because that SDK is available on Tiger, and Tiger doesn't (officially) know it's last AppKit version number yet. Christiaan From finlay.dobbie at gmail.com Tue Oct 23 04:32:11 2007 From: finlay.dobbie at gmail.com (Finlay Dobbie) Date: Tue Oct 23 04:32:17 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <7BD207E7-D60D-4C63-A7C0-7837EAFC3E1F@gmail.com> References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <80297E47-8BFA-4F64-AEB3-02D6AE35963D@mac.com> <7BD207E7-D60D-4C63-A7C0-7837EAFC3E1F@gmail.com> Message-ID: On 23/10/2007, Christiaan Hofman wrote: > That should be in the main System version of NSApplication.h on > Leopard. Certainly not in the 10.4u SDK, because that SDK is > available on Tiger, and Tiger doesn't (officially) know it's last > AppKit version number yet. NSAppKitVersionNumber10_4 would correspond to the AppKit version number of 10.4.0, surely? -- Finlay From finlay.dobbie at gmail.com Tue Oct 23 04:35:51 2007 From: finlay.dobbie at gmail.com (Finlay Dobbie) Date: Tue Oct 23 04:35:56 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <80297E47-8BFA-4F64-AEB3-02D6AE35963D@mac.com> <7BD207E7-D60D-4C63-A7C0-7837EAFC3E1F@gmail.com> Message-ID: On 23/10/2007, Finlay Dobbie wrote: > On 23/10/2007, Christiaan Hofman wrote: > > That should be in the main System version of NSApplication.h on > > Leopard. Certainly not in the 10.4u SDK, because that SDK is > > available on Tiger, and Tiger doesn't (officially) know it's last > > AppKit version number yet. > > NSAppKitVersionNumber10_4 would correspond to the AppKit version > number of 10.4.0, surely? And just for completeness, that is 824. #ifndef NSAppKitVersionNumber10_4 #define NSAppKitVersionNumber10_4 824 #endif When Leopard comes out, if NSAppKitVersionNumber10_5 is not defined, you will obviously be able to use the same trick (just write a one line tool to print out the actual value of NSAppKitVersionNumber in the GM). -- Finlay From cmhofman at gmail.com Tue Oct 23 04:54:41 2007 From: cmhofman at gmail.com (Christiaan Hofman) Date: Tue Oct 23 04:54:47 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <80297E47-8BFA-4F64-AEB3-02D6AE35963D@mac.com> <7BD207E7-D60D-4C63-A7C0-7837EAFC3E1F@gmail.com> Message-ID: <2EDB0089-C148-448A-875B-3BC3DDC96A85@gmail.com> On 23 Oct 2007, at 1:35 PM, Finlay Dobbie wrote: > On 23/10/2007, Finlay Dobbie wrote: >> On 23/10/2007, Christiaan Hofman wrote: >>> That should be in the main System version of NSApplication.h on >>> Leopard. Certainly not in the 10.4u SDK, because that SDK is >>> available on Tiger, and Tiger doesn't (officially) know it's last >>> AppKit version number yet. >> >> NSAppKitVersionNumber10_4 would correspond to the AppKit version >> number of 10.4.0, surely? > Sorry, you're right. But though this might not be the reason then, it *is* a fact that NSAppKitVersionNumber10_4 is not defined on Tiger, but only in Leopard (and later) Just as NSAppKitVersionNumber10_3 was only defined on Tiger. I guess the idea is that an app developed on Tiger should not try to use Leopard features, so why should it care to check for Leopard? Christiaan > And just for completeness, that is 824. > > #ifndef NSAppKitVersionNumber10_4 > #define NSAppKitVersionNumber10_4 824 > #endif > > When Leopard comes out, if NSAppKitVersionNumber10_5 is not defined, > you will obviously be able to use the same trick (just write a one > line tool to print out the actual value of NSAppKitVersionNumber in > the GM). > > -- Finlay From alastair at alastairs-place.net Tue Oct 23 06:09:40 2007 From: alastair at alastairs-place.net (Alastair Houghton) Date: Tue Oct 23 06:09:47 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> Message-ID: On 23 Oct 2007, at 03:00, Rosyna wrote: > And the documentation on Tiger for reading that file is wrong. Very > wrong. And you can see how wrong it is by every application that > broke horribly in 10.4.10 because they didn't use Gestalt() like > you're supposed to. > > Use Gestalt() and be done with it. It is the correct and most > robust way to get the system version. Though whichever way you do it, it's possible to screw up if you get your comparisons wrong. It slightly easier to mess up if you're trying to scan a version string from a file, of course, but that doesn't mean you can't do it properly. I do note though that one of Apple's guys said that reading that file was wrong and that we should use Gestalt. On 22 Oct 2007, at 19:26, Finlay Dobbie wrote: > You can use NSAppKitVersionNumber, but "hard core no Carbon Cocoa > developers" need to grow up and stop being babies. Speaking as someone who would rather avoid Carbon where possible (which is not quite the same thing, I must emphasise), I find that the You-Should-Use-Carbon-Because-Its-Better camp are much more vociferous than the Hard-Core-No-Carbon camp (which is not surprising because I'm not actually convinced that the latter exists). And given that the "debate" is between people who do exist and people who do not, it's frankly rather boring and not a little preachy. Any sensible/pragmatic developer---and I think that's most of us--- will use a Carbon API *if* they know about it and if it makes their life easier or provides a better user experience. Developers who have a background in Mac OS development prior to OS X may be more inclined to use Carbon APIs where they exist; developers with other backgrounds (UNIX, for instance) may be less inclined to use them. And people writing cross-platform code may want to avoid them completely (just as they may wish to avoid Win32 APIs on Windows wherever possible). All for valid reasons. As for the specific case of wanting to enable/disable things on a per- system basis, it's much better to check for features rather than versions. That way you won't annoy users if (for instance) Apple back-ports something from 10.5 to 10.4.11, and you don't have any opportunity to stuff up when doing version number checks. Yes, there is a small risk that something not written by you or Apple might add its own methods/classes/functions with the same names, but if they're doing that, then their code will break on the new system anyway (unless the methods/classes happen to be equivalent, in which case who cares anyway?) Kind regards, Alastair. -- http://alastairs-place.net From finlay.dobbie at gmail.com Tue Oct 23 06:52:04 2007 From: finlay.dobbie at gmail.com (Finlay Dobbie) Date: Tue Oct 23 06:52:09 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> Message-ID: On 23/10/2007, Alastair Houghton wrote: > > Use Gestalt() and be done with it. It is the correct and most > > robust way to get the system version. > > Though whichever way you do it, it's possible to screw up if you get > your comparisons wrong. It slightly easier to mess up if you're > trying to scan a version string from a file, of course, but that > doesn't mean you can't do it properly. I do note though that one of > Apple's guys said that reading that file was wrong and that we should > use Gestalt. The file is an implementation detail. Don't rely on it. The only public defined interface to the values defined in the file is through Gestalt. There are SPI in CoreFoundation, but they don't really buy you anything over using Gestalt. > On 22 Oct 2007, at 19:26, Finlay Dobbie wrote: > > > You can use NSAppKitVersionNumber, but "hard core no Carbon Cocoa > > developers" need to grow up and stop being babies. > > Speaking as someone who would rather avoid Carbon where possible > (which is not quite the same thing, I must emphasise), I find that > the You-Should-Use-Carbon-Because-Its-Better camp are much more > vociferous than the Hard-Core-No-Carbon camp (which is not surprising > because I'm not actually convinced that the latter exists). And > given that the "debate" is between people who do exist and people who > do not, it's frankly rather boring and not a little preachy. Your experience does not mesh with mine. > Any sensible/pragmatic developer---and I think that's most of us--- > will use a Carbon API *if* they know about it and if it makes their > life easier or provides a better user experience. So, again, use Gestalt. It's the best tool for the job. Whether it's Carbon or Cocoa is irrelevant. -- Finlay From alastair at alastairs-place.net Tue Oct 23 08:24:20 2007 From: alastair at alastairs-place.net (Alastair Houghton) Date: Tue Oct 23 08:24:27 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> Message-ID: <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> On 23 Oct 2007, at 14:52, Finlay Dobbie wrote: > On 23/10/2007, Alastair Houghton wrote: >>> Use Gestalt() and be done with it. It is the correct and most >>> robust way to get the system version. >> >> Though whichever way you do it, it's possible to screw up if you get >> your comparisons wrong. It slightly easier to mess up if you're >> trying to scan a version string from a file, of course, but that >> doesn't mean you can't do it properly. I do note though that one of >> Apple's guys said that reading that file was wrong and that we should >> use Gestalt. > > The file is an implementation detail. Don't rely on it. My point was that Rosyna was implying that the reason Gestalt() was "right" and reading the file was "wrong" was that people messed up reading the file. But that's not true (sure, it's true that people stuffed up reading it, but that doesn't make Gestalt() "right" and reading the file "wrong"). The reason Gestalt() is the best way is that Apple said so. And in either case, you can still do the comparison wrong. A common mistake is to do this: if (majorVersion >= 10 && minorVersion >= 4 && bugFixVersion >= 6) { // 10.4.6 and above <---- WRONG! } because of course the last test will fail for 10.5.0 (and the middle one, for 11.0.0). Gestalt() doesn't save you from that kind of stupidity. And *even after all that*, there are one or two reasons you might want to use the file anyway; for instance, if you need the build number, or if you need to identify the version of Mac OS X on a disk that you didn't boot from. And it *isn't* an "implementation detail". It's documented all over the place in Tiger, including in the manual page for the "sw_vers" tool, which is yet another way to get this information. As for Leopard, well you can look for yourself I suspect. >> Any sensible/pragmatic developer---and I think that's most of us--- >> will use a Carbon API *if* they know about it and if it makes their >> life easier or provides a better user experience. > > So, again, use Gestalt. It's the best tool for the job. Whether > it's Carbon or Cocoa is irrelevant. **I didn't say you shouldn't use Gestalt**, though I will say (now that you've said that) that it depends on what you're trying to accomplish. It might be better in some instances to use uname() instead of Gestalt(). Or to check the AppKit version number. Or indeed to do something else entirely. The decision should be made on the basis of the information you actually want. Checking the system version to see whether you can call a QuickTime API, for instance, would be a mistake. But such things have happened, *over and over*, on all the platforms I've worked on. The best bet is always to test for features, not versions, because it's difficult to screw that up and it allows for the possibility that things might be back-ported in future. Kind regards, Alastair. -- http://alastairs-place.net From finlay.dobbie at gmail.com Tue Oct 23 08:30:28 2007 From: finlay.dobbie at gmail.com (Finlay Dobbie) Date: Tue Oct 23 08:30:33 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> Message-ID: On 23/10/2007, Alastair Houghton wrote: > It's documented all over the place in Tiger, including in > the manual page for the "sw_vers" tool, which is yet another way to > get this information. You shouldn't rely on that either: -- Finlay From alastair at alastairs-place.net Tue Oct 23 08:53:40 2007 From: alastair at alastairs-place.net (Alastair Houghton) Date: Tue Oct 23 08:53:47 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> Message-ID: <5C93BB26-BA21-4D2D-A9AA-CF0C0161C6E6@alastairs-place.net> On 23 Oct 2007, at 16:30, Finlay Dobbie wrote: > On 23/10/2007, Alastair Houghton wrote: >> It's documented all over the place in Tiger, including in >> the manual page for the "sw_vers" tool, which is yet another way to >> get this information. > > You shouldn't rely on that either: > Yes, I remember that thread (or at least something similar that made its way to Cocoa-dev). In a number of important cases, that thread is wrong. Yes, I know, prior to Leopard, some things might not conform properly to the POSIX spec., so there may be some changes as a result. But even given that caveat I can think of at least a couple of cases where it is *overwhelmingly* preferable to parse rather than trying to make the same API calls as the tool in question. Not to mention the fact that I didn't suggest parsing the output of sw_vers. I was merely pointing out that the manual page documents the presence of the plist file that you claimed is an "implementation detail". Kind regards, Alastair. -- http://alastairs-place.net From finlay.dobbie at gmail.com Tue Oct 23 09:39:49 2007 From: finlay.dobbie at gmail.com (Finlay Dobbie) Date: Tue Oct 23 09:39:55 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <5C93BB26-BA21-4D2D-A9AA-CF0C0161C6E6@alastairs-place.net> References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> <5C93BB26-BA21-4D2D-A9AA-CF0C0161C6E6@alastairs-place.net> Message-ID: On 23/10/2007, Alastair Houghton wrote: > Not to mention the fact that I didn't suggest parsing the output of > sw_vers. I was merely pointing out that the manual page documents > the presence of the plist file that you claimed is an "implementation > detail". It's not my claim, I'm just reiterating what I have been told by the Apple engineers responsible. The documentation may well be wrong. -- Finlay From rosyna at unsanity.com Tue Oct 23 09:49:43 2007 From: rosyna at unsanity.com (Rosyna) Date: Tue Oct 23 09:49:49 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> Message-ID: The manual page for sw_vers doesn't document it, it merely lists it. And note that it lists two files. Both files may not exist on most systems. Also, sw_vers has this fun little bug that may cause it to output complete garbage on some system configurations. Ack, at 10/23/07, Alastair Houghton said: > It's documented all over the place in Tiger, including in the >manual page for the "sw_vers" tool, which is yet another way to get >this information. -- Sincerely, Rosyna Keller Technical Support/Carbon troll/Always needs a hug Unsanity: Unsane Tools for Insanely Great People It's either this, or imagining Phil Schiller in a thong. From alastair at alastairs-place.net Tue Oct 23 10:15:48 2007 From: alastair at alastairs-place.net (Alastair Houghton) Date: Tue Oct 23 10:15:53 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> Message-ID: On 23 Oct 2007, at 17:49, Rosyna wrote: > The manual page for sw_vers doesn't document it, it merely lists it. Which documents its presence. Maybe not its contents, but certainly its presence. > And note that it lists two files. Both files may not exist on most > systems. That's true. ServerVersion.plist only exists on Mac OS X Server. SystemVersion.plist exists on both though. > Also, sw_vers has this fun little bug that may cause it to output > complete garbage on some system configurations. Nice. My point still stands though. The presence of this file is documented. In Tiger, the fact that you could use it is documented (in the docs for Gestalt(), no less). It isn't something that Apple can freely remove without side effects, because they have made its existence public and have, at one point, actively advocated using it. Plus Gestalt() doesn't help you in all cases where this file might. So, sure, you should use Gestalt() if that's what you need. But before stating categorically that Gestalt() is the One True Way, it's worth realising that not everybody's needs are the same and sometimes that means doing something different. Kind regards, Alastair. -- http://alastairs-place.net From finlay.dobbie at gmail.com Tue Oct 23 10:25:28 2007 From: finlay.dobbie at gmail.com (Finlay Dobbie) Date: Tue Oct 23 10:25:35 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> Message-ID: On 23/10/2007, Alastair Houghton wrote: > Plus Gestalt() doesn't help you in all cases where this file might. Would you care to elaborate on that? > So, sure, you should use Gestalt() if that's what you need. But > before stating categorically that Gestalt() is the One True Way, it's > worth realising that not everybody's needs are the same and sometimes > that means doing something different. Perhaps where "something different" is not "determining what version of Mac OS X we're running on", but then we were never discussing that. Gestalt is the best tool for this job. -- Finlay From gweston at mac.com Tue Oct 23 15:21:54 2007 From: gweston at mac.com (Gregory Weston) Date: Tue Oct 23 15:22:01 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <20071023190006.41A8F1C6DC1@forums.omnigroup.com> References: <20071023190006.41A8F1C6DC1@forums.omnigroup.com> Message-ID: Alastair Houghton wrote: > The best bet is always to test for features, not versions, because > it's difficult to screw that up and it allows for the possibility > that things might be back-ported in future. Or removed. Or made optional. From scott at cocoadoc.com Tue Oct 23 16:49:10 2007 From: scott at cocoadoc.com (Scott Anguish) Date: Tue Oct 23 16:49:15 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> <5C93BB26-BA21-4D2D-A9AA-CF0C0161C6E6@alastairs-place.net> Message-ID: someone should file a bug. On Oct 23, 2007, at 12:39 PM, Finlay Dobbie wrote: > It's not my claim, I'm just reiterating what I have been told by the > Apple engineers responsible. The documentation may well be wrong. From edenwaith at mac.com Tue Oct 23 20:33:16 2007 From: edenwaith at mac.com (Chad Armstrong) Date: Tue Oct 23 20:33:22 2007 Subject: Auto-resizing NSTextField In-Reply-To: <20071023190006.79A9F1C6DC4@forums.omnigroup.com> References: <20071023190006.79A9F1C6DC4@forums.omnigroup.com> Message-ID: <47816F26-64FD-400C-A64C-85DB4561F4AB@mac.com> Hello: I'm trying to subclass an NSTextField, so when the data is loaded into it, the field resizes (vertically) so all of the data loads properly. I've found this bit of code and have been using it as an example: http://www.cocoadev.com/index.pl?CCDGrowingTextField I implemented my own version of this code, and when I try to tell the NSTextField to resize, it gets to the method, but it doesn't react. What I'm also finding, is that it isn't even setting the string any longer! So, this line used to work when the text field was a standard NSTextField. [myTextField setStringValue: myString]; Now, after I subclassed the text field, it does not even seem to respond at all. Doesn't set the text, doesn't resize. Any tips on what I'm missing or doing wrong? Regards, Chad From alastair at alastairs-place.net Wed Oct 24 03:07:39 2007 From: alastair at alastairs-place.net (Alastair Houghton) Date: Wed Oct 24 03:07:45 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <4E7C9B15-B023-4674-98FE-BB1CA7B2416E@thaesofereode.info> <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> Message-ID: <8B943D64-76F6-4B21-B2B0-0A0C1B430A8B@alastairs-place.net> On 23 Oct 2007, at 18:25, Finlay Dobbie wrote: > On 23/10/2007, Alastair Houghton wrote: >> Plus Gestalt() doesn't help you in all cases where this file might. > > Would you care to elaborate on that? I already did. Gestalt() can't tell you the build number (and sometimes there are different versions of Mac OS X with the same major/minor/bugfix... it commonly happens when new hardware is released, for example). And it only tells you about the *running* system; if, for instance, you need to identify a build of Mac OS X that's on some other disk, you can't ask Gestalt() for that information. >> So, sure, you should use Gestalt() if that's what you need. But >> before stating categorically that Gestalt() is the One True Way, it's >> worth realising that not everybody's needs are the same and sometimes >> that means doing something different. > > Perhaps where "something different" is not "determining what version > of Mac OS X we're running on", but then we were never discussing that. That's not strictly true. It had entered the discussion on more than one occasion, including (I think) in every post I've made on the topic, as well as some from some of the other contributors. IMO, checking the Mac OS X version is normally the wrong thing to do. It may sometimes be a necessary evil, but usually there are better ways to get things done. Kind regards, Alastair. -- http://alastairs-place.net From bill at cheeseman.name Wed Oct 24 03:39:22 2007 From: bill at cheeseman.name (Bill Cheeseman) Date: Wed Oct 24 03:51:20 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <8B943D64-76F6-4B21-B2B0-0A0C1B430A8B@alastairs-place.net> Message-ID: on 2007-10-24 6:07 AM, Alastair Houghton at alastair@alastairs-place.net wrote: > IMO, checking the Mac OS X version is normally the wrong thing to > do. It may sometimes be a necessary evil, but usually there are > better ways to get things done. I think that statement is too general. It's true as to specific, individual features, but not when the entire product is aimed at technology introduced in a particular version of Mac OS X. One of my commercial products went through major revisions for Tiger, adding many new features based on techniques that were introduced in Tiger. My other commercial product was written for Tiger, and some of its core features require techniques introduced in Tiger. I didn't have the time required to make sure every feature either worked as expected or was blocked in Panther and older, and that wouldn't have made any sense for one of them anyway because it was designed for Tiger-specific technology. I decided to make both products require Tiger or newer. Code testing for Tiger was therefore necessary. (I used the Gestalt selectors and some nice code that is floating around on the lists to make sure the test works correctly all the way pack to Jaguar (or Cheetah?). I'll be doing the same thing for Leopard. -- Bill Cheeseman - bill@cheeseman.name Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.com From mah at jump-ing.de Wed Oct 24 04:21:28 2007 From: mah at jump-ing.de (Markus Hitter) Date: Wed Oct 24 04:21:41 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: Message-ID: <6A3903D2-65AE-4270-9372-FAD63D99B604@jump-ing.de> Am 24.10.2007 um 12:39 schrieb Bill Cheeseman: > Code testing for Tiger was therefore necessary. Why do you require to hack around such tests if one of your users wants to test your app in Panther? The user always knows best what (s) he wants. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From bill at cheeseman.name Wed Oct 24 05:09:30 2007 From: bill at cheeseman.name (Bill Cheeseman) Date: Wed Oct 24 05:10:01 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <6A3903D2-65AE-4270-9372-FAD63D99B604@jump-ing.de> Message-ID: on 2007-10-24 7:21 AM, Markus Hitter at mah@jump-ing.de wrote: > Am 24.10.2007 um 12:39 schrieb Bill Cheeseman: > >> Code testing for Tiger was therefore necessary. > > Why do you require to hack around such tests if one of your users > wants to test your app in Panther? The user always knows best what (s) > he wants. One of my apps functions incompletely under Panther, and the other doesn't function at all under Panther. I don't think it would be smart to frustrate my customers by forcing them to waste their time finding that out for themselves. By testing for Tiger, I am able to tell the user nicely at the outset that the product isn't designed for Panther. The user may know what he wants, but I know best what my products actually do. As the developer of the products, I feel an obligation to inform the user what they do and what they don't do. -- Bill Cheeseman - bill@cheeseman.name Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.com From idiotsavant2005 at gmail.com Wed Oct 24 07:29:29 2007 From: idiotsavant2005 at gmail.com (I. Savant) Date: Wed Oct 24 07:29:33 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <6A3903D2-65AE-4270-9372-FAD63D99B604@jump-ing.de> Message-ID: > The user may know what he wants, but I know best what my products actually > do. As the developer of the products, I feel an obligation to inform the > user what they do and what they don't do. Perfectly salient point. You can paste this fact (minimum requirements) all over the download site, all over the packaging (if there is any) and all through the manuals, but many users don't bother reading that, they just download and (try to) run it. It's quite often that users will download some freeware app I have floating around out there, ignoring the system requirements (OS X 10.4 or above). They then write angry missives about how they can't run the (OS X only) app on their Windows PC. Of course that's an extreme case (how would you notify them in the app if the app won't even launch), but it illustrates an important point: sometimes users don't bother reading things. Sometimes that sentence is more accurate if you replace 'sometimes' with 'most times'. Who the hell cares if the user "knows he wants to run the app on 'x' system" ... if he can't, he can't. "Them's the breaks," as the horribly broken phrase goes. ;-) -- I.S. From finlay.dobbie at gmail.com Wed Oct 24 11:08:12 2007 From: finlay.dobbie at gmail.com (Finlay Dobbie) Date: Wed Oct 24 11:08:21 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <8B943D64-76F6-4B21-B2B0-0A0C1B430A8B@alastairs-place.net> References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> <8B943D64-76F6-4B21-B2B0-0A0C1B430A8B@alastairs-place.net> Message-ID: You really shouldn't need to know the build number for any purpose, except potentially for reporting. Edge cases do not an argument make :) -- Finlay On 24/10/2007, Alastair Houghton wrote: > On 23 Oct 2007, at 18:25, Finlay Dobbie wrote: > > > On 23/10/2007, Alastair Houghton wrote: > >> Plus Gestalt() doesn't help you in all cases where this file might. > > > > Would you care to elaborate on that? > > I already did. > > Gestalt() can't tell you the build number (and sometimes there are > different versions of Mac OS X with the same major/minor/bugfix... it > commonly happens when new hardware is released, for example). And it > only tells you about the *running* system; if, for instance, you need > to identify a build of Mac OS X that's on some other disk, you can't > ask Gestalt() for that information. > > >> So, sure, you should use Gestalt() if that's what you need. But > >> before stating categorically that Gestalt() is the One True Way, it's > >> worth realising that not everybody's needs are the same and sometimes > >> that means doing something different. > > > > Perhaps where "something different" is not "determining what version > > of Mac OS X we're running on", but then we were never discussing that. > > That's not strictly true. It had entered the discussion on more than > one occasion, including (I think) in every post I've made on the > topic, as well as some from some of the other contributors. > > IMO, checking the Mac OS X version is normally the wrong thing to > do. It may sometimes be a necessary evil, but usually there are > better ways to get things done. > > Kind regards, > > Alastair. > > -- > http://alastairs-place.net > > _______________________________________________ > MacOSX-dev mailing list > MacOSX-dev@omnigroup.com > http://www.omnigroup.com/mailman/listinfo/macosx-dev > From alastair at alastairs-place.net Wed Oct 24 12:02:14 2007 From: alastair at alastairs-place.net (Alastair Houghton) Date: Wed Oct 24 12:02:23 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> <8B943D64-76F6-4B21-B2B0-0A0C1B430A8B@alastairs-place.net> Message-ID: <56C9ABBE-C134-438E-954D-E8CC22438CE8@alastairs-place.net> On 24 Oct 2007, at 19:08, Finlay Dobbie wrote: > You really shouldn't need to know the build number for any purpose, > except potentially for reporting. Edge cases do not an argument make > :) Edge cases may not make an argument, but they do make it less than black and white. Besides which, at every turn, you seem to be under the impression that I'm arguing *against* using Gestalt(). I have not, and I am not. Using Gestalt() *is* the best way to get the system version number (assuming that's really what you need). But that doesn't mean that there aren't circumstances where the file is better---or even the *only* way to obtain the information. Kind regards, Alastair. -- http://alastairs-place.net From kusterer at gmail.com Wed Oct 24 17:50:52 2007 From: kusterer at gmail.com (Uli Kusterer) Date: Wed Oct 24 17:51:00 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <6A3903D2-65AE-4270-9372-FAD63D99B604@jump-ing.de> References: <6A3903D2-65AE-4270-9372-FAD63D99B604@jump-ing.de> Message-ID: <86236D2A-84DA-40A9-9276-C3B6C53D0835@gmail.com> Am 24.10.2007 um 13:21 schrieb Markus Hitter: > Am 24.10.2007 um 12:39 schrieb Bill Cheeseman: >> Code testing for Tiger was therefore necessary. > > Why do you require to hack around such tests if one of your users > wants to test your app in Panther? The user always knows best what > (s)he wants. Definitely not. Many user do not read manuals and system requirements, or don't keep the manual and box around, and then just try to run the application to see if it works. If you know your app will seem to work fine but crash on the user and take their data with them (not arbitrary data, but the current session), it's IMHO the right thing to do to tell your users that the app wasn't intended to work on this OS. Whether you actually let the user proceed after that depends on who your users are, why your app may be limited to this particular OS version and more. But it is simply a bad user experience to have your app crash if you can make it put up a warning instead. Cheers, -- M. Uli Kusterer http://www.zathras.de From kusterer at gmail.com Wed Oct 24 17:55:59 2007 From: kusterer at gmail.com (Uli Kusterer) Date: Wed Oct 24 17:56:11 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> <8B943D64-76F6-4B21-B2B0-0A0C1B430A8B@alastairs-place.net> Message-ID: Am 24.10.2007 um 20:08 schrieb Finlay Dobbie: > You really shouldn't need to know the build number for any purpose, > except potentially for reporting. Edge cases do not an argument make > :) This sounds like you never ran into the two differing 10.4.10 builds. Apple shoved out a second release due to that sound issue with the former. They also provided an upgrade to turn the broken build into the fixed version. But the broken-then-fixed build has a different build number (and some different bugs) than the fixed-from- the-start second revision. The least of our troubles was that, since the build numbers differed, Xcode wouldn't let us distribute builds between these two versions ... Cheers, -- M. Uli Kusterer http://www.zathras.de From rosyna at unsanity.com Wed Oct 24 23:27:34 2007 From: rosyna at unsanity.com (Rosyna) Date: Wed Oct 24 23:27:49 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> <8B943D64-76F6-4B21-B2B0-0A0C1B430A8B@alastairs-place.net> Message-ID: Which is actually a good example of why you shouldn't use build numbers and the borked behaviours you can get if you do... But Xcode has a lot of examples of borked behaviours (see MAC_OS_X_VERSION_ACTUAL). Ack, at 10/25/07, Uli Kusterer said: > The least of our troubles was that, since the build numbers >differed, Xcode wouldn't let us distribute builds between these two >versions ... -- Sincerely, Rosyna Keller Technical Support/Carbon troll/Always needs a hug Unsanity: Unsane Tools for Insanely Great People It's either this, or imagining Phil Schiller in a thong. From finlay.dobbie at gmail.com Thu Oct 25 01:18:08 2007 From: finlay.dobbie at gmail.com (Finlay Dobbie) Date: Thu Oct 25 01:18:11 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> <8B943D64-76F6-4B21-B2B0-0A0C1B430A8B@alastairs-place.net> Message-ID: On 25/10/2007, Uli Kusterer wrote: > Am 24.10.2007 um 20:08 schrieb Finlay Dobbie: > > You really shouldn't need to know the build number for any purpose, > > except potentially for reporting. Edge cases do not an argument make > > :) > > This sounds like you never ran into the two differing 10.4.10 > builds. Apple shoved out a second release due to that sound issue > with the former. They also provided an upgrade to turn the broken > build into the fixed version. But the broken-then-fixed build has a > different build number (and some different bugs) than the fixed-from- > the-start second revision. Does your app change behaviour based on whether the sound is broken or not? -- Finlay From kusterer at gmail.com Thu Oct 25 02:06:06 2007 From: kusterer at gmail.com (Uli Kusterer) Date: Thu Oct 25 02:06:16 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <7715FF8D-6350-44BF-BCF0-671A3F644189@mac.com> <3E8C80E7-84C1-4CF1-8450-90093CF4C6BF@alastairs-place.net> <8B943D64-76F6-4B21-B2B0-0A0C1B430A8B@alastairs-place.net> Message-ID: <884E10BC-820D-42ED-AC47-4C2D174E6455@gmail.com> Am 25.10.2007 um 10:18 schrieb Finlay Dobbie: > On 25/10/2007, Uli Kusterer wrote: >> Am 24.10.2007 um 20:08 schrieb Finlay Dobbie: >>> You really shouldn't need to know the build number for any purpose, >>> except potentially for reporting. Edge cases do not an argument make >>> :) >> >> This sounds like you never ran into the two differing 10.4.10 >> builds. Apple shoved out a second release due to that sound issue >> with the former. They also provided an upgrade to turn the broken >> build into the fixed version. But the broken-then-fixed build has a >> different build number (and some different bugs) than the fixed-from- >> the-start second revision. > > Does your app change behaviour based on whether the sound is broken > or not? No. We expect our users to install the latest system updates, which fix this issue. However, the two different fixed versions had other bugs around which we had to work. We do change behavior when running on a system version that has those bugs, though. Cheers, -- M. Uli Kusterer http://www.zathras.de From mah at jump-ing.de Thu Oct 25 02:52:45 2007 From: mah at jump-ing.de (Markus Hitter) Date: Thu Oct 25 02:52:55 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <86236D2A-84DA-40A9-9276-C3B6C53D0835@gmail.com> References: <6A3903D2-65AE-4270-9372-FAD63D99B604@jump-ing.de> <86236D2A-84DA-40A9-9276-C3B6C53D0835@gmail.com> Message-ID: Am 25.10.2007 um 02:50 schrieb Uli Kusterer: > Am 24.10.2007 um 13:21 schrieb Markus Hitter: > >> The user always knows best what (s)he wants. > > Definitely not. With such an attitude, you better stop working for customers. My humble opinion. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From kusterer at gmail.com Thu Oct 25 04:08:02 2007 From: kusterer at gmail.com (Uli Kusterer) Date: Thu Oct 25 04:08:09 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: References: <6A3903D2-65AE-4270-9372-FAD63D99B604@jump-ing.de> <86236D2A-84DA-40A9-9276-C3B6C53D0835@gmail.com> Message-ID: <57C2B151-754D-4A65-8563-6FC577174F3A@gmail.com> On 25.10.2007, at 11:52, Markus Hitter wrote: > Am 25.10.2007 um 02:50 schrieb Uli Kusterer: > >> Am 24.10.2007 um 13:21 schrieb Markus Hitter: >> >>> The user always knows best what (s)he wants. >> >> Definitely not. > > With such an attitude, you better stop working for customers. > > My humble opinion. Well, everyone's entitled to their opinion. I have stated in various places that I think that the user doesn't, and moreover shouldn't *have to* know what they want. I want to write software that stays out of the way, that can be used easily, without having to first acquire lots of knowledge about the way the program works. I've certainly been in the situation myself where I didn't know whether an application would run on a particular Mac, and I find it much more convenient to just click the thing and have it tell me, than having to dig out a paper manual and search it, or having to find the correct page on the vendor's huge web site. If you still think I should stop working for customers, I guess we have to agree to disagree. Or you could read Steve Krug's book "Don't make me think!", which explains the school of thought behind this at length. Cheers, -- M. Uli Kusterer http://www.zathras.de From alastair at alastairs-place.net Thu Oct 25 07:17:05 2007 From: alastair at alastairs-place.net (Alastair Houghton) Date: Thu Oct 25 07:17:11 2007 Subject: [CocoaApp isThisTiger] In-Reply-To: <57C2B151-754D-4A65-8563-6FC577174F3A@gmail.com> References: <6A3903D2-65AE-4270-9372-FAD63D99B604@jump-ing.de> <86236D2A-84DA-40A9-9276-C3B6C53D0835@gmail.com> <57C2B151-754D-4A65-8563-6FC577174F3A@gmail.com> Message-ID: <350CA36C-8A90-4C5A-BC32-F283A70565AC@alastairs-place.net> On 25 Oct 2007, at 12:08, Uli Kusterer wrote: > On 25.10.2007, at 11