On Aug 2, 2011, at 12:40 PM, cocoa-dev-requ...@lists.apple.com wrote: > Send Cocoa-dev mailing list submissions to > cocoa-dev@lists.apple.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.apple.com/mailman/listinfo/cocoa-dev > or, via email, send a message with subject or body 'help' to > cocoa-dev-requ...@lists.apple.com > > You can reach the person managing the list at > cocoa-dev-ow...@lists.apple.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Cocoa-dev digest..." > > > Today's Topics: > > 1. Re: ARC and Singletons (Karl Goiser) > 2. Re: ARC and Singletons (Kyle Sluder) > 3. Re: ARC and Singletons (Karl Goiser) > 4. Re: ARC and Singletons (Jean-Daniel Dupas) > 5. quick look question (Rick C.) > 6. Re: quick look question (jonat...@mugginsoft.com) > 7. Long delay of NSPopUpButton first click (Rimas M.) > 8. Re: Long delay of NSPopUpButton first click (Glenn L. Austin) > 9. How to detect Time Machine volume? (Leonardo Borsten) > 10. Cocoa AppleScript (John Nairn) > 11. Re: Why Don't Cocoa's (Un)Archiving Methods return Errors? > (Wade Tregaskis) > 12. Re: How to detect Time Machine volume? (Stephane Sudre) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 02 Aug 2011 12:14:35 +1000 > From: Karl Goiser <li...@goiser.com> > Subject: Re: ARC and Singletons > To: Cocoa Dev <cocoa-dev@lists.apple.com> > Message-ID: <4f16ede9-a4ab-4902-ba02-954893537...@goiser.com> > Content-Type: text/plain; charset=windows-1252 > > Wow, class methods finally get the tick of approval! Only 30+ years after > being specified in the Smalltalk standard.. > > > Forget about singletons: they are just a workaround for not having class > methods/variables. > > > Each class is a single object that exists for the life of the application > therefore it is, by definition a singleton - and you get it for free! > > > You don‚t need to keep and manage variables pointing to the class because you > already have it when you send a message to a class method. > > > Karl > > > > ------------------------------ > > Message: 2 > Date: Mon, 01 Aug 2011 21:02:31 -0700 > From: Kyle Sluder <kyle.slu...@gmail.com> > Subject: Re: ARC and Singletons > To: Karl Goiser <li...@goiser.com> > Cc: Cocoa Dev <cocoa-dev@lists.apple.com> > Message-ID: > <canes-cwjtbzaqdm86djncsy7_utcqcylgxdkbtxvp_vbsej...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Aug 1, 2011 at 7:14 PM, Karl Goiser <li...@goiser.com> wrote: >> Wow, class methods finally get the tick of approval! Only 30+ years after >> being specified in the Smalltalk standard.. >> >> >> Forget about singletons: they are just a workaround for not having class >> methods/variables. > > No, they're not. I mentioned the NSFileManager example above; that was > a great example of how the singleton pattern is more flexible than > using class methods for the same task. > > Class methods have their purpose. Cocoa and Cocoa Touch use them to > great effect in places like +[UIView setAnimationsEnabled:], where the > method logically applies to instances of that class. They help > maintain encapsulation, since they are defined inside the class and > therefore, following typical good design principles, are allowed to > peek behind the public veil of instances. > > But class methods aren't a replacement for the singleton pattern. Even > if we had class storage (which in practice would be no different from > static global variables except for scope), class methods would still > be appropriate for a different set of tasks. > > I wouldn't hold my breath waiting for Apple or anyone else to drop the > singleton pattern and adopt class methods. > > --Kyle Sluder > > > ------------------------------ > > Message: 3 > Date: Tue, 02 Aug 2011 16:22:13 +1000 > From: Karl Goiser <li...@goiser.com> > Subject: Re: ARC and Singletons > To: Kyle Sluder <kyle.slu...@gmail.com> > Cc: Cocoa Dev <cocoa-dev@lists.apple.com> > Message-ID: <a4233bf0-fa8b-4e35-95a4-5b9269df2...@goiser.com> > Content-Type: text/plain; charset=windows-1252 > > Yes they are. > > > They are a kludge that came about because C++ doesn‚t implement object > behaviour properly. > > Try this: http://www.google.com/search?hl=en&q=Singleton%2Bevil > > > You have not said what about NSFileManager is a great example of the > singleton pattern. > > > Of course class methods have their purposes: lots of them! > Normally, not even a class method is allowed to break encapsulation. What I > think you mean is that a class method sets class properties that all > instances of that class refer to.. > > > Of course, class methods aren‚t a replacement for the singleton pattern: the > singleton pattern is a fix for inadequately designed languages. > > > Karl > > > > On 02/08/2011, at 2:02 PM, Kyle Sluder wrote: > >> On Mon, Aug 1, 2011 at 7:14 PM, Karl Goiser <li...@goiser.com> wrote: >>> Wow, class methods finally get the tick of approval! Only 30+ years after >>> being specified in the Smalltalk standard.. >>> >>> >>> Forget about singletons: they are just a workaround for not having class >>> methods/variables. >> >> No, they're not. I mentioned the NSFileManager example above; that was >> a great example of how the singleton pattern is more flexible than >> using class methods for the same task. >> >> Class methods have their purpose. Cocoa and Cocoa Touch use them to >> great effect in places like +[UIView setAnimationsEnabled:], where the >> method logically applies to instances of that class. They help >> maintain encapsulation, since they are defined inside the class and >> therefore, following typical good design principles, are allowed to >> peek behind the public veil of instances. >> >> But class methods aren't a replacement for the singleton pattern. Even >> if we had class storage (which in practice would be no different from >> static global variables except for scope), class methods would still >> be appropriate for a different set of tasks. >> >> I wouldn't hold my breath waiting for Apple or anyone else to drop the >> singleton pattern and adopt class methods. >> >> --Kyle Sluder > > > > > ------------------------------ > > Message: 4 > Date: Tue, 02 Aug 2011 09:51:58 +0200 > From: Jean-Daniel Dupas <devli...@shadowlab.org> > Subject: Re: ARC and Singletons > To: Karl Goiser <li...@goiser.com> > Cc: Cocoa Dev <cocoa-dev@lists.apple.com> > Message-ID: <789b77e2-1ec3-49fc-bd91-4e9775612...@shadowlab.org> > Content-Type: text/plain; charset=windows-1252 > > > Le 2 août 2011 à 08:22, Karl Goiser a écrit : > >> Yes they are. >> >> >> They are a kludge that came about because C++ doesn‚t implement object >> behaviour properly. >> >> Try this: http://www.google.com/search?hl=en&q=Singleton%2Bevil >> >> >> You have not said what about NSFileManager is a great example of the >> singleton pattern. > > > Since 10.5, you can create other instances of NSFileManager. > > Thanks to the design it chooses (singleton pattern) it was possible to change > its behavior without breaking the whole API. > > >> Of course class methods have their purposes: lots of them! >> Normally, not even a class method is allowed to break encapsulation. What I >> think you mean is that a class method sets class properties that all >> instances of that class refer to.. >> >> >> Of course, class methods aren‚t a replacement for the singleton pattern: the >> singleton pattern is a fix for inadequately designed languages. >> > > That's not because there is 2 way to do the same thing that one is The One > True Way˙ and the other is a poor practice used by bad programmers. > >> >> Karl >> >> >> >> On 02/08/2011, at 2:02 PM, Kyle Sluder wrote: >> >>> On Mon, Aug 1, 2011 at 7:14 PM, Karl Goiser <li...@goiser.com> wrote: >>>> Wow, class methods finally get the tick of approval! Only 30+ years after >>>> being specified in the Smalltalk standard.. >>>> >>>> >>>> Forget about singletons: they are just a workaround for not having class >>>> methods/variables. >>> >>> No, they're not. I mentioned the NSFileManager example above; that was >>> a great example of how the singleton pattern is more flexible than >>> using class methods for the same task. >>> >>> Class methods have their purpose. Cocoa and Cocoa Touch use them to >>> great effect in places like +[UIView setAnimationsEnabled:], where the >>> method logically applies to instances of that class. They help >>> maintain encapsulation, since they are defined inside the class and >>> therefore, following typical good design principles, are allowed to >>> peek behind the public veil of instances. >>> >>> But class methods aren't a replacement for the singleton pattern. Even >>> if we had class storage (which in practice would be no different from >>> static global variables except for scope), class methods would still >>> be appropriate for a different set of tasks. >>> >>> I wouldn't hold my breath waiting for Apple or anyone else to drop the >>> singleton pattern and adopt class methods. >>> >>> --Kyle Sluder >> >> >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org >> >> This email sent to devli...@shadowlab.org > > -- Jean-Daniel > > > > > > > ------------------------------ > > Message: 5 > Date: Tue, 02 Aug 2011 18:39:51 +0800 > From: "Rick C." <rickcort...@gmail.com> > Subject: quick look question > To: Cocoa Dev <cocoa-dev@lists.apple.com> > Message-ID: <6b2727cd-40c8-44db-9605-af7bc6b75...@gmail.com> > Content-Type: text/plain; charset=us-ascii > > Hi all, > > I want to include this feature in my app and the way I want it to work is if > a user selects a file in my table view and clicks a button it will open that > file in a quick look panel just the way it works in Finder. Actually if > there was only a way to trigger that easily like NSWorkspace or something I'd > use it! Now I need to support 10.5 still and unfortunately I see a lot of it > became formal in 10.6. But is it possible to achieve what I'm looking to do? > I have download QuickLook Sketch sample code am I going in the right > direction because I wasn't hoping to make any plugins. Any pointers would be > great thanks! > > rc > > ------------------------------ > > Message: 6 > Date: Tue, 02 Aug 2011 12:00:35 +0100 > From: "jonat...@mugginsoft.com" <jonat...@mugginsoft.com> > Subject: Re: quick look question > To: cocoa-dev@lists.apple.com > Message-ID: <00afcdea-9f2e-47a2-b4d6-b83975e39...@mugginsoft.com> > Content-Type: text/plain; charset=us-ascii > > > On 2 Aug 2011, at 11:39, Rick C. wrote: > >> Hi all, >> >> I want to include this feature in my app and the way I want it to work is if >> a user selects a file in my table view and clicks a button it will open that >> file in a quick look panel just the way it works in Finder. Actually if >> there was only a way to trigger that easily like NSWorkspace or something >> I'd use it! Now I need to support 10.5 still and unfortunately I see a lot >> of it became formal in 10.6. But is it possible to achieve what I'm looking >> to do? I have download QuickLook Sketch sample code am I going in the right >> direction because I wasn't hoping to make any plugins. Any pointers would >> be great thanks! >> > > Checkout NSImage+QuickLook available at http://mattgemmell.com/source. > This doesn't use the formal 10.6+ API but calls /usr/bin/qlmanage instead. > Works fine on 10.5, 10.6 and 10.7 > > > Regards > > Jonathan Mitchell > > Developer > Mugginsoft LLP > http://www.mugginsoft.com > > > > > ------------------------------ > > Message: 7 > Date: Tue, 02 Aug 2011 16:42:59 +0300 > From: "Rimas M." <apple.list...@gmail.com> > Subject: Long delay of NSPopUpButton first click > To: Cocoa Development List <cocoa-dev@lists.apple.com> > Message-ID: > <CAEOVC_mwB1HXnvrhdTx9M4vTLmXG2fefzYwHiZ=o42hwqpd...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello list, > > I am trying to do quite simple thing - add a popup with all fonts, available > on system. Each item of menu, should be displayed in corresponding font. As > an example could be all iWork apps. When you dealing with text, you have a > popup with fonts, and each font name is displayed with "preview" of that > font. > > I have tried to do that in very usual way: > - iterating over available fonts > - creating a NSMenuItem for each font, setting it up > - setting menuItem's attributedTitle with corresponding NSFontAttributeName > - adding menuItem to the popup. > > This works as expected, but after app launch, when I click on that popup for > the first time, delay until menu is shown is unacceptable. Usually it takes > a few seconds. All following times I click on the popup, the menu is > displayed immediately. Until relaunch of the app.. > > Shark has not provided any useful information. So I am wondering - I have > missed something, or should I use some "tricks" to avoid that delay? > > Any thoughts are very welcome. > > Regards, > > Rimas M. > > > ------------------------------ > > Message: 8 > Date: Tue, 02 Aug 2011 08:13:38 -0700 > From: "Glenn L. Austin" <gl...@austin-soft.com> > Subject: Re: Long delay of NSPopUpButton first click > To: "Rimas M." <apple.list...@gmail.com> > Cc: Cocoa Development List <cocoa-dev@lists.apple.com> > Message-ID: <6c0fdf81-a013-40af-91f0-0f2c529cb...@austin-soft.com> > Content-Type: text/plain; charset=us-ascii > > On Aug 2, 2011, at 6:42 AM, Rimas M. wrote: > >> Hello list, >> >> I am trying to do quite simple thing - add a popup with all fonts, available >> on system. Each item of menu, should be displayed in corresponding font. As >> an example could be all iWork apps. When you dealing with text, you have a >> popup with fonts, and each font name is displayed with "preview" of that >> font. >> >> I have tried to do that in very usual way: >> - iterating over available fonts >> - creating a NSMenuItem for each font, setting it up >> - setting menuItem's attributedTitle with corresponding NSFontAttributeName >> - adding menuItem to the popup. >> >> This works as expected, but after app launch, when I click on that popup for >> the first time, delay until menu is shown is unacceptable. Usually it takes >> a few seconds. All following times I click on the popup, the menu is >> displayed immediately. Until relaunch of the app.. >> >> Shark has not provided any useful information. So I am wondering - I have >> missed something, or should I use some "tricks" to avoid that delay? > > Yes -- don't do that!!! > > You are asking the system to not only iterate through all of the fonts and > styles, but to also set each menu item's text to that font and style. The > iteration part is fairly quick, setting the item text requires that the font > be loaded and prepared for use just to draw that *one text item*. Preparing > each font takes a small amount of time, but multiplied by the 100+ fonts on a > system gives you a noticeable time delay. > > Most applications that draw the font menu using the fonts actually pre-create > the menu items as images of the menu item text, then only display the image > in the menu. > > (History: I've worked on both the AppleWorks and the Microsoft Office 2011 > font menus in my career.) > > -- > Glenn L. Austin, Computer Wizard and Race Car Driver <>< > <http://www.austin-soft.com> > Looking for more opportunities... > > ------------------------------ > > Message: 9 > Date: Tue, 02 Aug 2011 11:57:37 -0400 > From: Leonardo Borsten <le...@prepressmiami.com> > Subject: How to detect Time Machine volume? > To: Cocoa-Dev List <cocoa-dev@lists.apple.com> > Message-ID: <627e93c7-2511-49a4-94c0-ed9ac2f9d...@prepressmiami.com> > Content-Type: text/plain; charset=us-ascii > > Hello, > > What is the most reliable way to detect in code if a mounted volume is the > Time Machine disk? > Currently I'm using the following code (also to detect a Boot Camp volume): > > - (Boolean)isNotSearchable:(NSString *)volumePath > { > > NSFileManager *fm = [NSFileManager defaultManager]; > > NSString *timemachine = [volumePath > stringByAppendingPathComponent:@"Backups.backupdb"]; > NSString *winSystem = [volumePath > stringByAppendingPathComponent:@"MSDOS.SYS"]; > > if ([fm fileExistsAtPath:timemachine]) return YES; > if ([fm fileExistsAtPath:winSystem]) return YES; > > return NO; > } > > This works fine on my system. Will this code work reliably on my user's > systems? Is there a better way? > The same question can apply for iDisk and iCloud, probably. > > The reason I need to know is that I have a function using FSCatalogSearch > where I definitely don't want to access these type of volumes. > > Thanks! > > > Leonardo Borsten > > > ------------------------------ > > Message: 10 > Date: Tue, 02 Aug 2011 09:04:20 -0700 > From: John Nairn <j...@geditcom.com> > Subject: Cocoa AppleScript > To: cocoa-dev@lists.apple.com > Message-ID: <6af84b7d-c93b-4e4d-8cc1-943cf4060...@geditcom.com> > Content-Type: text/plain; charset=us-ascii > > I have always run AppleScripts with a single Cocoa call: > > NSAppleEventDescriptor *result=[script executeAndReturnError:&errorInfo]; > > but things seemed to have change in Lion. The first symptom is that scripts > that used to run fine, now quit with an "AppleEvent timed out" error. The > only one that is causing problems now is simply to open a file in a Script: > > open file GEDFilePath > > This task times out immediately without waiting the 120 seconds (which is > supposed to be default AppleEvent time out time) and despite the fact the the > file successfully opens even after the script has quit. My Cocoa code to open > a file does the following. The document class responds to > > - (BOOL)readFromURL:(NSURL *)absoluteURL ofType:(NSString *)aType > error:(NSError **)outError > > The first task is to detach a thread to read the file: > > [NSThread detachNewThreadSelector:@selector(readFileThread:) > toTarget:self > withObject:[NSArray > arrayWithObjects:fileName,aType,nil]]; > > The main thread then enters a modal progress panel to display opening > progress and to have a button to cancel the process if desired: > > showProgress = (allocate and retain my ProgressController > window) > NSTimeInterval frameRate = 1./3.; > [showProgress runModalProgress:frameRate]; > [[showProgress window] close]; > [showProgress release]; > showProgress = nil; > > This same code works fine in 10.4 through 10.6. In Lion the read process > works fine but times out immediately when called from AppleScript. > > ------------ > John Nairn > http://www.geditcom.com > Genealogy Software for the Mac > > > > ------------------------------ > > Message: 11 > Date: Tue, 02 Aug 2011 09:54:16 -0700 > From: Wade Tregaskis <wadesli...@mac.com> > Subject: Re: Why Don't Cocoa's (Un)Archiving Methods return Errors? > To: Greg Parker <gpar...@apple.com> > Cc: Cocoa-Dev Apple <cocoa-dev@lists.apple.com> > Message-ID: <20a03831-1463-4c4c-b396-c283a5251...@mac.com> > Content-Type: text/plain; charset=windows-1252 > >>> That'll need to be updated. If you look at the @autoreleasepool section of >>> the ARC documentation, it specifically states that crossing out of one via >>> an exception will not drain the pool. There doesn't appear to be any way, >>> even through compiler flags, to change this. >> >> If an autorelease pool pop is skipped by an exception, then the autorelease >> pool will not be drained immediately. However, it will generally be drained >> later, after the exception is caught and handled and some parent pool itself >> is drained normally. > > "Generally"? In any case, could you see that the ARC documentation is > updated - it says nothing about this; in fact it clearly states the behaviour > I noted. > > Also, now that I look at it again closely, the older documentation on > autorelease pools and exceptions doesn't make sense. > >> If an exception occurs, and the thread suddenly transfers out of the current >> context, the pool associated with that context is drained. However, if that >> pool is not the top pool on the thread‚s stack, all the pools above the >> drained pool are also drained (releasing all their objects in the process) > > Isn't the autorelease pool "of the current context" by definition the topmost > one? If the exception takes you out of several autorelease-pool contexts > then of course based on the first sentence you would expect all of them to be > drained. Which I gather is the behaviour. So the second sentence (in fact, > most of the rest of that paragraph in the docs) is very confusing. > > Also, I don't understand the last bit of: > >> Neither is it necessary or even desirable for an exception handler to send >> release to its autorelease pool, unless the handler is re-raising the >> exception. > > How does re-raising the exception change the autorelease pool behaviour? If > I don't release the pool explicitly when re-raising an exception, does that > mean the pool is 'leaked'? > > ------------------------------ > > Message: 12 > Date: Tue, 02 Aug 2011 19:37:22 +0200 > From: Stephane Sudre <dev.iceb...@gmail.com> > Subject: Re: How to detect Time Machine volume? > To: Leonardo Borsten <le...@prepressmiami.com> > Cc: Cocoa-Dev List <cocoa-dev@lists.apple.com> > Message-ID: > <camkfz2a+n8tsz5ajyrzryd9b_hfelkn4y6cg3mf-eieg+f+...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > This code would work in most cases but is actually unreliable. > > Obvious cases: you have 2 text files with these names ar the root of a > partition. > Worse case: an old time machine partition has been replaced by a new > one. Since the old partition is some kind of a second backup, the user > has not removed the Time Machine files. > > For Boot Camp, I tend to believe it's possible to get the information > using the statfs API. > > For Time Machine, maybe it's safe to get the info from the > /Library/Preferences/com.apple.TimeMachine.plist file (assuming it's > there). > > > On Tue, Aug 2, 2011 at 5:57 PM, Leonardo Borsten > <le...@prepressmiami.com> wrote: >> Hello, >> >> What is the most reliable way to detect in code if a mounted volume is the >> Time Machine disk? >> Currently I'm using the following code (also to detect a Boot Camp volume): >> >> - (Boolean)isNotSearchable:(NSString *)volumePath >> { >> >> NSFileManager *fm = [NSFileManager defaultManager]; >> >> NSString *timemachine = [volumePath >> stringByAppendingPathComponent:@"Backups.backupdb"]; >> NSString *winSystem = [volumePath >> stringByAppendingPathComponent:@"MSDOS.SYS"]; >> >> if ([fm fileExistsAtPath:timemachine]) return YES; >> if ([fm fileExistsAtPath:winSystem]) return YES; >> >> return NO; >> } >> >> This works fine on my system. Will this code work reliably on my user's >> systems? Is there a better way? >> The same question can apply for iDisk and iCloud, probably. >> >> The reason I need to know is that I have a function using FSCatalogSearch >> where I definitely don't want to access these type of volumes. >> >> Thanks! >> >> >> Leonardo Borsten >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/cocoa-dev/dev.iceberg%40gmail.com >> >> This email sent to dev.iceb...@gmail.com >> > > > ------------------------------ > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins (at) lists.apple.com > > http://lists.apple.com/mailman/listinfo/cocoa-dev > > > End of Cocoa-dev Digest, Vol 8, Issue 595 > *****************************************
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
