Bug 343201

Comment 1 Miles Parker 2011-07-11 20:17:45 EDT

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.

Comment 2 Benjamin Muskalla 2011-07-12 06:24:55 EDT

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.

Comment 3 Miles Parker 2011-07-12 13:24:01 EDT

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.)

Comment 4 Miles Parker 2011-07-12 13:25:54 EDT

(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.

Comment 5 Miles Parker 2011-07-21 17:56:22 EDT

(This is essentaily complete, but we won't resolve until we get the code actually submitted.)

Comment 6 Miles Parker 2011-07-21 18:20:26 EDT

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?

Comment 7 Miles Parker 2011-08-15 23:39:35 EDT

This is complete, except for properties.

Comment 8 Miles Parker 2011-08-17 21:11:45 EDT

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.