On Aug 16, 2011, at 2:19 AM, Jan Mauersberger wrote:
Hi Miles,
Yes, we're looking at moving that over too EclipseLabs git, but let me know if you want to commit to my fork.
Well, I just started to check some of the code. However, I recognized that you do work with eclipse 3.7 (I still use 3.6) - some of the dependencies in the manifests are explicitly referring to 3.7 or related newer packages (GMF, EMF etc.). Are these dependencies made by intention or simply the result of the "assiduous" manifest editor?
Yes, a lot of it has to do with exactly as you say with perfect polite wording, the "assiduous" (I'd almost say obnoxious) manifest editor. I wouldn't be surprised though to discover that there are some 3.7 dependencies out there, but I'll try to keep it out of the core stuff as much as I can.
We still haven't really decided what to do about two things: 1. EMF tree editor (e.g. the Sample Model editor, etc..) as well as general EMF.Edit generated editors. That might require a specialized editor though it might be possible to do something with the adapter factory, I'll have to look into that. 2. Layouts. There are a lot of issues with how or if it makes sense to approach actually laying out the editors depending on DOI.
Definitely a bigger issue also for me, probably more interesting than the GMF stuff at the moment. During my experiments I at least managed to get my adapter factory based common viewer filtered based on the active task similar to how MyLyn contributes to Java browser etc.
That's awesome! Do you think you could adapt it to the current setup? Obviously feel free to ask me about how things are setup or make suggestions about how things could be better generalized. There is a tree editor bug there already and I could pass that off to you. My thinking is that ecore editor itself would be the best first target.
