Open
Bug 305142
Opened 19 years ago
Updated 8 years ago
Only include Help for installed components
Categories
(SeaMonkey :: Help Viewer, defect)
SeaMonkey
Help Viewer
Tracking
(Not tracked)
NEW
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)
Reporter | ||
Comment 1•19 years ago
|
||
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.
Reporter | ||
Comment 2•19 years ago
|
||
CC:ing Jeff, he might be interested of this too (also possible that he have some ideas on how to proceed).
Comment 3•19 years ago
|
||
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.
Reporter | ||
Comment 4•17 years ago
|
||
--> 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
Assignee | ||
Updated•8 years ago
|
Product: Toolkit → Seamonkey
Reporter | ||
Updated•8 years ago
|
Assignee: jwalden+fxhelp → nobody
You need to log in
before you can comment on or make changes to this bug.
Description
•