Bugzilla – Full Text Bug Listing
| Summary: | [modeling] create figure highlighter for diagrams | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Benjamin Muskalla <b.muskalla> |
| Component: | Mylyn | Assignee: | Miles Parker <milesparker> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | mistria, shawn.minto |
| Version: | unspecified | ||
| Target Milestone: | 0.9 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 343212 | ||
| Bug Blocks: | 351894 | ||
|
Description
Benjamin Muskalla
This has similar issues to bug 343217 -- we can't really reach into existing GEF editors unless we have some way to associate the editor with an underlying artifact if indeed there is one and with GEF that's all arbitrary. We could provide an API that a GEF implementor could use and then implement that for specific GEF based editors such as Papyrus UML but I think we might want to base that on the underlying model instead. Overall, my thinking is that we should focus on the underlying model as what we base the context on, and then provide some sort of mapping(s) to the views based on that. I'm not worried about the above issue anymore. :) If someone wants to have us support their EMF based tool, they just need to give us access to the appropriate domain node and that is exactly what EcoreDiagram at least has done. Aren't adapters wonderful? But now I realized something else that I'd like feedback on. Unlike what is the case with say Java, the presentation of a diagram element has semantics. (Duh.) So we can't just go willy-nilly changing the color shape, font etc.. of a diagram element. The user isn't going to be very happy if they've just spent a bunch of time coloring their diagram elements and then later on we go and turn them all light-gray. We can't simply keep track of the prior state and restore it either, because then we're looking at contention with user changes. One possiblity is to use decorators, but I don't think that's going to give us what we want in terms of visual decluttering. :) There is of course the same issue with layouts though there we might simply create a separate "focused" layout. I suppose we could do something similar here, but that sounds potentially pretty nasty -- then we're trying to keep two different edits synchronized and we're still left with the problem of the user not being able to edit presentation. Thoughts, anyone? I don't know how the coloring and such works exactly, but is it possible to highlight in making it bolder / darker or maybe the other way round, make everything not within the DoI a bit brighter or even opaque? or just print the label in the figure bold(er)/bigger, similar to what happens in the package explorer for Java focussing? (In reply to comment #3) > I don't know how the coloring and such works exactly, but is it possible to > highlight in making it bolder / darker or maybe the other way round, make > everything not within the DoI a bit brighter or even opaque? > > or just print the label in the figure bold(er)/bigger, similar to what happens > in the package explorer for Java focussing? The trouble is that these are all model related changes at least for the GMF implementations. This is one of the reasons that the GMF stuff seemed a little less certain that the GEF pieces. In GEF you can get finer grain control, but with GMF you have to go against their underlying model if you want to change something on the visual side. I think. One possible approach is to actually add an alpha layer to the viewer that would hide/obscure the elements underneath, but that would probably be significantly more involved. It might also be possible to get into the GEF model underneath the GMF stuff and override behavior, but both of those options would involve The other major issue is that UML at least has all sorts of typography and diagram related semantic meaning. For example, abstracts and interfaces are italicized, dash-lines indicate different relationships than solid lines, etc.. Even bold outline can be significant for some diagrams. So color and opaqueness would probably be the way to go. It would certainly be a possibility would be simply to say "if you want to use Mylyn focussing with your editing, you have to give color to us". :) Some kind of contract like that.. Hm, maybe the communities input would be valuable here, and waiting with this story until there is at least some input here A GMF diagram context is made of 2 parts: * The semantic model * The diagram notation model (contains the description of the diagram: location of items, color, fonts...) When the end-user manipulates diagram, he relies on the GMF Runtime APIs to modify the semantic and/or the notation model, This changes the model, and then these changes are propagated onto the diagram using GEF or Draw2d, and can be perstisted. Basically, GMF is a MVC: GMF APIs manipulates controllers that change models and views (Figures). However, you can manipulate the diagram directly with the Draw2d layer to update figures (views). If you change .setBackgroundColor on the figure, you directly modify the view, and this does not affect the underlying semantic and notation models of the diagram. These changes won't be persisted, they won't change on the underlying files, the editor won't become dirty. At anytime, you'll be able to restore the status of the diagram as it is defined in the notation model. I think Mylyn should read GMF models to detect the changes, and then highlight the changes on Figures using Draw2d. This won't affect any semantic of GMF. For the EMF compare integration with GMF, the approach we are taking right now is to use a GMF decorator (which is displayed in a dedicated GEF layer . the Decorator has to provide its figure (in our case a red/green/blue shape around the original Figure). As it's a decorator its not changing any model (being the notation or semantic one). The problem with the decorator approach is that I don't think you can achieve some kind of "opacity change on existing figures". I guess you would need to hijack the GraphicalContext before the paint() of the original figure to change the opacity.. (In reply to comment #7) > The problem with the decorator approach is that I don't think you can achieve > some kind of "opacity change on existing figures". I guess you would need to > hijack the GraphicalContext before the paint() of the original figure to change > the opacity.. Actually, I've done some other work recently with this and discovered that you can successfully overlay an alpha in a GEF layer. So unless GMF Runtime is somehow preventing the full use of GEF layers it is something worth trying. I will definitely check out EMF Compare -- it sounds like we have the same kinds of issues -- in fact there could probably be some kind of generic GMF / GEF figure annotation approach (I hesitate to say "model" because we probably have enough of those.. ;) ) (In reply to comment #6) > However, you can manipulate the diagram directly with the Draw2d layer to > update figures (views). If you change .setBackgroundColor on the figure, you > directly modify the view, and this does not affect the underlying semantic and > notation models of the diagram. These changes won't be persisted, they won't > change on the underlying files, the editor won't become dirty. At anytime, > you'll be able to restore the status of the diagram as it is defined in the > notation model. > > I think Mylyn should read GMF models to detect the changes, and then highlight > the changes on Figures using Draw2d. This won't affect any semantic of GMF. I did some futzing with this already, and my concern is that it won't work or won't work reliably. At least with only a couple of hours exploring I couldn't find a way for a) to change something in the GEF model and then b) cause a refresh of the GEF diagram without also reloading the GMF state thus losing what I had just done. Basically, when I made a change directly to the GEf model, GMF simply replaced that with the backing graphical model, which makes sense. There may be a hacky way to do this that I haven't found yet, but if I can get it to work, I'm concerned that it is really subverting the intent of the framework so that we'll always be dealing with trying to prevent GMF from doing what it wants to do. OK, have a solution for this one. I've tested using decorators -- that seems to work quite well and they are not persisted so we don't have to worry about making the editor dirty, etc.. The idea is to use an alpha layer that will modify itself based on context changes and model interaction. This works -- except for landmarks-- but an important question to everyone: how should we actually highlight items? What's the difference between that and simply showing them? In other mylyn contexts such as JDT, there isn't actually a highlight the item simply isn't shown when the user hasn't focussed. The intiial implementation drew a box around the highlighted items, but isn't that redundant? Regarding highlighting, I think we run into the same trouble as with other decorations: what is from Mylyn and what is diagram specific. While I'd suggest to make things in bold font if they are a landmark (same as for JDT in the Package Explorer) but that could clash with some diagram semantics. Wonder if it makes sense to have different shades for the different elements, eg. * no context, hidden * in context, 10% alpha layer * is landmark, no alpha layer Does that make sense? (In reply to comment #12) > Regarding highlighting, I think we run into the same trouble as with other > decorations: what is from Mylyn and what is diagram specific. While I'd > suggest to make things in bold font if they are a landmark (same as for JDT in > the Package Explorer) but that could clash with some diagram semantics. Wonder We can't muck with fonts very easily -- the decorator scheme isn't set up for that. And yep, they're really semantic. > if it makes sense to have different shades for the different elements, eg. > * no context, hidden check. > * in context, 10% alpha layer > * is landmark, no alpha layer So, with say a JDT class isn't it the case that something that is in context but isn't landmarked is just using the default presentation? That's why I was thinking that we might just leave the default case as is. There is another complication here, the GMF decorations actually steal the mouse events. That's fine for the hidden, I just remove the decoration on mouse-over. But it doesn't work for say the clack outline approach that I'd been experimenting with. We could draw four lines instead, but that's somehow not very satisfying. But we could also remove the highlight on mouse over. I don't know if that would look weird or not. It probably would if we were highlighting and then that highlighting went away. The more I think about it the more I think the 90% approach is a good one, though that might not really make much of a visual difference. I could also do a yellow which would be a sort of "highlight marker". I'll play with different approaches. If this is getting too complex to implement, we should consider ignoring the difference between "in context" and "landmarked" for now and push this to the end as a "nice to have". Or is there any progress currently since your last comment? (In reply to comment #14) > If this is getting too complex to implement, we should consider ignoring the > difference between "in context" and "landmarked" for now and push this to the > end as a "nice to have". Or is there any progress currently since your last > comment? I think all of the work on the figure masking part will make this much easier, but I think the bigger question is "does it make sense"? IOTW, given that everything that isn't "not-interesting" (masked) is "interesting" (right?) then doesn't that imply that there isn't a category in between? In which case, why highlight it? BTW, not apropos this bug, but since we're on the topic, I'm going to have to spend a bit of time with landmarks in Java code as I've never used them. Do you have some good use cases for where they make sense just so I can get a sense for what might be appropriate in a modeling context? If you get a chance, take a look at the very latest I just pushed using an ecore diagram (papyrus still hasn't been tested.) That will give you a better sense for how the masking is working. Kind of cool, I think. :) (In reply to comment #15) > I think all of the work on the figure masking part will make this much easier, > but I think the bigger question is "does it make sense"? IOTW, given that > everything that isn't "not-interesting" (masked) is "interesting" (right?) then > doesn't that imply that there isn't a category in between? In which case, why > highlight it? If I understand context right, the distinction between "in context" and "a landmark" is how important it is. A landmark will never (almost never I guess) get removed from context again without the user actively removing it, since it's "degree of interest" is way higher than normal context entries. Added Shawn, he should be able to provide better input Shawn, and others.. I guess I really am confused then. Because working on a practical level with contexts -- and I'm embarrassed to say that its only recently that I've used it regularly -- what I see is that something either is in context or it isn't. So if I click on a Java element say, it is no longer grayed out if the package explorer isn't focused, and it appears when the package explorer is focused. When I look at the API for example for IInteractionObject I see support for interesting, but not for landmark, though landmarks are there in places. In the help docs, there is: Interest manipulation Ctrl+Shift+Up: mark as landmark Ctrl+Shift+Down: mark less interesting So they seem elided somehow but I'm not really sure. This is all related to bug 343212 as well. The good news is that all of the infrastrucutre is in place so we can do whatever we want here, but I'm just not sure what the right thing is. Again, I think what I'm doing with the masking helps a lot but the more I play with it the more I think we do need some kind of positive indications as well. OK, I'm sorry, I think I've finally figured this out. :) I was trying to landmark resources and that doesn't really make sense. When I landmark a method say it shows up in bold. We can do something like that. I guess the thing is that you cn't go from "landmarked" to just interesting and that was where I was getting caught up. I'm actully thinking now that landmarks might be useful on both the class or even atrribute level. Done. We aren't actually doing this per se, instead we're supporting markers. Please feel free to reopen if you'd like to see things handled differently. Easy to change. |