Re: Cocoa-dev Digest, Vol 8, Issue 595
Re: Cocoa-dev Digest, Vol 8, Issue 595
- Subject: Re: Cocoa-dev Digest, Vol 8, Issue 595
- From: Bill Monk <email@hidden>
- Date: Tue, 02 Aug 2011 13:34:20 -0500
On Aug 2, 2011, at 12:40 PM, email@hidden wrote:
> Send Cocoa-dev mailing list submissions to
> email@hidden
>
> 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
> email@hidden
>
> You can reach the person managing the list at
> email@hidden
>
> 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 (email@hidden)
> 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 <email@hidden>
> Subject: Re: ARC and Singletons
> To: Cocoa Dev <email@hidden>
> Message-ID: <email@hidden>
> 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 <email@hidden>
> Subject: Re: ARC and Singletons
> To: Karl Goiser <email@hidden>
> Cc: Cocoa Dev <email@hidden>
> Message-ID:
> <email@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Mon, Aug 1, 2011 at 7:14 PM, Karl Goiser <email@hidden> 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 <email@hidden>
> Subject: Re: ARC and Singletons
> To: Kyle Sluder <email@hidden>
> Cc: Cocoa Dev <email@hidden>
> Message-ID: <email@hidden>
> 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+evil
>
>
> 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 <email@hidden> 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 <email@hidden>
> Subject: Re: ARC and Singletons
> To: Karl Goiser <email@hidden>
> Cc: Cocoa Dev <email@hidden>
> Message-ID: <email@hidden>
> 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+evil
>>
>>
>> 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 <email@hidden> 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 (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
> -- Jean-Daniel
>
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 02 Aug 2011 18:39:51 +0800
> From: "Rick C." <email@hidden>
> Subject: quick look question
> To: Cocoa Dev <email@hidden>
> Message-ID: <email@hidden>
> 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: "email@hidden" <email@hidden>
> Subject: Re: quick look question
> To: email@hidden
> Message-ID: <email@hidden>
> 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." <email@hidden>
> Subject: Long delay of NSPopUpButton first click
> To: Cocoa Development List <email@hidden>
> Message-ID:
> <CAEOVC_mwB1HXnvrhdTx9M4vTLmXG2fefzYwHiZ=email@hidden>
> 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" <email@hidden>
> Subject: Re: Long delay of NSPopUpButton first click
> To: "Rimas M." <email@hidden>
> Cc: Cocoa Development List <email@hidden>
> Message-ID: <email@hidden>
> 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 <email@hidden>
> Subject: How to detect Time Machine volume?
> To: Cocoa-Dev List <email@hidden>
> Message-ID: <email@hidden>
> 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 <email@hidden>
> Subject: Cocoa AppleScript
> To: email@hidden
> Message-ID: <email@hidden>
> 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 <email@hidden>
> Subject: Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
> To: Greg Parker <email@hidden>
> Cc: Cocoa-Dev Apple <email@hidden>
> Message-ID: <email@hidden>
> 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 <email@hidden>
> Subject: Re: How to detect Time Machine volume?
> To: Leonardo Borsten <email@hidden>
> Cc: Cocoa-Dev List <email@hidden>
> Message-ID:
> <email@hidden>
> 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
> <email@hidden> 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 (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>>
>
>
> ------------------------------
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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 (email@hidden)
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:
This email sent to email@hidden