Community
Participate
Working Groups
Improve structure of existing documentation. The Eclipse help books are currently black boxes. There is no easy way to insert additional material into an existing Eclipse book, such as adding a section describing a new tool. And there is no way to incorporate portions of the Eclipse books into some other book. The Eclipse Platform help books should be restructured in a more modular manner by making better use of existing help system capabilities. [Platform, JDT, PDE, Platform Help] [Theme: User experience]
I posted to the eclipse.platform newsgroup on a related topic and was pointed to this bug report. The idea is to improve the usability of the help system by improving the co-existance of various plugins. The key to the approach is to extend what can be done with perspectives. I have also described a similar problem and solution for action set contributions. See bug #36968. Here is my post: --- We have written a plugin for our programming language. Now we would like to include documentation for it. We have hit a few problems. We would like to rely on Eclipse documentation for providing help on core plugins like the debug view. It is a waste of effort for us to duplicate the documentation of generic components, and it is impossible to guarantee that our docs would be for the correct version of Eclipse as someone can run different versions of our plugin with different versions of Eclipse. The strange thing is that the debug view is documented by org.eclipse.jdt.doc.user. Why are generic components part of the JDT docs? This is unfortunate because it means that our users will have to read JDT documentation in addition to the documentation for our language. This JDT documentation talks about generic issues (e.g. step into) and JDT specific issues (e.g. step with filters). So to a new user who is trying to learn about the debug view, it is not even clear what is JDT-specific and what is generic to the view. Does anybody have ideas or experiences on how to go about integrating documentation in a workable way? Are there any planned enhancements to the documentation infrastructure? Are there any plan to refactor the documentation so that the generic views will have their own docs? In an post to this news group called 'Scope of Actions' (May 5, 2003), I discussed what really amounts to the same issues, but for action contributions instead of documentation contributions. I think the same approach would work for documentation. The idea is that on a per perspective basis, the user would have the ability to customise which doc contributions to show or hide (as can be currently done like with action sets). Then we could create custom debug and editing perspectives and initialize them to show the generic docs and our docs. The JDT docs would not show up by default (but users, of course, are free to customise any perpspective any way the see fit). This is a long term solution since is requires enhancements to how perspectives work, and it requires a refactoring of the docs which are currently part of a JDT plugin. It is straight forward to get a plugin up and going. But when it comes down to trying to prepare a polished release, co-exisitance issues block the way. I think that better use of perspectives is the key to providing proper co- existance of plugins.
*** Bug 112863 has been marked as a duplicate of this bug. ***
This is no longer a plan item.
This has been fixed long time ago.
