Community
Participate
Working Groups
I am integrating a compiler and runtime system into eclipse. I want to support multiple installations of the compiler and rts. The installations are specified rather like the JDT JRE installs. Within each installation directory resides user documentation which varies between releases. I use an IHelpContentProducer to trap the request for a specific type of documentation (e.g. the user manual) and then use a FileInputStream to retrieve the file for the default installation. If I use an external web browser and open mutliple instances of the help system I can request two different manuals. However because the manual documentation uses relative URLs and there is only a single instance of the IHelpContentProducer, I don't know which manual the href relative URL is being requested for. It would therefore be more useful if the IContentHelpProducer can specify the document base of the requesting document or some such info that makes it possible to distinguish these relative URLs.
In 3.3 there will be two alternative ways to do this kind of thing.. 1. Contribute a new filter type that filters out the runtimes user doesn't care about, and contribute all the books with filters specific to the runtime they're for. So all but the current one will be filtered. 2. Write an ITocProvider which allows you to plug-in code that generates the toc on the fly. So you can get it to point to whichever runtime docs you want.
This bug has been dormant for several years - is this an issue you still care about? As I understand the problem you are using the same class that implements IHelpContentProducer to handle several content from several different bundles - is that correct?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
