Community
Participate
Working Groups
EMF model editors should be able to propagate selection events so we can track and add them to the context.
All we need to do here is to register as a listener for selection events. Not sure if we can get EAttribute level -- that's done in property editor -- but that wouldn't add much value anyway if we can't.
There is already some monitoring in place by Mylyn we can use for this. The initial contribution also contains such a monitor to track interesting events. Other things to consider: selections in outline Property editor tracking would be really cool - but we should decide this based on a cost-benefit equation.
Yeah, I'm still trying to figure out what sort of level of granularity works best for Mylyn. If we do an a analogy to Java code, then there we want method level tracking, but not (excluding accesesor method) field level? Similarly, I could see wanting EStructural Relation (attrbiutes and references) level for Ecore, but it seems doubtful that we'd want to filter properties. Though... now that I think of it this really could be useful for Ecore derived models, we often end up with a lot of properties and EMF allows catergorization of them, i.e. "Basic", "Advanced" etc. So there is a filtering mechanism. But this ends up being a cross-cutting concern. As a kind of simple minded example, if I'm working with updating internal documentation of EMF models (noone actually does this, but bare with me :)) it would be really cool if Mylyn could see that and then highlight description property / move it to top / hide other properties. But this wouldn't be for a specific EClass that I was editing, it would that for all classes I opened in my "dcoumentation" task, those properties would be highlighted. Is there an analagous thing that Mylyn does now for a different context bridge? I mean thinking about it this could be a real killer feature. (Though still not something we should probably tackle for this go around.)
(In reply to comment #2) > Other things to consider: selections in outline Yes, the EMF editor works in an interesting way. Because the EMF editor really already *is* an outline in that is a tree structure. On the other hand, you might use an outline to navigate to particular parts of an EMF target model editor.
(This is essentaily complete, but we won't resolve until we get the code actually submitted.)
I think we'll skip property changes, that is property changes on model items themselves. In other words, if a user were to select an attribute, we'd track that change, but -- we wouldn't track to the level of granularity of the properties. For example, in the case where someone was editing an *.ecore* model, as opposed to an .ecore derived model, on selecting "Library" and then a Library attribute like "Address" and then selecting address and setting the type to "String", the last item would *not* have an interaction element created. Make sense?
This is complete, except for properties.
OK, this task was a little confusing. I think it's actually about dealing with EMF.Edit Tree efforts. It's not at all clear that we'll need to do the selection stuff -- I think that will probably be handled magically by existing EMF editor but we can reopen if that isn't the case.
