Notarization porcess
Has anyone actually been able to get an App notarized in Xcode? After I upload the App to Apple for notarization, I get an e-mail from Apple after a few minutes that says the App has been notarized and I can now Export it. However, back in Xcode in the Organizer window it says “Processing” and the “Export Notarized App” button isn’t enabled. It just stalls out there. A second question: Assuming notarization of the App eventually happens, do I also need to separately notarize the DMG that I distribute the App in (in the Terminal CLI) ? If I need to do both, this could take nearly forever. TIA, Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
MKLaunchOptionsMapTypeKey in OS X Mavericks
In OS X Mavericks, has anyone used MKLaunchOptionsMapTypeKey to open a map in
Hybrid mode, for example:
NSDictionary *options = @{MKLaunchOptionsMapTypeKey: [NSNumber
numberWithUnsignedInteger:MKMapTypeHybrid]};
followed by openInMapsWithLaunchOptions: ?
The map opens in Hybrid mode, however in order to set it into Standard mode (in
the Maps application), you need to select Hybrid mode (or Satellite mode), and
then set it to Standard mode. Also, the view menu shows no selection when you
initially go into the Maps application.
Is this a bug or is there something else that needs to be done in order to make
this work correctly?
Thanks,
Jim Merkel
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Sandboxing not so bad
Maybe you are correct. I have found a couple of other cases where Sandboxing limits the functionality of my application. I'm beginning to think maybe I should not Sandbox. By the way, none of the applications I have downloaded from the MAS are Sandboxed. Seems to be a lot of exceptions being made. Jim Merkel On Sep 15, 2012, at 2:55 PM, koko k...@highrolls.net wrote: Yes, a piece of cake for a piece of cake app. Try doing something like iterating the file system so you can present to the user all files of unique types you understand that can be anywhere on the system. The sandbox is like a cat box … to be avoided at all costs. -koko On Sep 15, 2012, at 3:01 PM, James Merkel wrote: On Sep 13, 2012, at 12:45 PM, James Merkel jmerk...@mac.com wrote: Sandboxing is not as restrictive than I though it would be. For example, the documentation for the entitlement: com.apple.security.files.user-selected.read-write says this entitlement provides: Read/write access to files the user has selected using an Open or Save dialog . I was reading more into that than I should have. If you use the Open dialog to access a file, then you can read and write to the file. You don't have to use the Save dialog to write to the file. And that file can be anywhere on the file system (except for system files I guess). And yes the app is really sandboxed. If no entitlements are enabled I can't do anything (except read and write to recent documents in the Open Recent menu). So with just that entitlement and a Printing Entitlement I can do just about everything I could previously do before Sandboxing. The only thing I can't do is write comments to the Finder GetInfo window -- because that uses Applescript. But I can live without that. So unless I'm missing something, sandboxing is a piece of cake. Thanks, Jim Merkel Just noticed -- perviously I had the capability to make a change to all files in a folder based on the changes to a particular open file from that folder. With Sandboxing, I can't do that anymore since those other files weren't opened from an Open dialog. So maybe Sandboxing is not so wonderful. On the other hand, one could also say that my previous implementation didn't follow human interface guidelines. Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/koko%40highrolls.net This email sent to k...@highrolls.net ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Sandboxing not so bad
On Sep 13, 2012, at 12:45 PM, James Merkel jmerk...@mac.com wrote: Sandboxing is not as restrictive than I though it would be. For example, the documentation for the entitlement: com.apple.security.files.user-selected.read-write says this entitlement provides: Read/write access to files the user has selected using an Open or Save dialog . I was reading more into that than I should have. If you use the Open dialog to access a file, then you can read and write to the file. You don't have to use the Save dialog to write to the file. And that file can be anywhere on the file system (except for system files I guess). And yes the app is really sandboxed. If no entitlements are enabled I can't do anything (except read and write to recent documents in the Open Recent menu). So with just that entitlement and a Printing Entitlement I can do just about everything I could previously do before Sandboxing. The only thing I can't do is write comments to the Finder GetInfo window -- because that uses Applescript. But I can live without that. So unless I'm missing something, sandboxing is a piece of cake. Thanks, Jim Merkel Just noticed -- perviously I had the capability to make a change to all files in a folder based on the changes to a particular open file from that folder. With Sandboxing, I can't do that anymore since those other files weren't opened from an Open dialog. So maybe Sandboxing is not so wonderful. On the other hand, one could also say that my previous implementation didn't follow human interface guidelines. Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Sandboxing not so bad
Sandboxing is not as restrictive than I though it would be. For example, the documentation for the entitlement: com.apple.security.files.user-selected.read-write says this entitlement provides: Read/write access to files the user has selected using an Open or Save dialog . I was reading more into that than I should have. If you use the Open dialog to access a file, then you can read and write to the file. You don't have to use the Save dialog to write to the file. And that file can be anywhere on the file system (except for system files I guess). And yes the app is really sandboxed. If no entitlements are enabled I can't do anything (except read and write to recent documents in the Open Recent menu). So with just that entitlement and a Printing Entitlement I can do just about everything I could previously do before Sandboxing. The only thing I can't do is write comments to the Finder GetInfo window -- because that uses Applescript. But I can live without that. So unless I'm missing something, sandboxing is a piece of cake. Thanks, Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Window Title drop-down menu in 10.8
On Sep 1, 2012, at 10:30 AM, Mike Abdullah cocoa...@mikeabdullah.net wrote: On 16 Aug 2012, at 14:52, James Merkel jmerk...@mac.com wrote: On Aug 15, 2012, at 11:25 PM, Mike Abdullah cocoa...@mikeabdullah.net wrote: On 14 Aug 2012, at 05:29, James Merkel jmerk...@mac.com wrote: In 10.8, what capabilities does a window need in order for it to have the window title drop down menu? My windows don't seem to have this feature. Does the window need to be document based? Yes. What feature(s) would you like of the dropdown? Primarily the Rename… capability.. Hi Jim, I finally dug up the release notes: https://developer.apple.com/library/mac/#releasenotes/Cocoa/AppKit.html There is no public API for Titlebar Renaming outside of NSDocument. You may note that even if your application is not app sandboxed, an instance of pboxd (aka Powerbox) is running while a Titlebar Renaming session is in progress. Titlebar Renaming uses pboxd even in non-sandboxed applications. Thanks for the link. I was hoping that there was a way of doing a rename without being an document based app, like you can have a recent documents menu even if you are not a documents based application. Apparently can't do that using public APIs. Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Sandboxing die.die.die
Why not just codeSign an application? It will still will be able to be downloaded by anyone using the default security setting: Mac App Store and identified developers. It just won't be able to be in the App store (I guess). Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Sandboxing die.die.die
Ok, for my particular application I don't see any need for iCloud or Notification center. For other applications, YMMV. Jim Merkel On Aug 22, 2012, at 12:51 PM, Alex Kac a...@webis.net wrote: There are some MAS-only features such as Notification Center (I believe) and iCloud, so its quite nice to be able to use those features. On Aug 22, 2012, at 2:42 PM, James Merkel jmerk...@mac.com wrote: Why not just codeSign an application? It will still will be able to be downloaded by anyone using the default security setting: Mac App Store and identified developers. It just won't be able to be in the App store (I guess). Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/alex%40webis.net This email sent to a...@webis.net Alex Kac - President and Founder Web Information Solutions, Inc. “Don't forget until too late that the business of life is not business but living.” -- B.C. Forbes, ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Sandboxing die.die.die
On Aug 22, 2012, at 1:27 PM, Kyle Sluder k...@ksluder.com wrote: On Wed, Aug 22, 2012, at 01:02 PM, Lee Ann Rucker wrote: Notification Center is usable by any app; I'm using it and App Store isn't even a possibility at this point. I believe your app has to be code-signed. But any valid code signature should work. --Kyle Sluder However, I don't think you can self sign it can you? Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Speed up image display for large raw images?
On Tue, 14 Aug 2012 21:58:38 Marco S Hyman wrote: The images are typically 25 MB Canon 7D raw image files that have been pre-alloc'ed and initWithContentsOfFile: The NSImageView is about 600x400 pixels. You could try to get to a reduced resolution image (preview image). Usually Raw files have these in jpeg format. Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Window Title drop-down menu in 10.8
On Aug 15, 2012, at 11:25 PM, Mike Abdullah cocoa...@mikeabdullah.net wrote: On 14 Aug 2012, at 05:29, James Merkel jmerk...@mac.com wrote: In 10.8, what capabilities does a window need in order for it to have the window title drop down menu? My windows don't seem to have this feature. Does the window need to be document based? Yes. What feature(s) would you like of the dropdown? Primarily the Rename… capability.. Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Window Title drop-down menu in 10.8
In 10.8, what capabilities does a window need in order for it to have the window title drop down menu? My windows don't seem to have this feature. Does the window need to be document based? Thanks, Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Thousands separators added to number fields
As of 10.8, it looks like thousands separators are automatically added to numbers displayed in text boxes. Can this be disabled? In some places it doesn't make sense like in a display of a year. TIA, Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thousands separators added to number fields
As of 10.8, it looks like thousands separators are automatically added to numbers displayed in text boxes. Can this be disabled? In some places it doesn't make sense like in a display of a year. Ok, I see from: https://developer.apple.com/library/mac/#releasenotes/CoreFoundation/CoreFoundation.html that +[NSString localizedStringWithFormat:] which I am using now adds the thousands separators. I don't see a way around this. Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thousands separators added to number fields
On Aug 10, 2012, at 1:17 PM, James Merkel jmerk...@mac.com wrote: +[NSString localizedStringWithFormat:] Never mind -- I see I can use +[NSString stringWithFormat:] rather than +[NSString localizedStringWithFormat:] to avoid the thousand separators. Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thousands separators added to number fields
Ok, I could do it that way also. Jim Merkel On Aug 10, 2012, at 1:28 PM, Kyle Sluder k...@ksluder.com wrote: On Fri, Aug 10, 2012, at 01:17 PM, James Merkel wrote: As of 10.8, it looks like thousands separators are automatically added to numbers displayed in text boxes. Can this be disabled? In some places it doesn't make sense like in a display of a year. Ok, I see from: https://developer.apple.com/library/mac/#releasenotes/CoreFoundation/CoreFoundation.html that +[NSString localizedStringWithFormat:] which I am using now adds the thousands separators. I don't see a way around this. Aside from attaching an NSNumberFormatter to the text field? --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cocoa-dev Digest, Vol 9, Issue 569
On Fri, 10 Aug 2012 13:47:48 -0600 mail...@ericgorr.net wrote: For a JPG image, I can just use CGImageSourceCopyPropertiesAtIndex to obtain the various bits of EXIF information from the image. However, this API does not work with quicktime movie files. What similar Cocoa APIs can I use to extact EXIF information from a Quicktime movie file? Or, if there aren't any Cocoa APIs, what might my best option be? Anyone face a similar issue? Possibly you can use ExifTool, otherwise you have to roll your own. Here's a link that has info on Quicktime tags: http://owl.phy.queensu.ca/~phil/exiftool/TagNames/QuickTime.html Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode - An Apple Embarrassment
Fri, 02 Mar 2012 16:00:41 +0900 On John Joyce wrote: I have to agree with Gene. I wasn't going to acknowledge this thread, but it is good to hear more than just people moaning. The initial adjustment to 4.x was jarring, but once you get used to the changes, they're mostly great! To the credit of the Xcode dev team, this thing is a HUGE undertaking and it's only gotten better with each update! What clang llvm do for code completion.. and the fix-it mechanism... just awesome and amazing. Just think how much work it is to build any IDE or fancy text editor... now try to do that yourself, even with a team... then you will appreciate how awesome it is. … Not sure why this thread is on Coccoa either. I'm probably a more casual user of Xcode than most of you guys. However, I haven't had any problems with Xcode 4.3. As far as I can remember 4.3 has never crashed -- whereas older versions of Xcode 4 did crash. For example just moving files around in the Navigator caused a crash. Also sometimes you couldn't bring up Xcode from the dock. You had to quit and restart. But that doesn't happen in 4.3. I also really like the features of Xcode 4. It takes a little getting used to but it's great after that. Of course if you are having random crashes - not reproducible, that would be annoying. But I'm not seeing that. Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Sensitivity of swipe gesture
Somewhat off-topic for Cocoa -- but In Lion 10.7, the swipe gesture is a nice feature of the mouse. However I find that frequently the mouse wants to swipe pages when I just want to scroll the page. When that happens the page has to settle down before anything else can be done. Kind of annoying. Is there any sensitivity preference or whatever for the swipe gesture? Then again maybe I'm just lacking motor control in my old age! Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Recently Opened in Doc
On 28 Jan 2012 08:46:48 -0800 Quincey Morris wrote: On Jan 28, 2012, at 08:19 , Brad Stone wrote: I have a shoebox app like iPhoto where the actual filename is irrelevant to the user. I control the file name. What I'd like to do is just capture the menu items before they're displayed and change the menu titles into something relevant to the user. In the scheme of things it's a minor way to access the info in my app so if I could eliminate them that would be OK too. Changing the filename is not an option at this point. It seems to me you can subclass NSDocumentController, then override 'noteNewRecentDocument:' to do nothing. Presumably this will keep your filename off the Open Recent submenu, the Recent Items item on the Apple menu, and the dock menu. Then you should be able to delete the Open Recent item itself, and be left with no traces of recent items from your app. If you wanted to go the extra mile, you could create your own recent-items implementation, driven from your 'noteNewRecentDocument:' override, and using the 'applicationDockMenu:' application delegate method, with whatever document identifiers you want. My app is not document based so I call noteNewRecentDocumentURL: directly to add the filename to the Open Recent submenu list. If I comment that line of code out then the document is not added to the list as expected. Also, the Dock menu Show Recents shows nothing and the filename is not added to the Dock menu list. So yes, noteNewRecentDocument; (which calls noteNewRecentDocumentURL: ) is the key to the whole thing. Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Recently Opened in Doc
On 27 Jan 2012 10:20:37 Brad Stone wrote: I'd like to 1) change the menu titles of the recently opened documents listed in the dock menu if I can't do that I'd like to 2) remove the list of recently opened documents all together. I haven't been able to find a way to do this. Can someone provide guidance? Thanks I don't have an answer to your question -- but something I didn't notice before. If you rename a file, the new filename appears in the recently opened files menu (replacing the old filename). However the old filename stays in the doc menu. Seems like that's a bug. Jim Merkel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Respecting tabs across applications
On Jan 11, 2012, at 2:40 PM, James Merkel wrote: On Jan 11, 2012, at 8:39 AM, Ross Carter wrote: On Jan 10, 2012, at 10:14 PM, James Merkel wrote: the default NSParagraphStyle is being applied to my string. To be precise, a NSParagraphStyle is being applied to your attributed string. The NSString does not contain any formatting information. When you copy rich text, say from TextEdit, you place two sets of data on the pasteboard: the rich text data with the NSParagraphStyle and font information, and plain text data, which is just the characters. When you paste into a document, the receiving app chooses the item on the pasteboard that it wants to use. A code editor might prefer the plain text version, whereas a word processor would prefer the rich text version. If you want the text to line up neatly in an app that takes plain text from the pasteboard, you probably want to align everything using spaces, as Jens said. If you want the text to align in an app that uses rich text, you should use tabs and define their location using NSParagraphStyle. To handle both possibilities, you need to manage what gets put on the pasteboard. If you are using NSTextView, there are some pasteboard methods available for you to override. Ross I'm using my own defined NSParagraphStyle now for the tabstops and that works fine. That's a cleaner and more maintainable approach than I was using before. So thanks to Jens for that suggestion. I would like to be able to copy and paste to TextEdit and maintain the attributes (including bolded text). I'll take a look at the pasteboard methods of NSTextView. Thanks Jim Merkel Turns out, all I needed to do was check the Allows Rich Text check box in the NSTextView Attributes Inspector in Interface Builder to allow the two types of text (Rich Text and plain text) to be copied to the pasteboard. No coding required - excellent. Jim Merkel ___ 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
Re: Respecting tabs across applications
On Jan 11, 2012, at 8:39 AM, Ross Carter wrote: On Jan 10, 2012, at 10:14 PM, James Merkel wrote: the default NSParagraphStyle is being applied to my string. To be precise, a NSParagraphStyle is being applied to your attributed string. The NSString does not contain any formatting information. When you copy rich text, say from TextEdit, you place two sets of data on the pasteboard: the rich text data with the NSParagraphStyle and font information, and plain text data, which is just the characters. When you paste into a document, the receiving app chooses the item on the pasteboard that it wants to use. A code editor might prefer the plain text version, whereas a word processor would prefer the rich text version. If you want the text to line up neatly in an app that takes plain text from the pasteboard, you probably want to align everything using spaces, as Jens said. If you want the text to align in an app that uses rich text, you should use tabs and define their location using NSParagraphStyle. To handle both possibilities, you need to manage what gets put on the pasteboard. If you are using NSTextView, there are some pasteboard methods available for you to override. Ross I'm using my own defined NSParagraphStyle now for the tabstops and that works fine. That's a cleaner and more maintainable approach than I was using before. So thanks to Jens for that suggestion. I would like to be able to copy and paste to TextEdit and maintain the attributes (including bolded text). I'll take a look at the pasteboard methods of NSTextView. Thanks Jim Merkel ___ 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
Respecting tabs across applications
In my application I tab text (Helvetica 12 font) so that things line up in my application window. If I copy a text selection out of my app window and then look at the clipboard, the text looks the same as in my window. If the clipboard is then pasted into a new TextEdit window or a new TextWrangler window, the tabs don't hold. If the clipboard is pasted into the Xcode editor, the tabs do hold. How can I make sure that tabs are respected in other applications. (Or what can I do in other applications to make sure that the tabs are respected) ? TIA, Jim Merkel ___ 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
Re: Respecting tabs across applications
On Jan 10, 2012, at 1:20 PM, Jens Alfke wrote: On Jan 10, 2012, at 12:49 PM, James Merkel wrote: In my application I tab text (Helvetica 12 font) so that things line up in my application window. If I copy a text selection out of my app window and then look at the clipboard, the text looks the same as in my window. If the clipboard is then pasted into a new TextEdit window or a new TextWrangler window, the tabs don't hold. If the clipboard is pasted into the Xcode editor, the tabs do hold. How can I make sure that tabs are respected in other applications. (Or what can I do in other applications to make sure that the tabs are respected) ? I don’t think you can get this to work everywhere. The best you can do is to make sure that the NSAttributedString you write to the pasteboard has tab stops explicitly defined in its NSParagraphStyle. That should take care of apps that handle styled text, e.g. TextEdit. But TextWrangler and Xcode and other plain-text editors define tabs as a specific number of character widths, and that number is fixed as part of the document, so pasting text wouldn’t affect it. Also, it just occurred to me, are you using multiple consecutive tab characters to try to force things to line up, or are you setting tab stops in the paragraph style? Using multiple tabs is a sure recipe for disaster*, one of those things they warn you not to do in Word Processing 101. —Jens * Sorry if that sounds harsh; I’m a typography geek. Don’t get me started about double-spacing after periods… In fact, I am using multiple consecutive tab characters to force things to line up -- i.e. a sure recipe for disaster. Where is this Word Processing 101 document that I should be reading? Thanks, Jim Merkel___ 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
Re: Respecting tabs across applications
On Jan 10, 2012, at 4:52 PM, Jens Alfke wrote: On Jan 10, 2012, at 2:00 PM, James Merkel wrote: In fact, I am using multiple consecutive tab characters to force things to line up -- i.e. a sure recipe for disaster. The trouble with that is that the number of tabs you’ll need depends on the width of each item, and that’s highly dependent on not only the font, but on which typographic features (like kerning and ligatures) are enabled. Where is this Word Processing 101 document that I should be reading? There was a great old book from the ‘80s called “The Mac Is Not A Typewriter” that went over all this stuff — tabs, spacing between sentences, curly vs straight quotes, dashes vs. hyphens and so on. Nowadays there must be some online tutorials, but I don’t know of anything specific. Anyway, if you want your layout to survive being transferred into TextEdit or a word processor, you should create an NSParagraphStyle with tab stops where you want them, then use a single tab between columns. If you want to paste it into a plain-text editor like Xcode/TextMate/TextWrangler/BBEdit, the task is entirely different. Use nothing but spaces as separators, because you can’t guess what width a tab is at the destination. Just assume the text is monospaced and count the number of characters in a column to figure out how many spaces to insert. Needless to say this will only look right in a monospaced font like Courier. —Jens Ok, I probably should have explained more. All of the strings are precomposed and are in localized string files. The strings are never intended to be edited. So for example I have tag strings like the following in the strings file (English version): BitsPerSample = Bits Per Sample:\t\t; Compression = Compression:\t\t\t; The strings are tabbed for Helvetica Regular 12 point font. So yes if the font is changed the tabs would change. These tag strings are then concatenated with other strings (also in localized string files) and then each line has a CR added. All of the strings are concatenated into one long NSMutableAttributedString and displayed in an NSTextView. I would have thought that if the text were copied out of my App and pasted into a text editor that the tabs would still line things up assuming the text editor had the same font.. To some extent this happens -- i.e.. the tabs still line things up in the clipboard, however they don't line up in TextEdit (even when it's in the plain text mode). In the Xcode editor the tabs do line things up. Even this is somewhat of an improvement compared to older OSX versions -- in 10.5 the tabs didn't line things up correctly even in the clipboard. Now (in Lion version 10.7.2) the text does look good in the clipboard. So some thing has chained in the way the text system works. Also, I notice that the text attributes (bolding) are sometimes lost when copying to the clipboard. This seems to be a random thing -- not sure why. Thanks for your help -- I'll check out NSParagraphStyle and the book you mentioned. Jim Merkel ___ 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
Re: Respecting tabs across applications
On Jan 10, 2012, at 6:54 PM, Jens Alfke wrote: I *think* what you mean there is that the layout works with whatever NSParagraphStyle’s default tab stops are Ok, there's something I didn't understand -- the default NSParagraphStyle is being applied to my string. So, I am supposed to modify this NSParagraphStyle to what I want (just one tab character). And then I need to take out all the extra tab characters in my strings file. Jim Merkel ___ 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
Cocoa Resources
For what it's worth, a couple of resources that I have recently run across that might be useful for Cocoa developers are: 1) An itunes video course on development for the iPhone by Dr Brad Larson: http://itunes.apple.com/itunes-u/advanced-iphone-development/id407243032 Although a year old it has lots of useful information -- even if you are developing for the Mac rather than the iPhone/iPad. 2) Stackoverflow http://stackoverflow.com/ Stackoverflow is a question/answer site that is not language specific. You can ask questions related to Cocoa, Xcode, OSX, iPhone, or iPad development. Or you can ask questions related to algorithms. If you do Google searches, a lot of hits will be to this site. Jim Merkel ___ 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
Re: NSBitmapImageRep and alpha channel
On Nov 12, 2011, at 4:34 PM, James Merkel wrote: On Nov 12, 2011, at 3:29 PM, Quincey Morris wrote: On Nov 12, 2011, at 14:01 , James Merkel wrote: d' = a * s + (1 - a) * d All premultiplication does is precalculate a * s. First question -- what is d' in that equation? It's the result of compositing the source (your image) onto the destination (the background). I read images from files and create histograms from them using pixel data from the NSBitmapImageRep. Things seem to work ok except for images that have an alpha channel (that is, bitsPerPixel = 32 from the NSBitmapImageRep, and an alpha channel is present). The histograms in that case have gaps in them (certain levels seem to be under-represented). Histograms of what? Color component distributions? How do you determine that levels are under-represented? If the pattern of gaps is regular, that probably means that the original image data was up-sampled at some point in the process of delivering the data to the bitmap image rep. Some specific images with this problem were downloaded through Image Capture and rotated in Image Capture. When an image is rotated in Image Capture, apparently the pixel data is rotated and the Exif Orientation tag is changed to reflect the rotation. (This is different from what I thought Apple said in previous documentation. I thought just the Exif Orientation tag was changed, and it was up to the image display program to rotate the image). Anyway, after rotation, the order of the data is ARGB, whereas before the rotation the order was RGBA. In a sense, the pixel order is is irrelevant -- it only matters if you're going to operate on the image pixel by pixel, so that you can decode the pixel components. Also, before the rotation, the alpha channel appears to be just an unused channel -- i.e. it's not really an alpha channel. What do you mean by unused? If the pixel format says there's an alpha channel, there is one. Are all the alpha channel values 1.0? I'd imagine that something captured via Image Capture would be fully opaque. Two additional questions: are the pixel data premultiplied with the alpha channel? Yeah, presumably. Also, for a histogram, should the data be premultiplied with alpha? That is, should the histogram reflect the alpha? Typically, you'd expect not. That's why premultiplied data sucks if you need to analyze or manipulate the pixels. You can always recover a non-premultiplied value, but there's a loss of precision involved (more pronounced as the alpha heads towards 0), so it's better to get hold of the un-premultiplied data. Of course, if all of the alpha values are 1.0, then a * s == s everywhere, so the question of premultiplication is moot. Yes, these are histograms of the color components. I think these histograms are wrong because I looked at the histograms generated by two other programs, and they don't show those gaps. Either they are wrong or I am wrong. Agree, pixel order doesn't matter. However, I only see the problem when the order is ARGB. By unused I mean the format is 32-bits per pixel, but the method hasAlpha on the image bitmap says there is no alpha. The color space is RGB, so I conclude there is an unused 4th channel. Also, using the mask NSAlphaFirstBitmapFormat says the alpha is not first. It (the unused channel) is last. Agree, for these images, the alpha value is always xFF which is 1. So it shouldn't matter. Jim Merkel This is kind of interesting -- if I rotate the image in Preview (rather than Image Capture), then the histogram looks normal. Looking at the NSBitmapImageRep from Preview image, the order is RGBA and there is no reported alpha channel. Furthermore for the Preview rotated image, the Exif Orientation tag says normal (horizontal), and the width and height are reported correctly. For the Image Capture rotated image, the Exif Orientation tag says rotated 90 degrees and the width and height are reversed (i.e. not reported correctly). I think Preview is doing the right thing and Image Capture is doing the wrong thing. Why I get a bad histogram from the IMage Capture rotated image I'm not sure. Jim Merkel ___ 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
Re: NSBitmapImageRep and alpha channel
On Nov 13, 2011, at 12:34 PM, Quincey Morris wrote: On Nov 13, 2011, at 11:11 , James Merkel wrote: This is kind of interesting -- if I rotate the image in Preview (rather than Image Capture), then the histogram looks normal. Looking at the NSBitmapImageRep from Preview image, the order is RGBA and there is no reported alpha channel. Furthermore for the Preview rotated image, the Exif Orientation tag says normal (horizontal), and the width and height are reported correctly. For the Image Capture rotated image, the Exif Orientation tag says rotated 90 degrees and the width and height are reversed (i.e. not reported correctly). I think Preview is doing the right thing and Image Capture is doing the wrong thing. Why I get a bad histogram from the IMage Capture rotated image I'm not sure. The implication of this is likely that you're misinterpreting the pixel format of the Image-Capture-rotated image. (For example, did it change the component values from 8-bit to 16-bit components or to floats, or something like that?). In principle, it shouldn't be too hard to resolve. Simply examining the data, or substituting a test image with known, predictably-arranged colors, should let you see why your histogram calculation doesn't match. NSBitmapImageRep reports that the image is 32-bits per pixel, 8-bits per sample and the pixel values are integers. I have tried some simple one-color test images created in Photoshop Elements. They produce correct histograms. The Photoshop test images are 24-bits per pixel. I'm not sure I have control over making them 32-bits with an alpha channel. I'll have to look into it. Jim Merkel ___ 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
NSBitmapImageRep and alpha channel
The document for NSBitmapImageRep says the following: Alpha Premultiplication If a coverage (alpha) plane exists, a bitmap’s color components are premultiplied with it. If you modify the contents of the bitmap, you are therefore responsible for premultiplying the data. For this reason, though, if you want to manipulate the actual data, an NSBitmapImageRep object is not recommended for storage. If you need to work with data that is not premultiplied, you should use Quartz, specifically CGImageCreate with kCGImageAlphaLast. Note that premultiplying does not affect the output quality. Given source bitmap pixel s, destination pixel d, and alpha value a, a blend is basically d' = a * s + (1 - a) * d All premultiplication does is precalculate a * s. First question -- what is d' in that equation? I read images from files and create histograms from them using pixel data from the NSBitmapImageRep. Things seem to work ok except for images that have an alpha channel (that is, bitsPerPixel = 32 from the NSBitmapImageRep, and an alpha channel is present). The histograms in that case have gaps in them (certain levels seem to be under-represented). Some specific images with this problem were downloaded through Image Capture and rotated in Image Capture. When an image is rotated in Image Capture, apparently the pixel data is rotated and the Exif Orientation tag is changed to reflect the rotation. (This is different from what I thought Apple said in previous documentation. I thought just the Exif Orientation tag was changed, and it was up to the image display program to rotate the image). Anyway, after rotation, the order of the data is ARGB, whereas before the rotation the order was RGBA. Also, before the rotation, the alpha channel appears to be just an unused channel -- i.e. it's not really an alpha channel. Two additional questions: are the pixel data premultiplied with the alpha channel? Also, for a histogram, should the data be premultiplied with alpha? That is, should the histogram reflect the alpha? Thanks for any help. Jim Merkel___ 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
Re: NSBitmapImageRep and alpha channel
On Nov 12, 2011, at 3:29 PM, Quincey Morris wrote: On Nov 12, 2011, at 14:01 , James Merkel wrote: d' = a * s + (1 - a) * d All premultiplication does is precalculate a * s. First question -- what is d' in that equation? It's the result of compositing the source (your image) onto the destination (the background). I read images from files and create histograms from them using pixel data from the NSBitmapImageRep. Things seem to work ok except for images that have an alpha channel (that is, bitsPerPixel = 32 from the NSBitmapImageRep, and an alpha channel is present). The histograms in that case have gaps in them (certain levels seem to be under-represented). Histograms of what? Color component distributions? How do you determine that levels are under-represented? If the pattern of gaps is regular, that probably means that the original image data was up-sampled at some point in the process of delivering the data to the bitmap image rep. Some specific images with this problem were downloaded through Image Capture and rotated in Image Capture. When an image is rotated in Image Capture, apparently the pixel data is rotated and the Exif Orientation tag is changed to reflect the rotation. (This is different from what I thought Apple said in previous documentation. I thought just the Exif Orientation tag was changed, and it was up to the image display program to rotate the image). Anyway, after rotation, the order of the data is ARGB, whereas before the rotation the order was RGBA. In a sense, the pixel order is is irrelevant -- it only matters if you're going to operate on the image pixel by pixel, so that you can decode the pixel components. Also, before the rotation, the alpha channel appears to be just an unused channel -- i.e. it's not really an alpha channel. What do you mean by unused? If the pixel format says there's an alpha channel, there is one. Are all the alpha channel values 1.0? I'd imagine that something captured via Image Capture would be fully opaque. Two additional questions: are the pixel data premultiplied with the alpha channel? Yeah, presumably. Also, for a histogram, should the data be premultiplied with alpha? That is, should the histogram reflect the alpha? Typically, you'd expect not. That's why premultiplied data sucks if you need to analyze or manipulate the pixels. You can always recover a non-premultiplied value, but there's a loss of precision involved (more pronounced as the alpha heads towards 0), so it's better to get hold of the un-premultiplied data. Of course, if all of the alpha values are 1.0, then a * s == s everywhere, so the question of premultiplication is moot. Yes, these are histograms of the color components. I think these histograms are wrong because I looked at the histograms generated by two other programs, and they don't show those gaps. Either they are wrong or I am wrong. Agree, pixel order doesn't matter. However, I only see the problem when the order is ARGB. By unused I mean the format is 32-bits per pixel, but the method hasAlpha on the image bitmap says there is no alpha. The color space is RGB, so I conclude there is an unused 4th channel. Also, using the mask NSAlphaFirstBitmapFormat says the alpha is not first. It (the unused channel) is last. Agree, for these images, the alpha value is always xFF which is 1. So it shouldn't matter. Jim Merkel ___ 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
Re: In Praise of ARC
On Sat, 05 Nov 2011 15:39:01 -0600 Philip McIntosh wrote: I am impressed with the implementation of Automatic Reference Counting (ARC) in iOS 5 and the conversion tool built into XCode 4.2. I have an app that generated a small leak each time I ran a cycle of the app. This was no doubt caused by a design flaw since no matter how much I attended to my retain/release cycles I could not get rid of one left over NSDecimalNumber at the end of each operation. I took the plunge and refactored the project to use ARC in XCode. There were some very scary moments that generated many red warning flags, but I just kept doing it, and after I did it 4 times all the problems cleared themselves. That was a scary thing to do though. I just checked the app with instruments, and sure enough, the memory leaks are gone. Nice job Apple. I tend to agree. I went through a similar exercise with an OSX app. The ARCified code runs fine and there appears to be only one minor leak (I think it's in Apple's own code). One minor fly in the ointment -- ARC only works with Intel 64-bit apps and only on OSX 10.6 and 10.7. If you want to support earlier OS versions you need to build a separate app. Jim Merkel ___ 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
Re: Write to file Entitlement
Why would someone want to base their application on the tenuous availability of a temporary exception ? Jim Merkel On Nov 1, 2011, at 10:30 AM, Laurent Etiemble wrote: Hello, In a sandboxed application, you can read/write files without the save dialog by using the File Access Temporary Exceptions (cf. http://developer.apple.com/library/mac/#documentation/Miscellaneous/Reference/EntitlementKeyReference/AppSandboxTemporaryExceptionEntitlements/AppSandboxTemporaryExceptionEntitlements.html). These keys describe the folders in which you want to read/write files, either relative to user home folder or absolute. Here is an example to read any files inside the /Users folder: keycom.apple.security.temporary-exception.files.absolute-path.read-only/key array string/Users//string /array Here is an example to read and write any files inside the user home: keycom.apple.security.temporary-exception.files.home-relative-path.read-write/key array string//string /array Regards, Laurent Etiemble. 2011/10/31 James Merkel jmerk...@mac.com Reading the sandboxing documents, it looks like in order to write to a file you need to use the save dialog. My app updates files without the save dialog. Will that be permitted in a sandboxed app ? Jim Merkel ___ 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/laurent.etiemble%40gmail.com This email sent to laurent.etiem...@gmail.com ___ 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
Re: Write to file Entitlement
On Nov 1, 2011, at 11:37 AM, Laurent Daudelin wrote: On Nov 1, 2011, at 11:00, James Merkel wrote: Why would someone want to base their application on the tenuous availability of a temporary exception ? Jim Merkel On Nov 1, 2011, at 10:30 AM, Laurent Etiemble wrote: Hello, In a sandboxed application, you can read/write files without the save dialog by using the File Access Temporary Exceptions (cf.http://developer.apple.com/library/mac/#documentation/Miscellaneous/Reference/EntitlementKeyReference/AppSandboxTemporaryExceptionEntitlements/AppSandboxTemporaryExceptionEntitlements.html). These keys describe the folders in which you want to read/write files, either relative to user home folder or absolute. Here is an example to read any files inside the /Users folder: keycom.apple.security.temporary-exception.files.absolute-path.read-only/key array string/Users//string /array Here is an example to read and write any files inside the user home: keycom.apple.security.temporary-exception.files.home-relative-path.read-write/key array string//string /array Well, I maintain a synchronization tool. For me, that seems like a reasonable solution. Each time the user decides to synchronize 2 folders, I could just use a temporary exception. -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.com Your're assuming the temporary exception will always be granted. Jim Merkel ___ 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
Re: Write to file Entitlement
That will completely break my app. Off the top of my head, I don't know how I would change things to conform to that regime. I update files in a batch mode. Jim Merkel On Oct 30, 2011, at 11:39 PM, Gideon King wrote: If you are writing to somewhere inside the sandbox, you can read and write freely, but if outside, then you have to go through the save panel, which behind the scenes stretches your sandbox to include that file. Regards Gideon On 31/10/2011, at 3:27 PM, James Merkel wrote: Reading the sandboxing documents, it looks like in order to write to a file you need to use the save dialog. My app updates files without the save dialog. Will that be permitted in a sandboxed app ? Jim Merkel ___ 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/gideon%40novamind.com This email sent to gid...@novamind.com ___ 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
C struct and __unsafe_unretained
The document on ARC talks about problematic C structs like:
struct x { NSString *S; int X; } StaticArray[] = {
@foo, 42,
@bar, 97,
...
};
I use that pattern quite a bit in my code and haven't had any problems with it.
These are basically constant strings that never change.
With ARC, the compiler wants me to change the code to:
struct x { __unsafe_unretained NSString *S; int X; }
Aside from this looking really ugly, will the App store accept this in an
application?
The document on ARC says in order to do this task correctly, the code should be
changed to a class. Ok, what class are they talking about?
I don't see how the collection classes like NSDictionary or NSArray support
this. Do they mean create your own collection class to do this?
Thanks for any insight on this.
Jim Merkel
___
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
Re: C struct and __unsafe_unretained
On Oct 30, 2011, at 10:41 AM, Charles Srstka wrote:
On Oct 30, 2011, at 12:32 PM, James Merkel wrote:
struct x { NSString *S; int X; } StaticArray[] = {
@foo, 42,
@bar, 97,
...
};
I use that pattern quite a bit in my code and haven't had any problems with
it. These are basically constant strings that never change.
With ARC, the compiler wants me to change the code to:
struct x { __unsafe_unretained NSString *S; int X; }
Aside from this looking really ugly, will the App store accept this in an
application?
The document on ARC says in order to do this task correctly, the code should
be changed to a class. Ok, what class are they talking about?
They’re talking about:
@interface MyClass : NSObject
@property (strong) NSString *someString;
@property NSInteger someInteger;
@end
Charles
Thanks. That looks easy enough.
Jim Merkel___
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
Re: C struct and __unsafe_unretained
Ok thanks. Not changing anything is the easiest and safest approach.
Jim Merkel
On Oct 30, 2011, at 10:52 AM, Dave Zarzycki wrote:
On Oct 30, 2011, at 10:32 AM, James Merkel wrote:
The document on ARC talks about problematic C structs like:
struct x { NSString *S; int X; } StaticArray[] = {
@foo, 42,
@bar, 97,
...
};
I use that pattern quite a bit in my code and haven't had any problems with
it. These are basically constant strings that never change.
Is the above pattern in your code used with globals? (Probably.)
With ARC, the compiler wants me to change the code to:
struct x { __unsafe_unretained NSString *S; int X; }
Aside from this looking really ugly, will the App store accept this in an
application?
Yes. __unsafe_unretained is public API, therefore the App store will accept
it.
The document on ARC says in order to do this task correctly, the code should
be changed to a class. Ok, what class are they talking about?
That depends on the scenario. If the above struct is simply a global (and it
probably is), then changing to a class would be more complicated than just
using __unsafe_unretained. If the above struct is stored in malloc()ed
memory, then switching to a class is the right thing to do.
davez
I don't see how the collection classes like NSDictionary or NSArray support
this. Do they mean create your own collection class to do this?
Thanks for any insight on this.
Jim Merkel
___
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/zarzycki%40apple.com
This email sent to zarzy...@apple.com
___
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
Write to file Entitlement
Reading the sandboxing documents, it looks like in order to write to a file you need to use the save dialog. My app updates files without the save dialog. Will that be permitted in a sandboxed app ? Jim Merkel ___ 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
Future for Mac applications
As of November, all applications submitted to the App store must be sandboxed and signed. Not too difficult to forecast the future here. Will it be for an application to run on a Mac it will need to sandboxed and signed ? Jim Merkel ___ 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
Re: Future for Mac applications
Kyle Sluder kyle.slu...@gmail.com wrote: We all know that Apple will not comment on future plans. It might not be a good idea to encourage rampant speculation on this list. But as it stands right now, it's worth remembering that code signing and sandboxing are orthogonal technologies, and sandboxing clearly hasn't been nailed down yet. Not sure why you're saying they are orthogonal. In order to sandbox an App you need to sign it. One thing's for sure, whenever security people get involved with something, stasis sets in. Jim Merkel ___ 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
Re: NSImageView vs IKImageView
On Aug 6, 2011, at 6:26 PM, Graham Cox wrote: On 06/08/2011, at 10:44 PM, James Merkel wrote: True, I could just update the window. But that seemed like more work than just going through the closing/opening cycle. If this seems even remotely true, you're surely doing it wrong. Incidentally, IKImageView/NSImageVIew should handle this for you - if you change the image they are displaying, they will invalidate and update the relevant part of the window automatically. Again, if that's not happening, you're surely doing it wrong. --Graham No it wasn't updating of the image that was the problem -- it was updating of some text boxes in the same window. But I have fixed that. I just needed an update method for the window. Now it looks very smooth, So now I will probably just go back to using the NSImageView. The IKImageView was an overkill for what I'm doing. Jim Merkel ___ 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
Re: NSImageView vs IKImageView
On Aug 7, 2011, at 5:17 AM, Graham Cox wrote: On 07/08/2011, at 4:56 PM, James Merkel wrote: updating of some text boxes in the same window. But I have fixed that. I just needed an update method for the window No you don't. Updating a text box is also automatic. There's almost never a reason to update a window, views that come from Cocoa handle that for you when their content changes. Views you write yourself just needs to invoke [NSView setNeedsDisplay:YES], and you're done. Your implementation seems to be built on faulty assumptions about how views/windows work, which in turn suggests you haven't read the documentation: http://developer.apple.com/library/mac/#documentation/Cocoa/ Conceptual/CocoaViewsGuide/Introduction/Introduction.html One thing that does seem odd however with Apple's docs is that it's really hard to find a simple two-line explanation anywhere of how views get drawn (i.e. how windows are updated). The Views Programming Guide above already seems to assume you know that, and the Cocoa Fundamentals Guide doesn't get that far, as far as I could tell. I'm sure I've seen it written down somewhere, but as I say, it's hard to find. If that's true then this is a glaring hole in the documentation, which might go some way to explain why so many on this list don't seem to have these concepts very clear. --Graham That document you referenced has some very useful information that I haven't seen before. I had concluded the view hierarchy was similar to what is shown therein, but I just found that out by trial and error. It's difficult to get your arms around all of the documentation you need to know in order to do a task. Just reading the class references doesn't get you there. Possibly what I'm doing in the update is not exactly correct -- I'll review that document in more detail to determine. Thanks, Jim Merkel ___ 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
Re: NSImageView vs IKImageView
On Aug 6, 2011, at 3:58 AM, Graham Cox wrote: On 06/08/2011, at 7:07 AM, James Merkel wrote: In my app, I accept edits in a window, save the edits to a file, close the window, then reopen the window to show the changes. With an NSImageView, you get an annoying flash when the window closes and then opens again. With an IKImageView you don't get the flash -- you can barely tell that the window has closed and opened again. Much better appearance- wise. I am not sure why there is this difference between the two. A better question is why on earth do you need to close the window and reopen it to show the changes? That's just bizarre. --Graham True, I could just update the window. But that seemed like more work than just going through the closing/opening cycle. I'll look into it. Jim Merkel ___ 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
NSImageView vs IKImageView
As a follow on to a previous thread on thumbnails, I finally settled on using Image I/O for creating a thumbnail from a file using a CGImageRef. However I could still use an NSImageView or an IKImageView to display the image. NSImageView requires converting the CGImageRef to an NSImage, with a few lines of code, whereas a CGImageRef can be set directly into the IKImageView. Generally the NSImageView approach uses a lot less memory than IKImageView, and also the IKImageView seems to leak memory. (Although Instruments Leaks doesn't show the leaks.) So NSImageView seems the way to go, however there is one nice side effect for the IKImageView. In my app, I accept edits in a window, save the edits to a file, close the window, then reopen the window to show the changes. With an NSImageView, you get an annoying flash when the window closes and then opens again. With an IKImageView you don't get the flash -- you can barely tell that the window has closed and opened again. Much better appearance- wise. I am not sure why there is this difference between the two. So that's my conclusion -- if you just need thumbnails (with no image editing other than scaling and rotation) use Image I/O. Jim Merkel ___ 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
Re: Fastest high-quality thumbnail display
On Jul 31, 2011, at 4:32 AM, Michael Babin wrote: On Jul 30, 2011, at 9:10 PM, James Merkel wrote: I tried ImageKit and it works great. Excellent quality. Thanks for the suggestion, Scott. I didn't have to do much more than change an NSImageView to an IKImageView in InterfaceBuilder and the code. However, there doesn't appear to be an easy way to print a CGImageRef (which you get from an IKImageView) . So I figure for the printing case, I'll just open the file again and create an NSImage. Seems counterintuitive to open the file again, but its' probably easier than converting a CGImageRef to an NSImage. Interestingly, the quality of the printed NSImage is very good compared to the screen rendition. Never understood why that is. For 10.6 and later, you can use -[NSImage initWithCGImage:size:] to create an NSImage from a CGImageRef. For 10.5 and later, you can create an NSBitmapImageRep from your CGImageRef (-[NSBitmapImageRep initWithCGImage:]) and add the representation to an NSImage. Ok, I found the NSBitmapImageRep method for 10.5. So I can now print. However, one problem -- the image does not get rotated to the proper orientation. ImageKit does this automatically for the screen image. I was hoping to get rid of my rotation code, but maybe I have to keep it for the printed image. Jim Merkel ___ 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
Re: Fastest high-quality thumbnail display
Thanks, I'll take a look at IK. I also found an Apple example application called ImageApp. It seems to work fine. No memory leaks. The approach for using CIImage seems to be to draw directly to an NSView rather than going to an NSImageView. Jim Merkel On Jul 29, 2011, at 11:46 PM, Scott Anguish wrote: If you want to display many thumbnails (or images in general) why not use the ImageKit? It’s what it was designed for. Check out IK* files. “The IKImageBrowserView class is a view for displaying and browsing a large amount of images and movies efficiently.” On Jul 25, 2011, at 3:04 PM, James Merkel wrote: What is the fastest way to generate and display a thumbnail from a digital camera file? In the past I used NSImage -- however the quality (with JPEG files) leaves something to be desired. Now I am using CIImage with Lanczos scale transform -- quality is very good but it is slow (particularly with raw files). Should I be using the thumbnail capability of Image I/O? Will it have as good a quality as CIImage, but be faster? I am comparing the speed of my app (running in Xcode) with the speed of Preview. Preview is much faster ( 2x or 3X). I wonder what they are doing. Of course the fastest way to display a thumbnail is to use the thumbnail in the file (assuming there is one). But that's the problem, there may not be a thumbnail in the file, in which case you need to create one yourself. Thanks for any help, Jim Merkel ___ 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/scott%40cocoadoc.com This email sent to sc...@cocoadoc.com ___ 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
Re: Fastest high-quality thumbnail display
I tried ImageKit and it works great. Excellent quality. Thanks for the suggestion, Scott. I didn't have to do much more than change an NSImageView to an IKImageView in InterfaceBuilder and the code. However, there doesn't appear to be an easy way to print a CGImageRef (which you get from an IKImageView) . So I figure for the printing case, I'll just open the file again and create an NSImage. Seems counterintuitive to open the file again, but its' probably easier than converting a CGImageRef to an NSImage. Interestingly, the quality of the printed NSImage is very good compared to the screen rendition. Never understood why that is. Jim Merkel On Jul 30, 2011, at 8:12 AM, James Merkel wrote: Thanks, I'll take a look at IK. I also found an Apple example application called ImageApp. It seems to work fine. No memory leaks. The approach for using CIImage seems to be to draw directly to an NSView rather than going to an NSImageView. Jim Merkel On Jul 29, 2011, at 11:46 PM, Scott Anguish wrote: If you want to display many thumbnails (or images in general) why not use the ImageKit? It’s what it was designed for. Check out IK* files. “The IKImageBrowserView class is a view for displaying and browsing a large amount of images and movies efficiently.” On Jul 25, 2011, at 3:04 PM, James Merkel wrote: What is the fastest way to generate and display a thumbnail from a digital camera file? In the past I used NSImage -- however the quality (with JPEG files) leaves something to be desired. Now I am using CIImage with Lanczos scale transform -- quality is very good but it is slow (particularly with raw files). Should I be using the thumbnail capability of Image I/O? Will it have as good a quality as CIImage, but be faster? I am comparing the speed of my app (running in Xcode) with the speed of Preview. Preview is much faster ( 2x or 3X). I wonder what they are doing. Of course the fastest way to display a thumbnail is to use the thumbnail in the file (assuming there is one). But that's the problem, there may not be a thumbnail in the file, in which case you need to create one yourself. Thanks for any help, Jim Merkel ___ 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/scott %40cocoadoc.com This email sent to sc...@cocoadoc.com ___ 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
Re: Fastest high-quality thumbnail display
On Jul 26, 2011, at 1:39 AM, Mike Abdullah wrote: On 26 Jul 2011, at 01:55, James Merkel wrote: Well, I see I have a huge memory leak in CIImage. However, I don't see where my code is in error. Also, according to Instruments Object Allocation, ImageIO is holding this memory. So I guess Core Image calls IImageIO. Yes, since ImageIO's job is to read and write images, Core Image uses it to do that portion of its work. Yeah, it looks like I can't use CIImage because of the memory leak. Every time an image is opened, the memory footprint increases by the size of the image. Using CIImage was kind of a cul-de-sac. So now it looks like I have to use CGImage and figure out how to get a CGImageRef into an NSImageView which is ultimately how the image is displayed. Jim Merkel ___ 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
Re: Fastest high-quality thumbnail display
On Jul 26, 2011, at 7:34 AM, Kyle Sluder wrote: On Jul 26, 2011, at 7:04 AM, James Merkel jmerk...@mac.com wrote: Yeah, it looks like I can't use CIImage because of the memory leak. Every time an image is opened, the memory footprint increases by the size of the image. Using CIImage was kind of a cul-de-sac. I don't see how this is unexpected behavior. You opened an image; shouldn't the image be in memory? So now it looks like I have to use CGImage and figure out how to get a CGImageRef into an NSImageView which is ultimately how the image is displayed. I'm pretty sure all image loading in the frameworks is done with ImageIO. You're not going to escape it by using CGImage. Can you explain more about why you think this is a problematic leak and how it adversely affects you? You might also try posting on quartz-dev. --Kyle Sluder I should have been more precise, namely: Every time an image is opened and *closed*, the memory footprint increases by the size of the image. For example, if a 27.5 MB image is opened and closed 10 times, you end up with a memory footprint that has gown by 275 MB. The memory never gets freed up. This is a problem related to a CIImage memory leak and was discussed a few years ago. Do a Google search or archives search with the terms CIImage memory leak (without quotes). Actually, I don't think the problem is in ImageIO -- I was just referring to Instruments Object Allocations wherein if you click on the offending GeneralBlock, Instruments says the Responsible Library is ImageIO. Jim Merkel ___ 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
Fastest high-quality thumbnail display
What is the fastest way to generate and display a thumbnail from a digital camera file? In the past I used NSImage -- however the quality (with JPEG files) leaves something to be desired. Now I am using CIImage with Lanczos scale transform -- quality is very good but it is slow (particularly with raw files). Should I be using the thumbnail capability of Image I/O? Will it have as good a quality as CIImage, but be faster? I am comparing the speed of my app (running in Xcode) with the speed of Preview. Preview is much faster ( 2x or 3X). I wonder what they are doing. Of course the fastest way to display a thumbnail is to use the thumbnail in the file (assuming there is one). But that's the problem, there may not be a thumbnail in the file, in which case you need to create one yourself. Thanks for any help, Jim Merkel ___ 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
Re: Fastest high-quality thumbnail display
Well, I see I have a huge memory leak in CIImage. However, I don't see where my code is in error. Also, according to Instruments Object Allocation, ImageIO is holding this memory. So I guess Core Image calls IImageIO. I'll have to look at this in more detail. Jim Merkel On Jul 25, 2011, at 3:58 PM, Mike Abdullah wrote: On 25 Jul 2011, at 20:04, James Merkel wrote: What is the fastest way to generate and display a thumbnail from a digital camera file? In the past I used NSImage -- however the quality (with JPEG files) leaves something to be desired. Now I am using CIImage with Lanczos scale transform -- quality is very good but it is slow (particularly with raw files). Lanczos is high quality and slow, no way around that. Should I be using the thumbnail capability of Image I/O? Will it have as good a quality as CIImage, but be faster? Yes, you should be using it. It won't be as high quality as CIImage though. I am comparing the speed of my app (running in Xcode) with the speed of Preview. Preview is much faster ( 2x or 3X). I wonder what they are doing. Of course the fastest way to display a thumbnail is to use the thumbnail in the file (assuming there is one). But that's the problem, there may not be a thumbnail in the file, in which case you need to create one yourself. That's exactly what ImageIO offers you; the ability to use embedded thumbnail if present. ___ 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
Re: Adding Spotlight comment data to folder/file
On Mon, 11 Jul 2011 19:51:28 -0700 Kyle Sluder kyle.slu...@gmail.com wrote: Like I said, Apple designed that field for the sole use of the user. Not that your intended feature wouldn't be helpful, but a user who stumbled upon the output of your program occupying that slot might wrongly conclude that it exists for the purpose of programs to store information, not their own personal note. Apple themselves seems to violate that -- for example Image Capture has the option of putting in spotlight comments when you download images. Jim Merkel ___ 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
Re: dealloc and scarce resources
On Jun 29, 2011, at 11:07 PM, Kyle Sluder wrote: On Wed, Jun 29, 2011 at 10:38 PM, James Merkel jmerk...@mac.com wrote: Ok, thanks. For what I'm doing file descriptors are not a scarce resource. File descriptors are almost always a scarce resource. By default, each process only gets 256 of them. --Kyle Sluder Ok, I'm looking at my application in Instruments File Activity. The column labeled FD I assume means file descriptors. Is that the total number of FDs in use at any given time? Jim Merkel ___ 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
Re: dealloc and scarce resources
On Jun 30, 2011, at 2:01 AM, Ken Thomases wrote: On Jun 30, 2011, at 3:02 AM, Jean-Daniel Dupas wrote: Le 30 juin 2011 à 08:19, James Merkel a écrit : Ok, I'm looking at my application in Instruments File Activity. The column labeled FD I assume means file descriptors. Is that the total number of FDs in use at any given time? No, Just like process ID, file descriptor number can be reused by the system. That analogy is a bit flawed. Process IDs are global across the system. File descriptors are per-process. And there is absolutely no guarantee the system use simple incremental value for fd AFAIK. Actually, when a new file descriptor is created for your process, it does use the lowest unused descriptor number (except for dup2()). Still, the File Activity instrument's event list isn't showing a count of file descriptors, it's showing the specific individual file descriptor involved in the specific event. But there's a pretty good chance that the highest file descriptor you see across a significant range of events roughly indicates the count of open descriptors. Regards, Ken That's kind of what I concluded -- that the FD is roughly the current number of file descriptors. I noticed that sometimes the FD shows -1, but that's only in a transient condition. I attribute that to Instruments not being able to keep up. It never settles down to -1. After a fair amount of application warm-up the FD shows 25 to 26. So, I assume I'm ok. The FD has a pattern similar to memory in use. It grows for a while when you start and use an application, then settles out to some value. If it grows continually I guess you have a problem. In order not to get a fire-hose amount of data, you can type in a file-name (or some other identifier) into the spotlight-like magnifier box in the lower right corner of the Instruments window. Then you are looking at only files of interest. Again this sort of works, but Instruments still may not show everything. Jim Merkel___ 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
Re: dealloc and scarce resources
On Jun 30, 2011, at 9:20 AM, James Merkel wrote: On Jun 30, 2011, at 2:01 AM, Ken Thomases wrote: On Jun 30, 2011, at 3:02 AM, Jean-Daniel Dupas wrote: Le 30 juin 2011 à 08:19, James Merkel a écrit : Ok, I'm looking at my application in Instruments File Activity. The column labeled FD I assume means file descriptors. Is that the total number of FDs in use at any given time? No, Just like process ID, file descriptor number can be reused by the system. That analogy is a bit flawed. Process IDs are global across the system. File descriptors are per-process. And there is absolutely no guarantee the system use simple incremental value for fd AFAIK. Actually, when a new file descriptor is created for your process, it does use the lowest unused descriptor number (except for dup2()). Still, the File Activity instrument's event list isn't showing a count of file descriptors, it's showing the specific individual file descriptor involved in the specific event. But there's a pretty good chance that the highest file descriptor you see across a significant range of events roughly indicates the count of open descriptors. Regards, Ken That's kind of what I concluded -- that the FD is roughly the current number of file descriptors. I noticed that sometimes the FD shows -1, but that's only in a transient condition. I attribute that to Instruments not being able to keep up. It never settles down to -1. After a fair amount of application warm-up the FD shows 25 to 26. So, I assume I'm ok. The FD has a pattern similar to memory in use. It grows for a while when you start and use an application, then settles out to some value. If it grows continually I guess you have a problem. In order not to get a fire-hose amount of data, you can type in a file-name (or some other identifier) into the spotlight-like magnifier box in the lower right corner of the Instruments window. Then you are looking at only files of interest. Again this sort of works, but Instruments still may not show everything. Jim Merkel After looking some more at Instruments File Activity, I see that the FD can end up in a static state with an FD of -1. I'm not sure what that means. However I think Ken Thomases' statement is correct: Still, the File Activity instrument's event list isn't showing a count of file descriptors, it's showing the specific individual file descriptor involved in the specific event. But there's a pretty good chance that the highest file descriptor you see across a significant range of events roughly indicates the count of open descriptors. You can sort on the FD column and find the largest FD, so that's pretty easy to find. I notice that the Instruments documentation (User Guide) doesn't explain these things, at least as far as I could tell. Maybe you're just supposed to know this (from birth I guess). Jim Merkel ___ 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
Re: dealloc and scarce resources
On Jun 30, 2011, at 12:04 PM, Kyle Sluder wrote: On Thu, Jun 30, 2011 at 9:20 AM, James Merkel jmerk...@mac.com wrote: After a fair amount of application warm-up the FD shows 25 to 26. So, I assume I'm ok. And what happens when (not if) you introduce a leak, and these objects live longer than you expect them to? Or worse, someone else starts holding on to these objects? You're already using an -invalidate method. You just happened to call it -dealloc. Why not follow good defensive programming practice and make it explicit to save yourself future headaches? --Kyle Sluder Ok, I don't know what an -invalidate method is, but I'll look it up. Jim Merkel ___ 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
Re: dealloc and scarce resources
On Jun 30, 2011, at 12:21 PM, Kyle Sluder wrote: On Thu, Jun 30, 2011 at 12:12 PM, James Merkel jmerk...@mac.com wrote: Ok, I don't know what an -invalidate method is, but I'll look it up. It's the thing Wim talked about. An explicit way to release the scarce resource you're holding on to. Depending on what that resource is, an appropriate name might be -close, or -invalidate, or -terminate. --Kyle Sluder I saw that in Wlm's post. However, I'm not sure where I would do that. I'll have to think about it some more. By the way my original post referred to the Memory Management Programming Guide and the statement: You should typically not manage scarce resources such as file descriptors, network connections, and buffers or caches in a dealloc method. I was pretty sure that file descriptors referred to something at a lower level, but wasn't sure. Maybe I'm being pedantic, but Apple could have helped things along by saying: You should typically not manage scarce resources such as Unix file descriptors, ... Everyone doesn't approach this stuff with the same background. We find from Kernighan and Ritchie (KR) second edition, section 8.1 that a file descriptor is a small non-negative integer that refers to a file and is maintained by the system. So, my guess is that when Instruments shows an FD of -1 it refers to an FD that isn't mine. But that's just a guess. Instruments doesn't document this as far as I know. Jim Merkel ___ 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
Re: dealloc and scarce resources
On Jun 30, 2011, at 6:39 PM, Kyle Sluder wrote: On Thu, Jun 30, 2011 at 6:34 PM, James Merkel jmerk...@mac.com wrote: Then wherever I was sending the -release, I need to also send a separate -close. it could be before or after the release, it doesn't really matter. No, it really needs to be before the -release. When you call -release, you relinquish your ownership of that object. It may cease to exist at that point. It may continue to live for an indeterminate amount of time. But either way, yes, it's one method call, done before the call to -release. --Kyle Sluder Ok, doing the -close first makes more sense. ___ 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
dealloc and scarce resources
In another thread, someone referenced the Memory Management Programming Guide: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ MemoryMgmt/Articles/mmPractical.html%23//apple_ref/doc/uid/ TP40004447-1000922-BABBFBGJ In the Guide it says: You should typically not manage scarce resources such as file descriptors, network connections, and buffers or caches in a dealloc method. In particular, you should not design classes so that dealloc will be invoked when you think it will be invoked. Invocation of dealloc might be delayed or sidestepped, either because of a bug or because of application tear-down. Instead, if you have a class whose instances manage scarce resources, you should design your application such that you know when you no longer need the resources and can then tell the instance to “clean up” at that point. You would typically then release the instance, and dealloc would follow, but you will not suffer additional problems if it does not. In my code I close a file in the dealloc method -- so I guess that's a file descriptor. I opened the file in the init method, so it seemed logical to close it in the dealloc method. Also, not to be facetious, if I have a bug in my code, wouldn't I fix it? Granted, at application tear-down, if the file is still open, it won't be closed because dealloc won't be called. But again that comes under the heading of a bug in the code. So I don't understand this injunction. Jim Merkel___ 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
Re: dealloc and scarce resources
On Jun 29, 2011, at 7:17 PM, Wim Lewis wrote: On 29 Jun 2011, at 5:43 PM, James Merkel wrote: In the [Memory Management Programming Guide] it says: You should typically not manage scarce resources such as file descriptors, network connections, and buffers or caches in a dealloc method. In particular, you should not design classes so that dealloc will be invoked when you think it will be invoked. Invocation of dealloc might be delayed or sidestepped, either because of a bug or because of application tear-down. Instead, if you have a class whose instances manage scarce resources, you should design your application such that you know when you no longer need the resources and can then tell the instance to “clean up” at that point. You would typically then release the instance, and dealloc would follow, but you will not suffer additional problems if it does not. In my code I close a file in the dealloc method -- so I guess that's a file descriptor. I opened the file in the init method, so it seemed logical to close it in the dealloc method. Also, not to be facetious, if I have a bug in my code, wouldn't I fix it? Granted, at application tear-down, if the file is still open, it won't be closed because dealloc won't be called. But again that comes under the heading of a bug in the code. So I don't understand this injunction. I don't think it should be treated as a hard rule, but I think it is good advice most of the time, or at least a good starting position. One way to look at it is that for most objects you're not supposed to assume very much about their lifetime. You know they exist as long as you have a refcount to them, but they *may* continue to exist after you release them. This is the semantic of -release. You may happen to know, in a particular piece of code, that you have the only reference to something and it will be dealloced with a given release. But thinking of release as equivalent to dealloc will get you into trouble. Even ignoring GC (which makes dealloc/finalize even more uncertain), you might end up stashing a reference to that object somewhere else, extending its lifetime. Maybe it's in an NSNotification or an undo stack or a debug log, or there's a situation where your autorelease pool lasts longer than you expect (perhaps you are dealing with a bunch of files in a loop as you load or save a document, eg). In my experience it isn't *usually* a problem of leaking the file handles entirely; it's a problem if I temporarily accumulate too many of them, or if I need the file handle (or socket or...) to be closed before I do some operation, and simply calling -release isn't normally a guarantee of that. My preferred approach is to have a -close or -invalidate method that releases resources, breaks retain cycles, etc.. If -invalidate isn't called before dealloc, that's OK, but I can also call -invalidate explicitly if I know I want to tear down the object at a given time. I think there are cases where the indefinite lifetime *is* what you want, if you have objects that can lazily fault something in from disk, or which encapsulate a sharable server connection, or etc. But those objects should be the exception, so that you can be especially aware of lifecycle issues in any code that deals with them. And even so, I usually end up having to give them an -invalidate method eventually, to deal with some odd situation. I guess I do think of the delloc being called as a result of my release -- and that seems to be the way it is working. The approach I'm using now is to open the file in an init method, then read a few 100 bytes of header in another method, then find pointers to read other portions of the file and read some more data, then close the file in the dealloc method. Lazy loading of data is an Objective - C/Cocoa pattern. The alternative would be to open the file, read the entire file, and close it in the init method. I guess this is the approach used by NS methods such as: initWithContentsOfFile, etc. However, the file could be megabytes in size, and so this would be considerably slower. Another alternative would be to not use a class but just use C functions to do this, but that wouldn't be a Cocoa pattern at all. Bottom line though, what are the consequences of leaving a file open? When does it finally get closed? Jim Merkel___ 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
Re: dealloc and scarce resources
On Jun 29, 2011, at 9:47 PM, Quincey Morris wrote: On Jun 29, 2011, at 17:43, James Merkel wrote: You should typically not manage scarce resources such as file descriptors, network connections, and buffers or caches in a dealloc method. In particular, you should not design classes so that dealloc will be invoked when you think it will be invoked. Invocation of dealloc might be delayed or sidestepped, either because of a bug or because of application tear-down. Instead, if you have a class whose instances manage scarce resources, you should design your application such that you know when you no longer need the resources and can then tell the instance to “clean up” at that point. You would typically then release the instance, and dealloc would follow, but you will not suffer additional problems if it does not. In my code I close a file in the dealloc method -- so I guess that's a file descriptor. I opened the file in the init method, so it seemed logical to close it in the dealloc method. It's only logical to close the file descriptor in dealloc if it's not a scarce resource. The word scarce is vital to this question. Here's a simple (though contrived) example. Suppose you have a loop that's compressing image files. In each iteration of the loop, you open one file for reading and create a new file from it. Let's suppose you've invented objects to represent the source and destination files, and each of these object contains a file descriptor for its open file. It's not hard to imagine, for example, that for unrelated reasons your file-reading object ends up in the autorelease pool. Thus, these objects will build up till the loop exits. If you free the file descriptor in dealloc, and you have to convert 100,000 files, you're going to need 100,000 file descriptors, because you can't recycle file descriptors because dealloc isn't being called until the end of the whole operation. That obviously isn't going to work, since the kernel can create only a very limited number of simultaneous file descriptors. In this case, the recommended solution is to give your object a 'releaseResources' method that will free up its file descriptor. This is the scenario that the above warning is talking about. Note that if scarcity isn't an issue, if there could be as many simultaneous file descriptors as you choose to create, then this pattern isn't necessary***. In real life applications, causes of deferral of dealloc can be really hard to figure out deterministically. Thus it can be hard to know whether you *need* a 'releaseResources' pattern or not. That's why the recommendation is couched in terms of such general applicability. [What the warning doesn't say, though, is that the opposite problem exists too. It can be *very* hard to determine when to call 'releaseResources', a problem which carries over into the GC world too.] Also, not to be facetious, if I have a bug in my code, wouldn't I fix it? I think it's referring to the kind of bug where the object is lifetime is extended by an inscrutable chain of dependencies. If your design uses an implicit release-resource-on-dealloc pattern, it can be very hard to work out where to intervene, so the bug may be for all intents and purposes unfixable. Granted, at application tear-down, if the file is still open, it won't be closed because dealloc won't be called. But again that comes under the heading of a bug in the code. So I don't understand this injunction. Actually, at application tear-down, things like file descriptors are irrelevant, because they're destroyed automatically with your process. However, there are things with more global visibility, such as a system-wide cache, or a network login, that destruction of your process may leak. So, application tear-down tends to be the site of fewer problems, but resource management is still something that needs to be thought through. ***Actually, it may be necessary even then. *Your* application might not care if the file descriptors aren't freed until much later, but you might also be preventing other applications from gaining exclusive access to the files for some other purpose, so you'll lock out such applications possibly for hours. This is still a case of scarcity, just a different kind of scarcity. Ok, thanks. For what I'm doing file descriptors are not a scarce resource. Also, I didn't know file descriptors are destroyed at application tear-down. ___ 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
Re: Reading Adobe Photoshop header, Obj-C
Kevin, As others have suggested you probably want to step down to more basic C coding to handle this task. You can just use C library functions to read data from the file: fopen(), fseek(), fread(), fgetc(), fclose() etc. as discussed in Kernighan and Ritchie. As far as big endian, little endian issues, most image files use the convention 'MM' for big endian or 'II' for little endian somewhere in the first few bytes of the file. You then need to load the data accordingly. For example looking at a Photoshop Elements file, I see MM' (two ASCII characters) as the first two bytes of the file, announcing that the file is big endian. A tool that may be helpful for you in looking at file data directly is a Hex Editor. I use HexEdit which is freeware. Beware-- a Hex Editor is a sharp tool, you can open any file on your system and modify it. Jim Merkel ___ 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
Re: Reading Adobe Photoshop header, Obj-C
On Jun 28, 2011, at 4:35 PM, John Joyce wrote: On Jun 28, 2011, at 6:18 PM, James Merkel wrote: Kevin, As others have suggested you probably want to step down to more basic C coding to handle this task. You can just use C library functions to read data from the file: fopen(), fseek(), fread(), fgetc(), fclose() etc. as discussed in Kernighan and Ritchie. As far as big endian, little endian issues, most image files use the convention 'MM' for big endian or 'II' for little endian somewhere in the first few bytes of the file. You then need to load the data accordingly. For example looking at a Photoshop Elements file, I see MM' (two ASCII characters) as the first two bytes of the file, announcing that the file is big endian. A tool that may be helpful for you in looking at file data directly is a Hex Editor. I use HexEdit which is freeware. Beware-- a Hex Editor is a sharp tool, you can open any file on your system and modify it. Jim Merkel Synalyzeit is a free hex editor that's fabulous. Thanks, I'll take a look at that. HexEdit is getting a little dated. Jim Merkel ___ 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
Re: Progress Indicators Spin vs Bar
Thanks to all that provided code examples and suggestions on programming for concurrency. I am reading the docs to learn more on this subject. Jim Merkel ___ 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
Re: Progress Indicators Spin vs Bar
Yeah, I just kind of avoided the basic problem. The app isn't receiving at least some events -- for example the menus can't be pulled down. On the other hand, the spinning beach ball doesn't appear, and I can drag the progress window around. I'll have to see if a cancel button will work. Of course putting the code in another thread would be a big change. Jim Merkel On Jun 20, 2011, at 1:14 AM, Kyle Sluder wrote: On Jun 20, 2011, at 12:36 AM, James Merkel jmerk...@mac.com wrote: It turns out if I use setUsesThreadedAnimation:YES on the progress indicator, the bar indicator animates. The docs say this method sets a hint as to whether the receiver should implement animation of the progress indicator in a separate thread. I guess the hint is taken and the animation is performed in a separate thread. You still haven't addressed the question of whether you're blocking the main thread. According to your pseudocode, you are. This is very bad. The spinning beach ball cursor will appear while your app is performing its long processing, and there will be no way for your app to receive any events from the user asking it to cancel. I look forward to the day when OS X automatically kills beachballing programs after a certain time, a la iOS. Because then maybe iTunes will finally get rewritten. --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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Progress Indicators Spin vs Bar
It turns out if I use setUsesThreadedAnimation:YES on the progress indicator, the bar indicator animates. The docs say this method sets a hint as to whether the receiver should implement animation of the progress indicator in a separate thread. I guess the hint is taken and the animation is performed in a separate thread. Jim Merkel On Jun 19, 2011, at 1:38 PM, James Merkel wrote: On Jun 19, 2011, at 1:27 PM, Quincey Morris wrote: On Jun 19, 2011, at 13:14, James Merkel wrote: ProgressController * progressController = nil; progressController =[[ProgressController alloc] init]; NSLog(@Progress window: %@\n, [progressController window]); [progressController startProgressAnimation]; [progressController showWindow:self]; (Long processing) [progressController close]; [progressController release]; So this works with the spinner but not the bar. Seems strange because I thought the two progress indicators would work the same. They don't. The spinning indicator animates itself, but the bar animation depends on run loop iterations to drive the animation. If Long processing means a loop, you're not going back to the run loop. In those circumstances you must arrange for events to be processed (run the run loop or dequeue events in a modal event loop). Note that you probably want to do that anyway, because you probably want to have a Cancel button on a long-running operation. Ok thanks -- I didn't realize there was a difference in the way the two progress indicators worked. ___ 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
Re: Progress Indicators Spin vs Bar
On Jun 20, 2011, at 2:01 AM, Mike Abdullah wrote: On 20 Jun 2011, at 09:31, James Merkel wrote: Yeah, I just kind of avoided the basic problem. The app isn't receiving at least some events -- for example the menus can't be pulled down. On the other hand, the spinning beach ball doesn't appear, and I can drag the progress window around. Window dragging is handled by the window server so that an unresponsive app can't affect it. Upon further investigation I see that the beach ball does finally appear. I guess the question is, what is the definition of unresponsive? An app will always have short unresponsive periods when it is doing something. Another question -- when should a progress indicator be put up? The length of time in my processing loop can very greatly. I could be processing 3 files or 300 files. It seems a waste to flash a progress indicator for very short processing cases. On the other hand I can't just set a threshold for putting up a progress indicator, since the processing period can very from one machine to another. Also the processing period varies for different file types and even varies on the same machine from run to run. No obvious answers to some of these questions. ___ 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
Re: Progress Indicators Spin vs Bar
On Jun 20, 2011, at 12:05 PM, Conrad Shultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/20/11 11:47 AM, James Merkel wrote: On Jun 20, 2011, at 2:01 AM, Mike Abdullah wrote: On 20 Jun 2011, at 09:31, James Merkel wrote: Yeah, I just kind of avoided the basic problem. The app isn't receiving at least some events -- for example the menus can't be pulled down. On the other hand, the spinning beach ball doesn't appear, and I can drag the progress window around. Window dragging is handled by the window server so that an unresponsive app can't affect it. Upon further investigation I see that the beach ball does finally appear. I guess the question is, what is the definition of unresponsive? An app will always have short unresponsive periods when it is doing something. Disclosure: I haven't really been following this thread (no pun intended) so I apologize if some of this has been said or is not applicable. Unresponsive means the main thread is blocked, i.e. it's not able to process events (e.g. keystrokes, clicks), update the UI, or even respond to a SIGTERM (hence the Force Quit - SIGKILL). Of course every action on the main thread takes SOME finite amount of time, but the idea is that a well designed program offloads any tasks that could potentially take a perceptible amount of time onto a secondary thread so that the main thread can proceed, the run loop turns over, etc. There are certain situations where either processing must occur on the main thread (classes in AppKit or UIKit that are designated non-thread-safe come to mind) or where a task cannot logically proceed until a task is completed (for example, if a data model needs to be loaded in order for the app to be useful). In such cases, at a minimum you want to have a progress indicator so that user doesn't think the app has crashed. You should also go to great lengths to try to still offload such activity so that you can have the main thread handle some UI to allow the operation to be canceled if it's taking longer than the user wants (think of the Stop button omnipresent in every web browser). Another question -- when should a progress indicator be put up? The length of time in my processing loop can very greatly. I could be processing 3 files or 300 files. It seems a waste to flash a progress indicator for very short processing cases. On the other hand I can't just set a threshold for putting up a progress indicator, since the processing period can very from one machine to another. Also the processing period varies for different file types and even varies on the same machine from run to run. No obvious answers to some of these questions. I would say that if a procedure can potentially take a perceptible amount of time, go ahead and display a progress indicator. If it's so quick that the user doesn't even see it, so be it. Check out how web browsers do it... even going to http://localhost in Safari or Firefox shows a progress indicator for a fleeting moment. I don't really understand what you mean by a waste. It would be _more_ code to conditionally display an indicator, and in the case where you would consider not putting one up it follows that you can't be taxing the processor too much, so it's not like you're going to be slowing things down appreciably. - -- Conrad Shultz Synthetiq Solutions www.synthetiqsolutions.com -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3/mewACgkQaOlrz5+0JdV9BwCcCv7VwQkBf3/TJO+rMVh/hbW7 IKgAoIiyiflPyQ2DL/GPzgwXP2IK58iA =Z5g/ -END PGP SIGNATURE- True it's extra code to conditionally display an indicator, so I may as well always display it. The bigger problem is putting the long process into another thread. Need to delve into that. Thanks, Jim Merkel ___ 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
Re: Progress Indicators Spin vs Bar
On Jun 20, 2011, at 2:05 PM, Greg Parker wrote: On Jun 20, 2011, at 11:47 AM, James Merkel wrote: Another question -- when should a progress indicator be put up? The length of time in my processing loop can very greatly. I could be processing 3 files or 300 files. It seems a waste to flash a progress indicator for very short processing cases. On the other hand I can't just set a threshold for putting up a progress indicator, since the processing period can very from one machine to another. Also the processing period varies for different file types and even varies on the same machine from run to run. No obvious answers to some of these questions. One solution is to simply start the operation with no displayed progress, then later show the progress if it has not finished in X seconds. (Programmatically: schedule a one-shot NSTimer for X seconds later that starts showing progress when it fires. When the operation finishes, cancel the timer if it has not fired already. Do this both of these on the main thread to avoid thread-safety problems.) Your app will feel faster if short operations appear to finish instantly instead of briefly flashing a progress bar. File operations in the Finder do something like this. On the other hand, you should always show progress if the operation has no user-visible side effects. Nothing is worse than displaying nothing and leaving the user to wonder whether it did anything at all. In this case you want the finished progress bar to appear as a confirmation to the user for at least some minimum length of time. True it's extra code to conditionally display an indicator, so I may as well always display it. The bigger problem is putting the long process into another thread. Need to delve into that. Yes, the work thread will be the hard part. Polishing the progress UI should be straightforward after that. -- Greg Parker gpar...@apple.com Runtime Wrangler I hadn't thought of that -- putting up a progress indicator after a short passage of time. Sounds like a better way to go. I am trying to come up with a way of not using threads (because of the potential problems). All I really want to do is give the user a way of canceling the long process. I was thinking of just sampling a cancel state variable every time through the loop. Of course that introduces overhead, and there's the possibility the user cancels on a particularly long duration loop cycle and wouldn't quickly see a response to his cancel. I would think there is some simpler method than using threads for handling this fairly common situation of a handling a long process. Jim Merkel ___ 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
Re: Progress Indicators Spin vs Bar
On Jun 20, 2011, at 3:33 PM, Conrad Shultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/20/11 3:17 PM, James Merkel wrote: I am trying to come up with a way of not using threads (because of the potential problems). All I really want to do is give the user a way of canceling the long process. I was thinking of just sampling a cancel state variable every time through the loop. Of course that introduces overhead, and there's the possibility the user cancels on a particularly long duration loop cycle and wouldn't quickly see a response to his cancel. I would think there is some simpler method than using threads for handling this fairly common situation of a handling a long process. Please don't do this. If the main thread is blocked by whatever your process is doing the UI will not respond. You won't be able to set a cancel state variable while the main thread is blocked - it's what handles responding to, e.g., button clicks! I'd say that in general your application should be event driven; let the run loop do its thing and handle events as appropriate. About the only time I can think of to use a state variable as you describe is in, for example, an NSOperation, to mark it as canceled. But such an operation would itself be running on a separate thread (most commonly). While we often make it sound scary, threading needn't be difficult to implement. You have GCD, you have NSOperation/NSOperationQueue; between the two you have quite a bit of power with minimal lines of code needed. Depending on what you need to do in your loop, it might be as simple as calling dispatch_async(). Of course, if you need to handle locking, mutual exclusion, thread coordination, etc., THEN threading can start to get tough, but it doesn't really sound like this applies to you. Can you remind me what you are trying to accomplish (broad overview)? - -- Conrad Shultz Synthetiq Solutions www.synthetiqsolutions.com -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3/ysUACgkQaOlrz5+0JdU97wCdGwNBFZKMCdTgHediaXlQumgf 3ZUAnjDaoQrFHxAghq48tDOFlm6NdVW4 =5gh7 -END PGP SIGNATURE- I guess that's right -- I'll never capture the user's cancel. I'm opening all digital camera files in a folder (JPEG, TIF, etc), extracting a thumbnail and some Exif data, and putting the data in a TableView. The time consuming part is finding the thumbnails in the files. Jim Merkel ___ 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
Re: Progress Indicators Spin vs Bar
On Jun 20, 2011, at 7:23 PM, Conrad Shultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/20/11 3:54 PM, James Merkel wrote:
I'm opening all digital camera files in a folder (JPEG, TIF, etc),
extracting a thumbnail and some Exif data, and putting the data in a
TableView. The time consuming part is finding the thumbnails in the
files.
OK.
I don't know anything about extracting thumbnails et al., but for the
sake of argument suppose you have a class JMImageProcessor that has
methods like:
- - (id)initWithFileHandle:(NSFileHandle *)fileHandle;
- - (NSDictionary *)exifData;
- - (NSImage *)thumbnail; // Takes a long time to run
So in your main thread you then have a loop over a bunch of
NSFileHandles (of course you might be accessing the files completely
differently; this is just for illustration). So you might currently
have:
for (NSFileHandle *fileHandle in files) {
JMImageProcessor *processor = [[JMImageProcessor alloc]
initWithFileHandle:fileHandle];
// Call some code to stash the results, presumably updating the
tableView's data source in the process
[self setExifData:[processor exifData] forFile:fileHandle];
[self setThumbnail:[processor thumbnail] forFile:fileHandle];
[processor release];
// Call some code to redisplay the NSTableView
[self updateTable];
}
You could make such code non-blocking with, for example, GCD:
dispatch_queue_t workerQueue =
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, NULL);
for (NSFileHandle *fileHandle in files) {
dispatch_async(workerQueue,
^{
JMImageProcessor *processor = [[JMImageProcessor alloc]
initWithFileHandle:fileHandle];
[self setExifData:[processor exifData]
forFile:fileHandle];
[self setThumbnail:[processor thumbnail]
forFile:fileHandle];
[processor release];
dispatch_async(dispatch_get_main_queue(),
^{
[self updateTable];
// UI updates need to be on the main
thread, i.e., the GCD main
queue, so we call back asynchronously
}
);
}
);
}
(Note 1: this was all written in a mail client and untested.)
(Note 2: the above assumes that the setExifData/setThumbnail methods
are
implemented properly, atomically if required. But if the methods are
backed by, for example, mutable dictionaries, and anything accessing
them handle absent entries reasonably, this should be pretty
straightforward.)
(Note 3: this could all alternatively be done with NSOperationQueue,
or
even plain old NSThread. But GCD can probably do it in the smallest
amount of code.)
Good luck!
- --
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFOAACvaOlrz5+0JdURAvzkAJ9XaQ4CqRXY4k6fKtRdVkqcYBeBewCeL8fh
jOJSgWEisHfOU6/WflFoukA=
=swOg
-END PGP SIGNATURE-
First of all (kind of basic) what is GCD ?
I have actually implemented this a couple of different ways (not using
threads).
At first I just had lazy loading of the TableView. Whenever the
TableView needed something a file was accessed and a thumbnail
extracted. Then I changed it to do preprocessing. That is, everything
was extracted from the files and then the TableView was allowed to
load. The first approach uses less memory but is slower in updating
the TableView (when it is scrolled for example). The second approach
uses more memory but is faster in updating (provides a better user
experience). I think trying to do this in a separate thread would be
much cleaner using the second approach.
I forgot to mention the really slow case: if a thumbnail can't be
found in the file, then I make a thumbnail from the main image. If
this has to be done on a lot of files, then things really bog down.
Jim Merkel
___
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
Re: Progress Indicators Spin vs Bar
On Jun 20, 2011, at 8:43 PM, James Merkel wrote:
On Jun 20, 2011, at 7:23 PM, Conrad Shultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/20/11 3:54 PM, James Merkel wrote:
I'm opening all digital camera files in a folder (JPEG, TIF, etc),
extracting a thumbnail and some Exif data, and putting the data in a
TableView. The time consuming part is finding the thumbnails in
the files.
OK.
I don't know anything about extracting thumbnails et al., but for the
sake of argument suppose you have a class JMImageProcessor that has
methods like:
- - (id)initWithFileHandle:(NSFileHandle *)fileHandle;
- - (NSDictionary *)exifData;
- - (NSImage *)thumbnail; // Takes a long time to run
So in your main thread you then have a loop over a bunch of
NSFileHandles (of course you might be accessing the files completely
differently; this is just for illustration). So you might
currently have:
for (NSFileHandle *fileHandle in files) {
JMImageProcessor *processor = [[JMImageProcessor alloc]
initWithFileHandle:fileHandle];
// Call some code to stash the results, presumably updating the
tableView's data source in the process
[self setExifData:[processor exifData] forFile:fileHandle];
[self setThumbnail:[processor thumbnail] forFile:fileHandle];
[processor release];
// Call some code to redisplay the NSTableView
[self updateTable];
}
You could make such code non-blocking with, for example, GCD:
dispatch_queue_t workerQueue =
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, NULL);
for (NSFileHandle *fileHandle in files) {
dispatch_async(workerQueue,
^{
JMImageProcessor *processor = [[JMImageProcessor alloc]
initWithFileHandle:fileHandle];
[self setExifData:[processor exifData]
forFile:fileHandle];
[self setThumbnail:[processor thumbnail]
forFile:fileHandle];
[processor release];
dispatch_async(dispatch_get_main_queue(),
^{
[self updateTable];
// UI updates need to be on the main
thread, i.e., the GCD main
queue, so we call back asynchronously
}
);
}
);
}
(Note 1: this was all written in a mail client and untested.)
(Note 2: the above assumes that the setExifData/setThumbnail
methods are
implemented properly, atomically if required. But if the methods are
backed by, for example, mutable dictionaries, and anything accessing
them handle absent entries reasonably, this should be pretty
straightforward.)
(Note 3: this could all alternatively be done with
NSOperationQueue, or
even plain old NSThread. But GCD can probably do it in the smallest
amount of code.)
Good luck!
- --
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFOAACvaOlrz5+0JdURAvzkAJ9XaQ4CqRXY4k6fKtRdVkqcYBeBewCeL8fh
jOJSgWEisHfOU6/WflFoukA=
=swOg
-END PGP SIGNATURE-
First of all (kind of basic) what is GCD ?
I have actually implemented this a couple of different ways (not
using threads).
At first I just had lazy loading of the TableView. Whenever the
TableView needed something a file was accessed and a thumbnail
extracted. Then I changed it to do preprocessing. That is,
everything was extracted from the files and then the TableView was
allowed to load. The first approach uses less memory but is slower
in updating the TableView (when it is scrolled for example). The
second approach uses more memory but is faster in updating (provides
a better user experience). I think trying to do this in a separate
thread would be much cleaner using the second approach.
I forgot to mention the really slow case: if a thumbnail can't be
found in the file, then I make a thumbnail from the main image. If
this has to be done on a lot of files, then things really bog down.
Jim Merkel
Ok, I see GCD == Grand Central Dispatch. Available on Snow Leopard.
I'm on 10.5.8. I'll probably have to buy a new machine and get back to
you on this!
Jim Merkel
___
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
Progress Indicators Spin vs Bar
I am trying to do an indeterminate progress indicator in a small
NSPanel window similar to that shown in Figure 15-57 of the
OSXHIGuidelines. The NSPanel and NSProgresssIndicator are in a nib
file and I'm pretty sure the IB connections are correct. If I use a
spin progress indicator, I can start the animation. If I switch to a
bar progress indicator, I can't start the animation. (Looking at the
archives, this seems opposite from what other people have experienced
- they had problems with the spin progress indicator). The code is
pretty simple. I have a ProgressController class defined as follows
in .h and .m files:
@interface ProgressController : NSWindowController {
IBOutlet NSProgressIndicator *progressIndicator;
}
-(void)startProgressAnimation;
@end
#import ProgressController.h
@implementation ProgressController
-(id)init{
self = [super initWithWindowNibName:@ProgressWindow];
[self setWindowFrameAutosaveName:@ProgWindow];
return self;
}
-(void)windowDidLoad{
}
-(void)startProgressAnimation{
NSLog(@progressIndicator should start);
[progressIndicator startAnimation:nil];
}
@end
Then use the progress indicator as follows;
ProgressController * progressController = nil;
progressController =[[ProgressController alloc] init];
NSLog(@Progress window: %@\n, [progressController window]);
[progressController startProgressAnimation];
[progressController showWindow:self];
(Long processing)
[progressController close];
[progressController release];
So this works with the spinner but not the bar. Seems strange because
I thought the two progress indicators would work the same.
Thanks for any help.
Jim Merkel
___
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
Re: Progress Indicators Spin vs Bar
On Jun 19, 2011, at 1:27 PM, Quincey Morris wrote: On Jun 19, 2011, at 13:14, James Merkel wrote: ProgressController * progressController = nil; progressController =[[ProgressController alloc] init]; NSLog(@Progress window: %@\n, [progressController window]); [progressController startProgressAnimation]; [progressController showWindow:self]; (Long processing) [progressController close]; [progressController release]; So this works with the spinner but not the bar. Seems strange because I thought the two progress indicators would work the same. They don't. The spinning indicator animates itself, but the bar animation depends on run loop iterations to drive the animation. If Long processing means a loop, you're not going back to the run loop. In those circumstances you must arrange for events to be processed (run the run loop or dequeue events in a modal event loop). Note that you probably want to do that anyway, because you probably want to have a Cancel button on a long-running operation. Ok thanks -- I didn't realize there was a difference in the way the two progress indicators worked. ___ 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
Malformed URL string in openURL
I am sending a URL string to NSWorkspace's openURL method that has the bracket characters ( ) in it. The URL can't be opened by NSWorkspace. If I take out the ( ) characters NSWorkspace then opens the URL, so I guess NSWorkspace considers the string with ( ) a malformed URL. Note, the ( ) characters are used by Mapquest to label a location. If I just enter the URL string with brackets in the browser , it opens mapquest ok. Is there any way around this problem? Thanks, Jim Merkel ___ 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
Re: Malformed URL string in openURL
On Jun 7, 2011, at 5:06 PM, Jeffrey Walton wrote: On Tue, Jun 7, 2011 at 8:03 PM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Jun 7, 2011 at 7:42 PM, James Merkel jmerk...@mac.com wrote: I am sending a URL string to NSWorkspace's openURL method that has the bracket characters ( ) in it. The URL can't be opened by NSWorkspace. If I take out the ( ) characters NSWorkspace then opens the URL, so I guess NSWorkspace considers the string with ( ) a malformed URL. Note, the ( ) characters are used by Mapquest to label a location. If I just enter the URL string with brackets in the browser , it opens mapquest ok. Is there any way around this problem? Forgive the obvious: have you tried an HTML escape - #40; and #41;? My bad - URL escapes: %28 and %29. I tried %28 and %29 and that didn't work either. ___ 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
Re: Malformed URL string in openURL
On Jun 7, 2011, at 5:39 PM, Jens Alfke wrote: On Jun 7, 2011, at 4:42 PM, James Merkel wrote: I am sending a URL string to NSWorkspace's openURL method that has the bracket characters ( ) in it. The URL can't be opened by NSWorkspace. If I take out the ( ) characters NSWorkspace then opens the URL, so I guess NSWorkspace considers the string with ( ) a malformed URL. That’s weird, since RFC 1738 explicitly says parentheses are legal and don’t need to be escaped: Thus, only alphanumerics, the special characters $-_.+!*'(),, and reserved characters used for their reserved purposes may be used unencoded within a URL. Could you show us one of these URLs? —Jens The following works ok: NSString * mapquestURLString; mapquestURLString = [NSString stringWithString:@http://mapq.st/?maptype=hybridq=39.7452,-104.98916 ]; if([[NSWorkspace sharedWorkspace] openURL:[NSURL URLWithString:mapquestURLString]]); else NSLog(@Could not open mapquest); But if I use the following string, I get the error message: mapquestURLString = [NSString stringWithString:@http://mapq.st/?maptype=hybridq=39.7452,-104.98916(Test point label)]; I got the examples from http://www.mapquestapi.com/link-to-mapquest/#parameters I'm noticing some of the other examples don't work also. Jim Merkel___ 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
Re: Malformed URL string in openURL
On Jun 7, 2011, at 6:20 PM, Jens Alfke wrote: On Jun 7, 2011, at 6:17 PM, James Merkel wrote: The following works ok: NSString * mapquestURLString; mapquestURLString = [NSString stringWithString:@http://mapq.st/?maptype=hybridq=39.7452,-104.98916 ]; (Just FYI, the -stringWithString call is redundant. You can just assign the constant directly to the variable.) mapquestURLString = [NSString stringWithString:@http://mapq.st/?maptype=hybridq=39.7452,-104.98916(Test point label)”]; It’s not the parens that are illegal, it’s the spaces. Change them to %20 and you should be OK. —Jens Right you are -- thanks. I was using stringWithString because I actually was building up a URL string by appending strings. I simplified the code to show the problem. Jim Merkel___ 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
Re: Malformed URL string in openURL
On Jun 7, 2011, at 9:52 PM, Steve Christensen wrote: stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding Yeah, I just found that method about an hour ago! Not related to Cocoa -- but It turns out after playing around with this with mapquest and google maps, adding a label can change the view that you get (particularly in google maps). So I probably won't add that. But at least I found out how to get a legal URL string in the process. Thanks, Jim Merkel ___ 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
Re: Recursive search for files
On Wed, 25 May 2011 08:52:31 ronald b. kopelman wrote: On May 22, 2011, at 11:52 AM, James Merkel wrote: I would like to add a capability to an application to search directories and sub-directories eventually opening all image files (basically using NSDirectoryEnumerator). Obviously, I can't allow the user to start at say the volume level and do the search. However as far as I can tell, there is nothing in NSOpenPanel for example that prevents the user from starting there. I was trying to come up with a way to prevent the user from starting at the wrong place. (Putting up an Alert that says you can't start there). There's a method in the NSFileManager class called isDeletableFileAtPath. I am thinking that all of those volumes and higher level directories that I want to avoid are not deletable. Therefore I could use this as a filter. The only other approach might be to limit the search to a certain depth (maybe 10 or 20 directories). However that seems kind of mickey-mouse. Should I be looking at the lower level File Manager Reference for some help here? Has anyone come up with an approach for this? I have done these types of searches. I could not figure out how to set up the security stuff of entering passwords. You could try the following which should not be too hard to code. I figure everyone has the right to look at what they own so limit the searches by starting them at the user's home file (/Users/ownerName). You could test the file name for this prefix proceed if the test passes. You can use the NSString method hasPrefix: to do the test. You can probably find the home directory, though I have not tried this lately, by using Foundation functions. Try NSHomeDirectoryForUser(NSUserName()) see if this helps. Of course, it won't help if you are looking at a flash drive! Good luck. ronald b. kopelman Security shouldn't be an issue -- this application is for home use only. Allowing searches only of the home directory might be a reasonable approach. I should mention there is some source code that has been out there for a while that does some of what I want to do, it's called FolderSweep at http://www.brockerhoff.net/src/. Might take a look at this a little more. Thanks, Jim Merkel ___ 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
Re: Recursive search for files
On May 25, 2011, at 8:18 PM, Kyle Sluder wrote: On Wed, May 25, 2011 at 7:34 PM, James Merkel jmerk...@mac.com wrote: Security shouldn't be an issue -- this application is for home use only. Unless by home use you mean my own personal home use, then you're taking the wrong tack with respect to security. It is your responsibility to follow best security practices on behalf of your users. That's the only way any platform remains resilient to malware. --Kyle Sluder No, I meant users that are not in an office or commercial environment. A previous poster mentioned use of a password. Seems like overkill on your own machine at home. Jim Merkel ___ 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
Re: Recursive search for files
On May 25, 2011, at 8:27 PM, Jens Alfke wrote: On May 25, 2011, at 7:34 PM, James Merkel wrote: Security shouldn't be an issue -- this application is for home use only. Allowing searches only of the home directory might be a reasonable approach. Seems like a bad restriction. People may keep some of their files outside their home directory (I do). And what about scanning external disks like CD-Rs or flash drives? Of all the directory-scanning apps I’ve seen (OmniDiskSweeper, GrandPerspective, etc.) I can’t think of any that restrict what directory you can scan. —Jens What I'm trying to do is add a feature to my application that allows a user to search and make changes to image files that are in subfolders. (Right now you can just make changes in a folder). This isn't a general disk sweeper application. But I agree, I need to allow for the case of searching other drives etc. For example a digital camera looks like an external volume. So it would be useful to actually make changes to the images in camera. Jim Merkel___ 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
Re: Cocoa-dev Digest, Vol 8, Issue 367
On May 24, 2011, at 5:15 AM, cocoa-dev-requ...@lists.apple.com wrote: James Merkel wrote: I was trying to come up with a way to prevent the user from starting at the wrong place. (Putting up an Alert that says you can't start there). There's a method in the NSFileManager class called isDeletableFileAtPath. I am thinking that all of those volumes and higher level directories that I want to avoid are not deletable. Therefore I could use this as a filter. You should test that assumption. Test it when logged in as both a non-admin user and an admin user. You might be surprised. You also might be surprised if Apple changes anything in permissions, ACLs, etc. and suddenly you get a whole lot more files than you planned for. So the whole premise seems a little shaky to me. I'm not sure why you can't allow the user to start at the volume level, if by that you mean the root filesystem whose pathname is /. If you want to limit depth, give the user a control to limit depth. If you want to limit number of files, give the user a control for that. Set reasonable defaults, but otherwise don't artificially limit what users can do. You don't know how they've setup their storage, and arbitrary limitations are obnoxious. If your concern is traversing every mounted volume, there's an easy way to detect that: it's the device-id in the struct filled in by stat () (see man page for stat(2)). You don't have to decipher the device- id, you just have to check for a change in device-id to some value that differs from the device-id of where you started. For an example of controlling depth, traversal of volumes, etc. look at the man page for the 'find' command. There are also readable attributes (flags and xattrs) that can offer clues as to whether a directory is hidden from the GUI or not. See man chflags, and man xattr. The idea here is to not traverse hidden dirs unless the user says it should. Some of these are also available as Spotlight metadata, so read up on that, too. And don't put up any alert that says You can't start there. Simply dim or don't show any items that should not be traversed. Few things are worse than a cycle of You can't do that alerts, when the proper course is to only show things that can be done. -- GG Yes, I'm concluding that the best approach is to limit the depth of the search by a user selectable amount and also to limit the number of files that can be opened. As far as starting at the wrong place -- probably 99% of the directories are the wrong place, so I can't really prevent that and shouldn't try to prevent it. Thanks, Jim Merkel ___ 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
Re: Recursive search for files
On May 24, 2011, at 5:15 AM, cocoa-dev-requ...@lists.apple.com wrote: James Merkel wrote: I was trying to come up with a way to prevent the user from starting at the wrong place. (Putting up an Alert that says you can't start there). There's a method in the NSFileManager class called isDeletableFileAtPath. I am thinking that all of those volumes and higher level directories that I want to avoid are not deletable. Therefore I could use this as a filter. You should test that assumption. Test it when logged in as both a non-admin user and an admin user. You might be surprised. You also might be surprised if Apple changes anything in permissions, ACLs, etc. and suddenly you get a whole lot more files than you planned for. So the whole premise seems a little shaky to me. I'm not sure why you can't allow the user to start at the volume level, if by that you mean the root filesystem whose pathname is /. If you want to limit depth, give the user a control to limit depth. If you want to limit number of files, give the user a control for that. Set reasonable defaults, but otherwise don't artificially limit what users can do. You don't know how they've setup their storage, and arbitrary limitations are obnoxious. If your concern is traversing every mounted volume, there's an easy way to detect that: it's the device-id in the struct filled in by stat () (see man page for stat(2)). You don't have to decipher the device- id, you just have to check for a change in device-id to some value that differs from the device-id of where you started. For an example of controlling depth, traversal of volumes, etc. look at the man page for the 'find' command. There are also readable attributes (flags and xattrs) that can offer clues as to whether a directory is hidden from the GUI or not. See man chflags, and man xattr. The idea here is to not traverse hidden dirs unless the user says it should. Some of these are also available as Spotlight metadata, so read up on that, too. And don't put up any alert that says You can't start there. Simply dim or don't show any items that should not be traversed. Few things are worse than a cycle of You can't do that alerts, when the proper course is to only show things that can be done. -- GG Yes, I'm concluding that the best approach is to limit the depth of the search by a user selectable amount and also to limit the number of files that can be opened. As far as starting at the wrong place -- probably 99% of the directories are the wrong place, so I can't really prevent that and shouldn't try to prevent it. Thanks, Jim Merkel ___ 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
Recursive search for files
I would like to add a capability to an application to search directories and sub-directories eventually opening all image files (basically using NSDirectoryEnumerator). Obviously, I can't allow the user to start at say the volume level and do the search. However as far as I can tell, there is nothing in NSOpenPanel for example that prevents the user from starting there. I was trying to come up with a way to prevent the user from starting at the wrong place. (Putting up an Alert that says you can't start there). There's a method in the NSFileManager class called isDeletableFileAtPath. I am thinking that all of those volumes and higher level directories that I want to avoid are not deletable. Therefore I could use this as a filter. The only other approach might be to limit the search to a certain depth (maybe 10 or 20 directories). However that seems kind of mickey-mouse. Should I be looking at the lower level File Manager Reference for some help here? Has anyone come up with an approach for this? Thanks, Jim Merkel ___ 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
Re: Printing and Segmented Control state [Solved]
Ok, should have known this -- the print version of the view is a separate instance of the view from the screen version, and the print version doesn't have the segmented control. So I have to get the state of the control from the screen version and set it into the print version so I can print out the correct string. Jim Merkel On Jun 7, 2010, at 10:28 PM, James Merkel wrote: I have a view that has among other things a segmented control. In the printing code I want to print a string that represents the current state of the segmented control. However, whenever I query the segmented control with -selectedSegment in the print code, I get a value of 0. On the other hand, if I'm drawing the same view to the screen I get the correct index when I query for the selected segment. Has anyone run into this problem and found a work-around? Thanks in advance. Jim Merkel ___ 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
Printing and Segmented Control state
I have a view that has among other things a segmented control. In the printing code I want to print a string that represents the current state of the segmented control. However, whenever I query the segmented control with -selectedSegment in the print code, I get a value of 0. On the other hand, if I'm drawing the same view to the screen I get the correct index when I query for the selected segment. Has anyone run into this problem and found a work-around? Thanks in advance. Jim Merkel ___ 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
Bit maps from raw camera files
I notice there are now about 120 Digital camera raw formats supported by Mac OS X as of system 10.5.4. I am trying to get a bit map from these camera files so I am using: NSBitmapImageRep * imageBitMap = [NSBitmapImageRep imageRepWithContentsOfFile:theFile] For some raw files (Nikon NEF and Canon CR2) I get a bit map. But for other files (Sony DSLR-A100 ARW file) I get a nil bit map. On the other hand, I notice that the system does support the Sony raw file in some way, since for example: [[NSImage alloc] initWithContentsOfFile:theFile] does produce an image. So the question is how to go about reliably getting a bit map reliably form these camera raw files? Thanks. Jim Merkel ___ 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 [EMAIL PROTECTED]
Re: Bit maps from raw camera files
Will look into CGImageRef using ImageIO. However, I found that if I
use: imageRepsWithContentsOfFile: rather than
imageRepWithContentsOfFile: I can get a bit map from all raw files
that are supported by OS X. (At least for the raw files I have checked
so far). The method imageRepsWithContentsOfFile returns an array of
file reps, so the following works:
NSBitmapImageRep * imageBitMap = nil;
NSArray * repsArray;
repsArray = [NSBitmapImageRep imageRepsWithContentsOfFile:theFile];
if([repsArray lastObject] != nil) {
imageBitMap = [repsArray objectAtIndex:0];
}
Jim Merkel
On Sat, 05 Jul 2008 14:16:46 -0700 Chris Hanson wrote:
On Jul 5, 2008, at 2:00 PM, James Merkel wrote:
So the question is how to go about reliably getting a bit map
reliably form these camera raw files?
Try getting a CGImageRef using ImageIO.
On Jul 5, 2008, at 2:00 PM, James Merkel wrote:
I notice there are now about 120 Digital camera raw formats supported
by Mac OS X as of system 10.5.4.
I am trying to get a bit map from these camera files so I am using:
NSBitmapImageRep * imageBitMap = [NSBitmapImageRep
imageRepWithContentsOfFile:theFile]
For some raw files (Nikon NEF and Canon CR2) I get a bit map. But for
other files (Sony DSLR-A100 ARW file) I get a nil bit map.
On the other hand, I notice that the system does support the Sony raw
file in some way, since for example:
[[NSImage alloc] initWithContentsOfFile:theFile] does produce an
image.
So the question is how to go about reliably getting a bit map reliably
form these camera raw files?
___
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 [EMAIL PROTECTED]
Re: Using deprecated methods
On Sat, 5 Jul 2008 05:08:45 -0700 (PDT) Keith Blount wrote: Hi, Something that has bothered me for ages in Cocoa, but which I've always put to one side, is how to handle certain deprecated methods when supporting more than one OS. In some instances it's as simple as checking at runtime which OS is being used and using the appropriate method accordingly, but I'm wondering here about the trickier instances. For instance: I am currently overhauling printing in my application. I have a page layout accessory view and I now also want to add a print panel accessory view. My app runs on both Tiger and Leopard. - setAccessoryView: works on both Tiger and Leopard, for adding an accessory view to both NSPageLayout and NSPrintPanel. However, in both cases, -setAccessoryView: was (rather frustratingly in this case, I feel, as it worked fine) informally deprecated on Leopard. Instead, we are advised to use -addAccessoryViewController:, which uses an NSViewController. ... This brings up another question. Is -setAccessoryView: deprecated across the board or just for NSPageLayout and NSPrintPanel? I just added an accessory view to an NSSavePanel. There wasn't anything in the NSSavePanel docs that said -setAccessoryView: was deprecated there. Thanks, Jim Merkel ___ 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 [EMAIL PROTECTED]
Re: File's Owner
On May 25, 2008, at 12:02 PM, Hamish Allan wrote: What this thread has reminded me of is an ongoing conversation I have with a friend of mine, who refuses to countenance the square root of minus one, because he doesn't think it means anything. I explain to him how useful it can be to admit complex numbers for various real-world situations, but because there exists an algorithm to generate mandelbrots which doesn't ever do sqrt(n) for n0, he thinks this proves that complex numbers are entirely unnecessary and therefore best avoided. It doesn't matter how much you explain that real numbers are imaginary too, or that the square root of 4 apples is also meaningless in a physical sense. He has a sort of emotional investment in the uselessness of complex numbers that completely blinkers him. The difference is, I doubt that this particular friend will ever have reason to do anything that will be made easier by using complex numbers, so I don't suppose his opinion will ever change. But I'm hoping that it's just a matter of time for Johnny. (Maybe when he has occasion to create a document-based app it will become clearer? Although bags I not the one to tell him that NSDocumentController is not designed to mediate between his view and his NSDocument ;] ) The way I look at it, when you are attempting to learn a new subject you need to be humble. By that I mean you need to jettison some preconceived ideas and probably accept some things without a complete understanding (at least initially). If you are not willing to do that, you will have a hard time assimilating new ideas. Case in point, when I first started taking courses in electrical engineering, I remember some people saying that if you had previous experience with electronics/radio (like for example, you were a Ham radio operator), you might have more difficulty learning some concepts because you had preconceived ideas that were incorrect. (By the way, electrical engineering is where you will use complex numbers.) More to the subject at hand, I thought File's owner was just a mechanism for connecting nib objects to code. Nothing more or less. If I'm missing something, someone can correct me. Jim ___ 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 [EMAIL PROTECTED]
Re: Guidance for Cocoa's steep learning curve
Regarding the question on how NSTableView works -- there are examples of Table Views in the Aaron Hillegass book Cocoa programming for Mac OS X. Also, there are literally hundreds of questions and answers on Table Views in the archives of this mailing list. When I get stuck on how to do something, my first line of attack is to search the archives. The archives have a wealth of information. Jim Merkel ___ 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 [EMAIL PROTECTED]
Re: Southern California Coders?
Yeah, gas at ~ $4 per gallon, makes the drive from San Diego to Lake Forest kind of a luxury. Jim Merkel On Apr 2, 2008, at 9:55 PM, Scott Ellsworth wrote: On Wed, Apr 2, 2008 at 10:01 AM, Boyd Collier [EMAIL PROTECTED] wrote: I 'm also interested in knowing if there's a San Diego area group. At one point, a fair number of San Diego folks drove up for the Lake Forest meetings. The drive got to them about a year ago, and I have not heard whether they have started their own group. Scott On Apr 1, 2008, at 4:46 PM, James Merkel wrote: On Tue, 1 Apr 2008 15:23:40, Casey Becking wrote: Sorry to take any ones time if this has been discussed before. I was curious if there was any group meeting for Southern California coders to get together? Well, Southern California is a pretty big area. I have seen reference to Lake Forest meetings. Are there any groups in the San Diego area? Jim Merkel ___ 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/bcollier%40sunstroke.sdsu.edu This email sent to [EMAIL PROTECTED] ___ 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/scott_ellsworth%40alumni.hmc.edu This email sent to [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
Re: Southern California Coders?
On Tue, 1 Apr 2008 15:23:40, Casey Becking wrote: Sorry to take any ones time if this has been discussed before. I was curious if there was any group meeting for Southern California coders to get together? Well, Southern California is a pretty big area. I have seen reference to Lake Forest meetings. Are there any groups in the San Diego area? Jim Merkel ___ 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 [EMAIL PROTECTED]
