I'm following this guide to public some Apple help. The application I work on has had help built in for years, but it stopped working all of a sudden, and no changes were made to the application plist or any of the help files. We're presuming Apple changed something, so I made sure it met the specifications Apple were requiring. When I say "not working" I mean that our links using NSHelpManager will open the help viewer but bring back a page not found.
Things to check off the list:
There is an anchor with the correct name at the top of the page
The folder structure is a replica of what is in that article linked earlier
We are re-indexing the help pages
We do clear out all of the caches
Here's the code we use to open the help page:
NSString *locBookName = [[NSBundle mainBundle] objectForInfoDictionaryKey: #"CFBundleHelpBookName"];
[[NSHelpManager sharedHelpManager] openHelpAnchor:#"mypage" inBook:locBookName];
In this instance we'd have a page with a <a name="mypage"></a> at the top so it should link correctly. Our scripts are as follows:
hvfix (clears all caches):
rm -rf ~/Library/Caches/com.apple.help*
rm -rf ~/Library/Preferences/com.apple.help*
rm -rf ~/.Trash/*
killall helpd
defaults write com.apple.helpindexer IndexAnchors YES
updatehelpindex.sh (re-generates indexes)
#!/bin/sh
hiutil -C -f MyApp.help/Contents/Resources/English.lproj/MyApp.helpindex
MyApp.help/Contents/Resources/English.lproj/
We do a build, drop the folder into the Applications folder in order to register the application + the help. We even try a restart or logoff/logon and still we get nothing. I know it's a very fiddly process but nothing we try seems to work. All we want to be able to do is use the NSHelpManager to open a help anchor. Undoubtedly this works in 10.6+ as so many other apps do it (some reports suggest it won't work in 10.7/8, but they must be untrue).
Ideas?
EDIT (folder structure):
This is within the MyProj.help folder that's in a sub-directory of the overall Cocoa project called 'help'.
+ Contents
Info.plist
+ Resources
+ shrd
(a bunch of image files)
+ English.lproj
MyProj.helpindex
index.html
+ css
+ pgs
+ gfx
And in the folders are precisely what's as expected, 'css' has a bunch of CSS files in it, 'pgs' has the HTML pages and 'gfx' has image files.
It appears to be a bug in the way sandboxing affects the HelpViewer's directory search when a HelpBook is registered with the system (as outlined in this bug report), which fully explains why it shows up on 10.7 and 10.8, but not 10.6 and earlier. Even Apple's NSAlertTest suffers from it. Unfortunately, as the bug report remains unsolved as of the time of this post, there is no viable solution, but what few tests I've run have confirmed that NSHelpManager flat-out ignores the sandboxed help plist on my machine.
OK, this one's been quite a roller-coaster of confusion but it has something to do with with your folder structure setup in Xcode. Here's some things worth knowing:
People opt to put it in English.lproj. Don't do this, for a few reasons. First it won't display the sub-directories/files in Xcode if you dragged the help folder into your file listing, and secondly stuff in that folder is supposed to be flat, not structured.
Create a "help" folder in the root and put your files in that. You can then put them in a sub-directory called "English.lproj" if you want localisation.
Don't create a ".help" folder which contains all of your help files. This seems to break indexing. We don't know why.
Instead, have /help/Contents/stuff and drag and drop that folder into your project directory listing (mine's in "Resources" group). Make sure it's a blue folder and that you can see the entire directory (all of your HTML etc.)
Run the help indexer against it to generate the .helpindex file
Make sure your plist entries reflect the name of that folder and the meta tag name specified in your index.html file
If you follow the above rules things should work fine. It seems in ML that creating a .help folder breaks things from here on out, so basically, don't follow the Apple guide.
I am adding this response here because I found a very dumb way of fixing this. By using Apple's hiutil command line tool, I saw that all Apple's official help books use some sort of indexing using a redirector file:
$ hiutil -Df /Applications/Xcode.app/Contents/Resources/Xcode.help/Contents/Resources/en.lproj/search.helpindex
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
> <plist version="1.0">
> <dict>
> <key>dev01043b473</key>
> <array>
> <string>/redirect.html?topic=dev01043b473</string>
> </array>
> <key>dev0125622ec</key>
> <array>
> <string>/redirect.html?topic=dev0125622ec</string>
> </array>
> ...
Inspired by this, I attempted to generate a .searchindex file manually using NSUnarchiver to open the file created by hiutil, changing it, and using NSArchiver to write back to a file, but my anchors would still not work like I wanted.
I cloned TextEdit's help book based on Apple's undisclosed "Eagle" help engine (/Library/Documentation/Resources/Eagle/index.html), which produces the pretty help books all Apple apps use now. But because I was using HTML indexing, my anchors would lead to plain HTML files, which weren't prettified by Eagle.
Then I struck this dumb idea: It's a lot of work, but if you create a separate html file for each anchor, you can use the meta redirect head tag just like in the redirect.html, except your redirects will be static. Therefore, for my editor-prefs.html file, I created a editor-prefs-anchor.html file with the following contents:
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Editor Options</title>
<meta http-equiv="refresh" content="0;url=../index.html?localePath=en.lproj#/editor-prefs" />
</head>
<body>
<a id="editor-prefs">
</body>
</html>
The meta redirect tag takes care of redirecting to the proper Eagle-powered URL, and it works!
If anyone was struggling with Eagle like me, I hope this helps you!
I ran into this same issue (anchors not working in my app's help book) and did some poking around in the help books of other Apple apps, specifically Safari. I found this interesting entry in the Info.plist in the Safari.help bundle in the Safari app:
<key>HPDBookIndexPath</key>
<string>search.helpindex</string>
I changed this to match the name of the .helpindex file in my app's help bundle, and anchors started working.
Related
I'm generally new to web development so bear with me
I am using threejs and want to load an svg into this using the SVGLoader example but thats not really what my question is about. The function for the svg loading takes a path so what I need is to make the svg file I want to load available somewhere that can be accessed via a path. What I can't workout is how to tell vs code to make file available that isn't referenced anywhere. Whereever I put the files in my folder structure in vs code, it never ends up in the folders in chrome and so I can't reference the file via a path.
I may be misunderstanding something but is there a way of telling vs code to include certain files and copy them over?
for reference, I'm using typescript, vue/vuetify/vuex and threejs in a pane
so need a valid path here:
loadSvgResource('/static-assets/node_selected.svg',(o) => {
...
})
Answering my own question (i seem to do this a lot!)
in the vue documentation it says to place any files needed in this way in the public folder which I have done and then I have added this to the index.html in public for each file:
<link rel="icon" href="<%= BASE_URL %>static-assets/node_selected.svg" >
and the file is here: public/static-assets/node_selected.svg in vs code
then when I come to use the file in the code I am doing this:
aFunction(process.env.BASE_URL + 'static-assets/node_selected.svg')
and that seems to work
So the problem I'm having is that when I either create a new php project or open one of my old projects, I instantly get a small red line under just the < on the html <!DOCTYPE> tag.
The reason this is a problem is because I cannot open my previews in the IDE to see what my index.html file looks like on the browser.
Here is the picture of what I'm talking about:
Looks as if the textmate bundles are used for file highlighting.
Please open the Settings | Editor | File Types page and make sure that *.html pattern is assigned to HTML file type there:
So here's a question. I'm new to Sylius, and am working on some simple CSS updates. I have a local copy of Sylius running with the built-in webserver: server:run. I also have a development server on Digital Ocean, which runs an (almost) identical copy of Sylius, aside from the configs of course.
Something strange is happening with my CSS update, however. I made a change to .navbar-brand within web/assets/compiled/backend_backend_4.css.
This change showed up immediately on my local. On the development server, however, when pulling down the change (git), and verifying that it now exists in that file, the change doesn't seem to propegate. It's effects aren't shown, inspecting the stylesheet doesn't show them, and furthermore viewing the css file sourcecode directly in the browser does not show the change. But on the filesystem it's definitely there.
I've tried clearing the cache, to no avail.
I also checked the assetic value in both config_dev.yml files, and verified they are both set to use_controller: true
Even still, I tried dumping assetic, to no avail.
So I'm wondering what's going on. Additionally, I realize that I probably shouldn't edit CSS files within a folder called 'compiled'. I'm sure there's a way to do that using a compiler, but I'm not yet familiar with the process and am just making minor changes and learning about caching so far.
Yes you are right you shouldn't be editing the compiled files.
You should edit the source files, then run gulp
or on my system i have to explicitly run npm run gulp
I've documented the solution that worked for me here. It didn't involve Gulp at all, but instead uses Assetic:
Assets need to be installed as hard copies first (I'm not quite sure
what this does exactly, but it seems like an important step because
it copies a lot of assets to places. Documentation was unhelpful but
it was suggested on Stack Overflow somewhere.):
app/console assets:install web
Assets should be edited in web/bundles/[bundle-here]/css or js. This
is frequently within syliusweb if it has to do with page styles /
layouts.
Hint: These assets are referred to in files such as
src/Sylius/Bundle/Resources/views/Backend/layout.html.twig (see the
opening:
(% stylesheets
tag, or search universally for this tag).
Within this tag, you'll see that stylesheets have an output to the compiled folder, but also list the
bundles where they pull their original css from. You should edit one of the source css files, if you'd like your changes to end up in the destination css.
After editing assets, dump assetic:
php app/console assetic:dump
Note - it is also possible to set an assetic watcher on these assets
(google to find out how, think it's a -w flag somewhere), but this is
said to only work in development mode, as it should.
After dumping assetic, the assets from the source bundles compile into their assets/compiled versions, usually combining multiple stylesheets. You should now see your asset refresh!
I am not sure why my public assets are not being discovered by play. i am using the same code that works in an activator template in a play2 intelliJ project.
the routes
# Map static resources from the /public folder to the /assets URL path
GET /assets/*file controllers.Assets.at(path="/public", file)
and the html
<img src="#routes.Assets.at(s"images/foo.png")" width="64px">
seem to be correct, and the foo.png is in the public/images folder. the inspector highlights images/foo.png in the html with "cannot find" message. they seem to be being compiled, as they also correctly are placed in the target directory. the rest of the app and html is working fine
what is a possible explanation for this?
Try:
#routes.Assets.versioned("images/foo.png")
Honestly, I have no idea why but I know that it works for me.
Interestingly, there was nothing wrong. it seems that between sbt, play, and IntelliJ, there was simply lag in the resource resolution. after about an hour, everything suddenly worked.
this may not be reproducible, and therefore this question might be a candidate for removal
i'm using inappsettingskit and i have everything working except that it seems to have stopped recognizing changes to my root.plist. i know i've see things before about cleaning out certain directories of xcode but the wierd thing here is that i am changing just the version of the plist file (the last key) and that does show up on my settings page, but all of the changes in the upper part of the plist file are ignored. (my version info is coming from root.plist not info.plist)
any thoughts on this?
Try deleting the app from the phone/simulator and do a clean build.