Apple help is unacceptably slow. I just opened Safari's help, and it timed out, giving the "no information for that topic" message. Subsequent invocations are faster, but it is still a painful performance.
And this was on an Core i7 MBP with 16gB of RAM. I further note that Apple's own iWork apps use online help pages that open in Safari. Perhaps that is a hint. Kirk Kerekes (iPhone) > On May 7, 2014, at 12:08 PM, cocoa-dev-requ...@lists.apple.com wrote: > > Send Cocoa-dev mailing list submissions to > cocoa-dev@lists.apple.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.apple.com/mailman/listinfo/cocoa-dev > or, via email, send a message with subject or body 'help' to > cocoa-dev-requ...@lists.apple.com > > You can reach the person managing the list at > cocoa-dev-ow...@lists.apple.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Cocoa-dev digest..." > > > Today's Topics: > > 1. NSWorkspace issue (Varun Chandramohan) > 2. Re: NSWorkspace issue (Ken Thomases) > 3. Re: How to convert a UTF-8 byte offset into an NSString > character offset? (Uli Kusterer) > 4. Re: Help with Help (Uli Kusterer) > 5. Resizing last column of NSTableView when it touches window > border (Jakob Egger) > 6. Re: Help with Help (Jakob Egger) > 7. Re: Help with Help (Bill Cheeseman) > 8. NSData problems and viewing buffer data in hex (William Squires) > 9. Re: NSData problems and viewing buffer data in hex (Jens Alfke) > 10. NSNumberFormatter 10.0+ style exception with zero (Howard Moon) > 11. Re: Help with Help (Gordon Apple) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 07 May 2014 05:02:54 +0000 > From: Varun Chandramohan <varun.chandramo...@wontok.com> > To: Cocoa dev <Cocoa-dev@lists.apple.com> > Subject: NSWorkspace issue > Message-ID: <cf8ffbad.14fd%varun.chandramo...@wontok.com> > Content-Type: text/plain; charset="us-ascii" > > Hi All, > > I wanted to open a Finder window from my app with a file pre-selected. The > user could perform any Finder operations needed. I looked around the internet > and it turns out the best way to do this is using NSWorkspace. > > > - (void)applicationDidFinishLaunching:(NSNotification *)aNotification > > { > > // Insert code here to initialize your application > > NSURL *fileURL = [NSURL URLWithString:@"/Users/usr/Desktop/libd.dylib"]; > > NSArray *fileURLs = [NSArray arrayWithObjects:fileURL, nil]; > > [[NSWorkspace sharedWorkspace] activateFileViewerSelectingURLs:fileURLs]; > > } > > However, I am not sure what is going on. The Finder window never pops up. I > do see the top bar change to Finder bar but then the window is never present. > The file I am trying to highlight is present. Is there anyway to know error > code? The method is void. > > Regards, > Varun > > > ------------------------------ > > Message: 2 > Date: Wed, 07 May 2014 00:58:21 -0500 > From: Ken Thomases <k...@codeweavers.com> > To: Varun Chandramohan <varun.chandramo...@wontok.com> > Cc: Cocoa dev <Cocoa-dev@lists.apple.com> > Subject: Re: NSWorkspace issue > Message-ID: <bfe724aa-f5dd-418c-839f-b320f5401...@codeweavers.com> > Content-Type: text/plain; charset=us-ascii > >> On May 7, 2014, at 12:02 AM, Varun Chandramohan wrote: >> >> NSURL *fileURL = [NSURL URLWithString:@"/Users/usr/Desktop/libd.dylib"]; > > This is not correct. +[NSURL URLWithString:] expects a valid URL string. > What you're providing is a file path string, which is not a URL string. A > URL string might be "http://www.apple.com"; or > "file:///Users/usr/Desktop/libd.dylib". However, never just prepend > "file://" to a file path to try to make it into a URL string. That doesn't > correctly handle a path which contains characters which are not valid in URLs. > > The correct thing to do is use +[NSURL fileURLWithPath:] or a similar method. > > Regards, > Ken > > > > > ------------------------------ > > Message: 3 > Date: Wed, 07 May 2014 14:13:52 +0200 > From: Uli Kusterer <witness.of.teacht...@gmx.net> > To: Quincey Morris <quinceymor...@rivergatesoftware.com> > Cc: Cocoa Dev List <cocoa-dev@lists.apple.com> > Subject: Re: How to convert a UTF-8 byte offset into an NSString > character offset? > Message-ID: <ab2992a3-25bb-4335-97ed-21fedbf08...@gmx.net> > Content-Type: text/plain; charset=windows-1252 > >> On 06 May 2014, at 20:12, Quincey Morris >> <quinceymor...@rivergatesoftware.com> wrote: >> FWIW, my opinion is that if your library clients are specifying UTF-8 >> sequences at the API, and expect byte offsets into those sequences to be >> meaningful, you might well be forced to maintain the original UTF-8 sequence >> in the library’s internal data model — or, perhaps, an array of the original >> code points — and do all of your internal processing in terms of code >> points. Conversion to NSString would happen only in the journey from data >> model to UI text field. > > This is pretty much what I do in one of my projects. I hand-wrote code for > converting between offsets, mostly based on tutorials from the net, knowing > my offsets are always at the start/end of code points, and knowing that my > conversion code always generates the same sequence, just encoding as > UTF8/UTF16 as needed to display in the UI or convert selection offsets back > to UTF8 offsets. The code hasn't shipped (or been tested much beyond myself > using the app for a while), but if you're interested, contact me off-list and > I'll send you a copy. > > Cheers, > -- Uli Kusterer > "The Witnesses of TeachText are everywhere..." > http://www.zathras.de > > > > > ------------------------------ > > Message: 4 > Date: Wed, 07 May 2014 14:25:58 +0200 > From: Uli Kusterer <witness.of.teacht...@gmx.net> > To: Gordon Apple <g...@ed4u.com> > Cc: Cocoa-dev <cocoa-dev@lists.apple.com> > Subject: Re: Help with Help > Message-ID: <eb6c44a1-8883-4a2c-a170-1d5169caa...@gmx.net> > Content-Type: text/plain; charset=iso-8859-1 > >> On 29 Apr 2014, at 19:52, Gordon Apple <g...@ed4u.com> wrote: >> We would like to get a recommendation on the best way to generate a help >> system for a fairly complex application. We started by using a simple web >> view and created about 120 screens in BBEdit, mostly drill-down outlines. >> Unfortunately, this has been proven to be difficult to maintain. We¹ve >> looked into web generators like RapidWeaver, Freeway, and even Dreamweaver, >> but all of these have been described as ³roach motels² where you enter but >> can never leave. >> >> We would like to have both local and web-based or web-updated content and >> have contextual help. This all brings us to Apple¹s ³Help Book², which seems >> to have been around forever and presents its own learning curve. So the >> question is: Is this the way to go? It it still current? What are the >> experiences in using it? > > At its core, a help book is just HTML, with a few extra tags thrown in. So > I'd recommend that. > > That said, if you're looking for a tool to generate such help, that's your > answer as well. Pick anything that spits out HTML and lets you add the > required extra tags. This includes all web programming languages, i.e. I > worked on a project where we ran the PHP command line tool over a bunch of > PHP files and generated plain HTML files suitable for use with Apple Help > from that. These days you'd probably go with Ruby or so. > > Cheers, > -- Uli Kusterer > "The Witnesses of TeachText are everywhere..." > http://www.zathras.de > > > > > ------------------------------ > > Message: 5 > Date: Wed, 07 May 2014 14:27:42 +0200 > From: Jakob Egger <ja...@eggerapps.at> > To: Cocoa Cocoa-Dev <Cocoa-dev@lists.apple.com> > Subject: Resizing last column of NSTableView when it touches window > border > Message-ID: <cab3280b-7cc5-4e94-abfa-6597e90fc...@eggerapps.at> > Content-Type: text/plain; charset=us-ascii > > I have a NSTableView that spans the full width of the window, so it touches > the window borders on both sides. The table view has many columns (it scrolls > horizontally). > > Changing column witdth columns by dragging the separator line works > perfectly, except for the last column. The problem is that the separator line > coincides with the window border, so when I try to drag it the window is > resized, rather than the column. > > Did anybody else stumble upon this problem? > > Is there any way to tell the window to not resize when clicking near the > table header? I couldn't find anything in the docs on NSWindow. > > Or can you think of another workaround, aside from leaving an ugly > brushed-metal-like border around the table view? > > Best wishes, > Jakob > > > ------------------------------ > > Message: 6 > Date: Wed, 07 May 2014 15:44:20 +0200 > From: Jakob Egger <ja...@eggerapps.at> > To: Gordon Apple <g...@ed4u.com> > Cc: Cocoa-dev <cocoa-dev@lists.apple.com> > Subject: Re: Help with Help > Message-ID: <3f90080e-d894-400b-85dc-377aa535b...@eggerapps.at> > Content-Type: text/plain; charset=iso-8859-1 > > I'd strongly recommend against using Apple's Help Book application. There are > a few problems with Apple Help: > > > Problems with Help Books > ==================== > > First of all, they are poorly documented. It is extremely difficult to > structure them in the right way. You can't use HTML5, you have to use some > special XHTML doctype. It took me weeks to find the right tags / anchors and > all the implicit requirements to get it working. > > Once you get them working, they might fail mysteriously. Sometimes Help > Viewer won't find your Help Book. Sometimes it will take 30 seconds or longer > until the Help Book is displayed, without any sensible feedback to the user. > Sometimes old versions of your Help Book will be displayed. > > Searching Help Books is slow. Again, no feedback, so your users will think > there are no results, when in reality Help Viewer is still indexing your help > book. > > Additionally, the erratic behaviour seemed to change with every major version > of OS X. > > Finally, when I contacted Apple Developer Technical Support, they told me > that they don't offer support for Help Books. > > > Alternatives > ========= > > The solution I went with was to use a simple web view that displays normal > HTML pages. A plain window with three toolbar items: back / forward / index. > Additionally, I provide the documentation for the latest version on my > website. > > The HTML in the app and on the website is slightly different, I use PHP to > generate the HTML. > > A more modern approach would probably be to use a static site generator like > Jekyll, which would allow you to use templates, write in Markdown, etc. > > Best wishes, > Jakob > > >> Am 29.04.2014 um 19:52 schrieb Gordon Apple <g...@ed4u.com>: >> >> We would like to get a recommendation on the best way to generate a help >> system for a fairly complex application. We started by using a simple web >> view and created about 120 screens in BBEdit, mostly drill-down outlines. >> Unfortunately, this has been proven to be difficult to maintain. We¹ve >> looked into web generators like RapidWeaver, Freeway, and even Dreamweaver, >> but all of these have been described as ³roach motels² where you enter but >> can never leave. >> >> We would like to have both local and web-based or web-updated content and >> have contextual help. This all brings us to Apple¹s ³Help Book², which seems >> to have been around forever and presents its own learning curve. So the >> question is: Is this the way to go? It it still current? What are the >> experiences in using it? >> >> _______________________________________________ >> >> 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/jakob%40eggerapps.at >> >> This email sent to ja...@eggerapps.at > > > > > ------------------------------ > > Message: 7 > Date: Wed, 07 May 2014 09:53:38 -0400 > From: Bill Cheeseman <wjcheese...@gmail.com> > To: Cocoa-Dev Cocoa-Dev Mail <cocoa-dev@lists.apple.com> > Subject: Re: Help with Help > Message-ID: <3a547807-0967-4da4-82d0-c96db116b...@gmail.com> > Content-Type: text/plain; charset=us-ascii > > >> On May 7, 2014, at 9:44 AM, Jakob Egger <ja...@eggerapps.at> wrote: >> >> Problems with Help Books >> ==================== >> >> First of all, they are poorly documented. > > I disagree with most of Mr. Egger's comments about Help Book problems, but he > is certainly right that they are still poorly documented. The documentation > confuses the pre- and post-Snow Leopard forms of Help Books and is virtually > impossible to follow, despite years of complaints to Apple. > > As far as I know, the only comprehensive explanation of the "new" post-Snow > Leopard version of Help Books is Chapter 11 of my book, Cocoa Recipes for Mac > OS X, Second Edition (Peachpit Press 2010). > > -- > > Bill Cheeseman - b...@cheeseman.name > > > > ------------------------------ > > Message: 8 > Date: Wed, 07 May 2014 11:21:05 -0500 > From: William Squires <wsqui...@satx.rr.com> > To: Cocoa Developers <cocoa-dev@lists.apple.com> > Subject: NSData problems and viewing buffer data in hex > Message-ID: <e0d06da4-b6f3-4d0b-9a8b-caa2ef24a...@satx.rr.com> > Content-Type: text/plain; charset=us-ascii > > Quickie question: Does [NSData getBytes:range:] return <range>.length bytes > into the buffer specified, even if some of the bytes may be '\0' (terminating > null), so long as range is valid? I'm trying to read in a specified record > from a random-access file (record length is 1000 bytes = kRecSize), and I > have a self.fileContents that's an @property (nonatomic, strong) NSData > *fileContents, which I set up as follows: > > "FSSBorr.m" > ----------- > #import "FSSBorr.h" > > char buffer[kRecSize + 1]; // <-file scope > > #pragma mark "Private Suff" > > @interface FSSBorr () > > @property (nonatomic, assign) BORR_REC theRec; > @property (nonatomic, copy) NSString *fileName; // These two are set up > in my initWithFile: > @property (nonatomic, strong) NSData *fileContents; // ditto > > @end > > @implementation FSSBorr > > ... > > -(void)loadRec:(NSUInteger)index > { > NSUInteger byteOffset = index * kRecSize; > NSRange recordRange = NSMakeRange(byteOffset, kRecSize); > char *c = &buffer[0]; > char *p = (char *)(&_theRec); > > @try > { > [self.fileContents getBytes:buffer range:recordRange]; // Problem is here - > not reading in all 1000 bytes. > memccpy(p, c, kRecSize, sizeof(char)); > } > @catch (NSException *ex) > { > NSLog(@"%ul beyond end of file.\n", (unsigned int)index); > NSLog(@"NSException thrown: %@\n", [ex description]); > } > } > > @end > > The file in question is several hundred kB long, and "index" = 1 for this > debug session. Is there some way to view the buffer (contents) as a hex dump? > I know what the bytes should be (I used "hexdump -Cv <filename>.dat > > <filename>.txt to get the hex dump of <filename>.dat, which is what > self.fileContents is loaded with in my initWithFile: method of this class. > > > > > ------------------------------ > > Message: 9 > Date: Wed, 07 May 2014 09:27:15 -0700 > From: Jens Alfke <j...@mooseyard.com> > To: William Squires <wsqui...@satx.rr.com> > Cc: Cocoa Developers <cocoa-dev@lists.apple.com> > Subject: Re: NSData problems and viewing buffer data in hex > Message-ID: <e8f718b4-511b-4b31-aeb0-5025f3158...@mooseyard.com> > Content-Type: text/plain; charset=windows-1252 > > >> On May 7, 2014, at 9:21 AM, William Squires <wsqui...@satx.rr.com> wrote: >> >> Quickie question: Does [NSData getBytes:range:] return <range>.length bytes >> into the buffer specified, even if some of the bytes may be '\0' >> (terminating null), so long as range is valid? > > If it’s a valid sub-range of the data it’ll copy range.length bytes into the > buffer, otherwise it’ll raise an exception. > Whether or not the bytes are zeros has nothing to do with it … NSData doesn’t > care what the data is, it’s just a blob. > > —Jens > > > > ------------------------------ > > Message: 10 > Date: Wed, 07 May 2014 09:34:04 -0700 > From: Howard Moon <how...@antarestech.com> > To: cocoa-dev@lists.apple.com > Subject: NSNumberFormatter 10.0+ style exception with zero > Message-ID: <c7c7adf0-95b9-4615-9fe1-2f2c721eb...@antarestech.com> > Content-Type: text/plain; charset=us-ascii > > Hi, > > is the 10.0+ style of NSNumberFormatter no longer supported? I recently > moved from developing in Xcode3 under OS X 10.7 to Xcode 4 under OS X 10.8, > and from having a Base SDK of 10.6 to 10.7, and from a Deployment Target of > 10.5 to 10.6, and am now having problems with my xib-base NSTextFields > connected to an NSNumberFormatter. The formatter uses the 10.0+ style, > allowing me to set the "Zero" field, which I am setting to the string N/A. > This worked fine, even when running in 10.8 or 10.9, but crashes now that > I've compiled under these new conditions. > > Here is the call stack when the exception is thrown: > > 2014-05-07 08:32:15.225 Cubase 7.5[947:707] -[__NSCFString string]: > unrecognized selector sent to instance 0x1050188d0 > 2014-05-07 08:32:15.226 Cubase 7.5[947:707] NSInvalidArgumentException - > -[__NSCFString string]: unrecognized selector sent to instance 0x1050188d0 > 0 CoreFoundation 0x00007fff92b32aee > __exceptionPreprocess + 174 > 1 libobjc.A.dylib 0x00007fff8b8b13f0 > objc_exception_throw + 43 > 2 CoreFoundation 0x00007fff92bc940a > -[NSObject(NSObject) doesNotRecognizeSelector:] + 186 > 3 CoreFoundation 0x00007fff92b2102e ___forwarding___ + > 414 > 4 CoreFoundation 0x00007fff92b20e18 > _CF_forwarding_prep_0 + 232 > 5 Foundation 0x00007fff93bc592b > -[NSNumberFormatter(NSNumberFormatterCompatibility2) > __oldnf_stringForObjectValue:] + 192 > 6 AppKit 0x00007fff8bd2ba93 -[NSCell > _stringForEditing] + 83 > 7 AppKit 0x00007fff8bd35a32 -[NSCell > _skipsSynchronizationForEditingTextView:] + 34 > 8 AppKit 0x00007fff8bc5e43f -[NSCell > setObjectValue:] + 296 > 9 AppKit 0x00007fff8bc5e2fd -[NSTextFieldCell > setObjectValue:] + 43 > 10 AppKit 0x00007fff8be51cbd -[NSCell > _setIntegerValue:] + 196 > 11 AppKit 0x00007fff8be47f49 -[NSControl > setIntValue:] + 138 > ... > > I am simply calling setIntValue with a value of 0, which in previous builds > would set the text field's text to "N/A". But now this exception is thrown, > and I don't know why or what to do about it. If the 10.0 style of > NSNumberFormatter is no longer supported, why is it still available in Xcode > 4, and why does it compile and run, up to the point I set its value to 0? > > Thanks, > -Howard > > > > ------------------------------ > > Message: 11 > Date: Wed, 07 May 2014 12:08:04 -0500 > From: Gordon Apple <g...@ed4u.com> > To: Jakob Egger <ja...@eggerapps.at> > Cc: Cocoa-dev <cocoa-dev@lists.apple.com> > Subject: Re: Help with Help > Message-ID: <cf8fd2a4.115be1...@ed4u.com> > Content-Type: text/plain; charset="ISO-8859-1" > > Wow! That¹s quite an indictment of one of Apple, Inc¹s supposed developer > tools. You¹d think that with $190B cash, they could fix this. One of the > problems I ran into is that I couldn¹t find the indexing tool without going > back to old versions. When I tried to use it, it choked, spewing a litany > of error messages. So much for that (and using contextual help anchors). > > I did take a stab at using the $39 (30-day free trial) HelpSupreme app. > Aside from a few bugs, anomalies, and irritations, it worked, but I didn¹t > care for the format. (That might be fixable in their CSS files.) > Unfortunately, it has no provision for external links, movie files, or > anchors. > > I then tried the $150 (limited free trial) SimpleHelpEditor. It¹s a lot more > capable, but complex, and you end up having to write all the HTML yourself > anyway, so why bother? > > One thing I found out is that if your root file is not index.html, you¹d > better make sure your help file identifier does not have any spaces in it. > > I¹m considering just going back to my original (successful) approach and > doing it all in BBEdit, for lack of finding any superior approach. > > >> On 5/7/14 8:44 AM, "Jakob Egger" <ja...@eggerapps.at> wrote: >> >> I'd strongly recommend against using Apple's Help Book application. There are >> a few problems with Apple Help: >> >> >> Problems with Help Books >> ==================== >> >> First of all, they are poorly documented. It is extremely difficult to >> structure them in the right way. You can't use HTML5, you have to use some >> special XHTML doctype. It took me weeks to find the right tags / anchors and >> all the implicit requirements to get it working. >> >> Once you get them working, they might fail mysteriously. Sometimes Help >> Viewer >> won't find your Help Book. Sometimes it will take 30 seconds or longer until >> the Help Book is displayed, without any sensible feedback to the user. >> Sometimes old versions of your Help Book will be displayed. >> >> Searching Help Books is slow. Again, no feedback, so your users will think >> there are no results, when in reality Help Viewer is still indexing your help >> book. >> >> Additionally, the erratic behaviour seemed to change with every major version >> of OS X. >> >> Finally, when I contacted Apple Developer Technical Support, they told me >> that >> they don't offer support for Help Books. >> >> >> Alternatives >> ========= >> >> The solution I went with was to use a simple web view that displays normal >> HTML pages. A plain window with three toolbar items: back / forward / index. >> Additionally, I provide the documentation for the latest version on my >> website. >> >> The HTML in the app and on the website is slightly different, I use PHP to >> generate the HTML. >> >> A more modern approach would probably be to use a static site generator like >> Jekyll, which would allow you to use templates, write in Markdown, etc. >> >> Best wishes, >> Jakob > > > > ------------------------------ > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins (at) lists.apple.com > > https://lists.apple.com/mailman/listinfo/cocoa-dev > > > End of Cocoa-dev Digest, Vol 11, Issue 253 > ****************************************** _______________________________________________ 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
