Community
Participate
Working Groups
Currently, the DawnGMFEditorSupport class makes a critical assumption about the nature of its integration into a GMF-based editor: that the IDawnEditor implementation is the DiagramDocumentEditor generated by GMF, not some proxy or adapter for it. This assumes that the editor is the Dawn-generated subclass of the GMF-generated editor, that mixes in the IDawnEditor interface. For integration of CDO into Papyrus, this is awkward because I am trying not to generate 14 Dawn-specific subclasses of each of the 14 Papyrus diagram editors (not to mention that Papyrus lets end-users generate their own diagram editors, too). The approach I am taking is to inject the Dawn plumbing into the existing diagram editors using Papyrus's own extensibility mechanisms. Accordingly, the IDawnEditor that I supply to the DawnGMFEditorSupport is not actually the diagram editor but an adapter that delegates to it. Thus, I need to be able to customize the way in which the DawnGMFEditorSupport and its cohorts obtain the real diagram editor from the IDawnEditor (currently Dawn assumes that it can cast the IDawnEditor as a DiagramDocumentEditor).
Created attachment 226216 [details] Patch for IDawnEditor adapter support Attached a patch that implements support for IDawnEditors that are IAdaptable to DiagramDocumentEditor instead of actually instances of the latter. The DawnGMFEditorSupport provides an API for getting the GMF editor from an IDawnEditor and replaces straight-up casts with this API. Also, the DawnGMFEditorSupport provides a provides a new hook for subclasses to create custom DawnGMFHandler implementations. I use this in Papyrus to post edit-part refreshes asynchronously on the display thread, because Papyrus has edit-parts that update GEF/SWT objects when refreshing, requiring the display thread.
Requesting code review from Martin, if he has the time (please indicate if not; I will adapt).
Adding Martin to cc (it seems that e-mails referenced for review requests are not notified by Bugzilla).
Created attachment 226224 [details] patch v2 Hi Christian, great changes. There is only one small thing to mention. You forgot to update the Manifest.MF exported packages regarding the version increment. I fixed that with patch v2. Apart from that: Great work! Thanks for your effort and please go ahead and commit the patch :)
Btw. I recieved the review request by mail :)
(In reply to comment #4) > > great changes. There is only one small thing to mention. You forgot to > update the Manifest.MF exported packages regarding the version increment. I > fixed that with patch v2. Thanks, Martin! That's a good point. I would have expected some warning or error from PDE or API Tools ... I'll double-check and if I don't see it flagged, I'll report the issue. (In reply to comment #5) > Btw. I recieved the review request by mail :) OK, good. Thanks for letting me know. Bugzilla didn't mention it as usual when submitting changes to a bug.
commit 246e19229f3937236e1062e712a378b292b4f7ab
(In reply to comment #6) > (In reply to comment #4) > > > > great changes. There is only one small thing to mention. You forgot to > > update the Manifest.MF exported packages regarding the version increment. I > > fixed that with patch v2. > > Thanks, Martin! That's a good point. I would have expected some warning or > error from PDE or API Tools ... AFAIK. that's nothing the mentioned tools would ever check and that's one of the reasons why CDO committers are expected to install our own versioning tool. Compare http://wiki.eclipse.org/CDO_Source_Installation#Prepare_the_IDE You'll like it!
(In reply to comment #8) > > AFAIK. that's nothing the mentioned tools would ever check and that's one of > the reasons why CDO committers are expected to install our own versioning > tool. Compare http://wiki.eclipse.org/CDO_Source_Installation#Prepare_the_IDE > > You'll like it! Thanks, I do! I realize now that I was missing it, before. However, now I see that the release.xml file is has an out-of-date version number for the org.eclipse.emf.cdo.dawn.gmf plug-in in which I just bumped the version number. But, the version tool didn't complain. Should I update the release.xml? Or is that something that you will do closer to release time?
(In reply to comment #9) > However, now I see that the release.xml file is has an out-of-date version > number for the org.eclipse.emf.cdo.dawn.gmf plug-in in which I just bumped > the version number. But, the version tool didn't complain. > > Should I update the release.xml? Or is that something that you will do > closer to release time? I always regenerate the release.xml directly after a release so that it captures the released versions. Not the to-be-released versions ;-)
The release.xml and release.digest files are similar to an API baseline.
(In reply to comment #11) > The release.xml and release.digest files are similar to an API baseline. Ah! Thanks, that explains why it looks woefully out of date. :-) Hands off, then.
Available in R20130213-0014 (4.1.2)
