Community
Participate
Working Groups
For after Eclipse 3.4: The Help Table of Contents and Context Help Editors make it very easy to create the files and adhere to the toc and contexts DTDs for the help system. It would be nice to have a Help Index Editor to create files that adhere to the index.xml DTD for the help system keyword index. Someone I met at EclipseCon 2008 was telling me about all of the trouble he was having creating the keyword index files manually and thought a visual editor would be a big benefit. --Lee Anne
thanks for the suggestion Lee Anne
Hi, Is there any current outlook on this for 3.4? I'm giving a talk next week that includes creating everything you need for a doc plug-in (e.g., toc.xml, index.xml, contexts.xml, plugin.xml, and manifest.mf). I can show easily how to create these in the PDE *except* for index.xml. It sure would be nice to be able to include creating index.xml in that story. :-) --Lee Anne
Ooops, sorry, I meant 3.5!
This is not currently part of the PDE 3.5 plan. It would be nice to round out our UA editors, but no one has committed to working on it. Contributions are always welcome :)
BTW, if we do this. I would like to experiment with an EMF approach. I want to test the waters of how PDE will look with more EMF integration in the future.
> I would like to experiment with an EMF approach. I want to test the waters of > how PDE will look with more EMF integration in the future. You took the words right out of my mouth, Chris. I will try to investigate a bit during this week-end!
Created attachment 116134 [details] A -very- basic EMF based help index editor
Created attachment 116135 [details] Sample file A the moment it is necessary to have an input file like the one attached, because I didn't yet find how to tell EMF to ignore namespaces. The only difference between before and now is : <?xml version="1.0" encoding="UTF-8"?> <index:index xmlns:index="http://www.eclipse.org/pde/ua/index/1.0"> <!-- ... --> </index:index> instead of <?xml version="1.0" encoding="UTF-8"?> <index> <!-- ... --> </index>
Some of the cool things that come with this approach : - JFace databinding + EMF databinding = joy - Undo/redo works out of the box because of the EMF commands - ... so does the Drag&Drop - Dirty state of the editor automatically linked to the state of the EMF command stacks (open the editor, do something, undo it => the editor is *not* dirty) - Forms messagemanager can be bound to the status of the databinding context (not yet shown in this early prototype) - EMF.Edit allows fine tuning on how we want to display our model in a tree, how we want the labelproviders to look like and to react to model changes, which actions we want to enable on which contextual menu, etc...) - Implementing an Outline is very easy and can be done with a generic approach ... and, here are probably many others benefits! :)
As you will notice, there is not "source page" yet in this editor, but it shouldn't be much difficult to have one. However, we have to try to keep the dependencies low, because we may not want adding the full EMF (and TMF[1], perhaps..?) stack (even if it's not that huge) to PDE, thus SDK... [1] http://www.eclipse.org/modeling/tmf/
(In reply to comment #10) > However, we have to try to keep the dependencies low, because we may not want > adding the full EMF (and TMF[1], perhaps..?) stack (even if it's not that huge) > to PDE, thus SDK... What is the plan for the editor? The SDK can't depend on EMF (at least in the 3.5 timeframe) and EMF requires Java 5.0 which is also a problem for the SDK. Is there are a separate project where we could make this available?
PDE Incubator work. In the e4 timeframe, we will most likely have EMF in the SDK so we can take advantage of it. This should serve as an experiment to see what gains we get from using EMF. A lot of the gains are mentioned by Benjamin in comment #9... our UI code could be simplified quite a bit.
Chris, once again you took the words out of my mouth! :p For 3.5, the only thing we could experiment is more JFace databinding, but on a POJO model ...
Benjamin, would you be willing to become a PDE Incubator committer so you and I can continue this work in an open-source fashion and adhere to the Eclipse rules? If so, I'll create a place for this in the PDE incubator and nominate you as a committer so we can experiment in using EMF within PDE editors. We can start small and than move onto something a bit more complex like DS.
Chris, that would be cool, I think it is a *very* interesting topic, and there is still a lot of work :)
oh my EMF in PDE. I was dying without emf working with pde.runtime view recently. go ahead Ben!
Thanks Jacek! :)
Nothing committed for 3.5 here. Removing milestone.
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.
Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release.
