Re: Help with Help
Re: Help with Help
- Subject: Re: Help with Help
- From: Kirk <email@hidden>
- Date: Wed, 07 May 2014 13:00:09 -0500
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, email@hidden wrote:
>
> Send Cocoa-dev mailing list submissions to
> email@hidden
>
> 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
> email@hidden
>
> You can reach the person managing the list at
> email@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cocoa-dev digest..."
>
>
> Today's Topics:
>
> 1. 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 <email@hidden>
> To: Cocoa dev <email@hidden>
> Subject: NSWorkspace issue
> Message-ID: <CF8FFBAD.14FD%email@hidden>
> 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 <email@hidden>
> To: Varun Chandramohan <email@hidden>
> Cc: Cocoa dev <email@hidden>
> Subject: Re: NSWorkspace issue
> Message-ID: <email@hidden>
> 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 <email@hidden>
> To: Quincey Morris <email@hidden>
> Cc: Cocoa Dev List <email@hidden>
> Subject: Re: How to convert a UTF-8 byte offset into an NSString
> character offset?
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
>> On 06 May 2014, at 20:12, Quincey Morris <email@hidden> 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 <email@hidden>
> To: Gordon Apple <email@hidden>
> Cc: Cocoa-dev <email@hidden>
> Subject: Re: Help with Help
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=iso-8859-1
>
>> On 29 Apr 2014, at 19:52, Gordon Apple <email@hidden> 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 <email@hidden>
> To: Cocoa Cocoa-Dev <email@hidden>
> Subject: Resizing last column of NSTableView when it touches window
> border
> Message-ID: <email@hidden>
> 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 <email@hidden>
> To: Gordon Apple <email@hidden>
> Cc: Cocoa-dev <email@hidden>
> Subject: Re: Help with Help
> Message-ID: <email@hidden>
> 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 <email@hidden>:
>>
>> 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 (email@hidden)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 07 May 2014 09:53:38 -0400
> From: Bill Cheeseman <email@hidden>
> To: Cocoa-Dev Cocoa-Dev Mail <email@hidden>
> Subject: Re: Help with Help
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>
>> On May 7, 2014, at 9:44 AM, Jakob Egger <email@hidden> 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 - email@hidden
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 07 May 2014 11:21:05 -0500
> From: William Squires <email@hidden>
> To: Cocoa Developers <email@hidden>
> Subject: NSData problems and viewing buffer data in hex
> Message-ID: <email@hidden>
> 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 <email@hidden>
> To: William Squires <email@hidden>
> Cc: Cocoa Developers <email@hidden>
> Subject: Re: NSData problems and viewing buffer data in hex
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
>
>> On May 7, 2014, at 9:21 AM, William Squires <email@hidden> 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 <email@hidden>
> To: email@hidden
> Subject: NSNumberFormatter 10.0+ style exception with zero
> Message-ID: <email@hidden>
> 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 <email@hidden>
> To: Jakob Egger <email@hidden>
> Cc: Cocoa-dev <email@hidden>
> Subject: Re: Help with Help
> Message-ID: <CF8FD2A4.115BE1%email@hidden>
> 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" <email@hidden> 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 (email@hidden)
>
> 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 (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden