Open Bug 305142 Opened 19 years ago Updated 8 years ago

Only include Help for installed components

Categories

(SeaMonkey :: Help Viewer, defect)

defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: stefanh, Unassigned)

References

(Blocks 2 open bugs)

Details

Atm you get all the help content even if you choose to not install/build some of
the components (like MailNews, Composer).

This is not an ideal solution, since:

- It's confusing for the users who chooses to not install all the components

- It blocks the usage of entities from the  various prefs .dtd files (bug 287414)
- Iirc it also makes it impossible to  use xbl instead of images in the Help
files (bug 249744)
I'm thinking that you could split the existing toc file into 3 different ones,
one for the 'base' toc and the rest for the app-specific toc's. The same thing
has to be done with the index, of course. The app-specific toc and index should
then be added to the base-toc and base-index if the app is installed.

I've scanned the .xhtml files to see wether there would be an issue with links
pointing to non-existing files(like links in browser help pointing to mailnews
help). It seems that there are very few of those, and I can imagine that we can
work that out quite easy by simply removing them or re-write the text.

I have no immediate solution on how to actually include/exclude toc/index
depending on what you've installed. Neil had an idea of dynamically overlaying
the app-specific toc/index files and then use js to look for them.

CC:ing Jeff, he might be interested of this too (also possible that he have some ideas on how to proceed).
Well, splitting the toc up into separate files for each of SeaMonkey's components does seem like it would work; the only real problem I see is that from there you must somehow be able to take a list of all the possible help file locations and then dynamically create one content pack file that references whichever ones exist at runtime.  I'm currently trying to decide what's the best way to do it.

One way would be to code a custom function which would write such a file and then use it, but that's an utter hack.  It would have to run during some "load" event handler, and even if it were just a check for the existence of the file with file creation only if necessary it would still be ugly and slow.

Another way would be to just hack the help viewer so that it skips over entries it can't find; I don't know off the top of my head how either help viewer processes unfound entries.  The problem with this is that sometime in the future I'd like to start bulletproofing the viewer code, peppering it with throws and other such conveniences to make debugging the creation of a content pack easier.  In the case of a missing file it would be really nice to be able to throw "Database not found" or somesuch so that it's ridiculously obvious what went wrong.

At this point I'm not sure what your solution is going to be.  I'll give it some thought over the next few weeks and see if I can come up with a better solution.

Do note, however, that if I come up with a solution, it probably won't account for componentizing of a glossary; the toolkit help viewer's de-emphasis of the glossary and index in favor of just a table of contents and search results means that having a glossary with entries not relevant to installed components isn't a big issue.
--> Toolkit, since we'll use the toolkit Help viewer.
Assignee: neil → jwalden+fxhelp
Component: Help → Help Viewer
Product: Mozilla Application Suite → Toolkit
QA Contact: danielwang → help
Version: unspecified → Trunk
Product: Toolkit → Seamonkey
Assignee: jwalden+fxhelp → nobody
You need to log in before you can comment on or make changes to this bug.