| Summary: | [modeling] create figure filter 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: | greensopinion |
| Version: | unspecified | ||
| Target Milestone: | 0.9 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 351894 | ||
|
Description
Benjamin Muskalla
I think hiding is going to be problematic / challenging / interesting depending on POV. This is actually a task that gave me that "uhoh" feeling when first looking at the overall modeling bridge project. I think that hiding arbitrary parts of diagrams and then linking back up the individual parts could actually be a hard problem in the deep sense of that phrase, at least for generic diagram types. You need to know all about the semantics of what connections mean, which means actually having a meta-model that encodes that at the M3 level. (See http://en.wikipedia.org/wiki/Meta-Object_Facility.) Imagine the case where you have objects of interest for two UML modeled classes, and one of those objects has a containment relationship to a filtered object, while the other one has a association with that same filtered object. How do you represent the relationship between the un-filtered objects? Or do you just reveal that third object? But then where do you stop with these intermediate objects? Anyway, a bit ambitious. ;) OTOH, perhaps I'm making this out to be more complicated than it really is. David, I've cc'd you, perhaps you have some thoughts on how / if the hiding part could be accomplished? The soften part is "easy" at least for specific diagram types, so perhaps we could just make all of the other elements really really small. ;) I could imagine something like this: O = object in context - = any relation ~ = fading line representing a hidden object O---O~~~~ So, essentially you don't see the objects that are not in context but you see the outgoing connections that will fade into nothing. In combination with the Alt+Click behavior, we can then show the next level of references. Don't take this as set in stone - this is just an idea I had when thinking about this feature. Miles, this comment on the mailing list might be of interest here. Maybe we can automatically create such "views" to focus diagrams? ---------- Forwarded message ---------- Hi Miles, I was reading your project description: "In order to bring the productivity benefits of the task-focused interface to engineers using Eclipse-based modeling technologies, Tasktop will create a “Context Bridge” for EMF-based models and diagram editors. The result of this will be a focused mode for diagrams that shows only the elements related to the task-at-hand, dramatically reducing information overload for engineers working on large models" I don't really understand because in UML you can already create views which will only display relevant UML information coming from large models. Just drag and drop or use a contextual menu in order to select relevant UML elements and it is displayed immediately in a new diagram. Did I miss something ? Vlad, [I am hoping I am not being rude for reposting this here, but it's the same community and both public, so I hope it's ok] (In reply to comment #2) > I could imagine something like this: > > O = object in context > - = any relation > ~ = fading line representing a hidden object > > O---O~~~~ > It's a neat idea. Effectively you would need to represent the node invisibly, which would mean that you would have to know how that node related to other nodes. But here's the part that gives me a bit of a pause: Let's take the case of a simple Class diagram, where we are representing nothing but the class names and relations. Here, once you have all of the relations to a given Class, you've effectively defined that class as a node. So you could do one of two things.. 1. Have all of the "fading out" edges pointing to one invisible node. But then, why not make it visible? Maybe we should make it visible but faded. This would be analogous to showing the closest neighbors in the call graph in the context for JDT. (Is that how things work now?) Where should we stop with this process? This isn't at all an unsolvable problem but practically speaking you would end up with much more information than you would in the analogous JDT case -- my rough guess would be 2-3 times as many nodes as were actually focussed. 2. Have the fading out edges associated with dummy nodes, i.e. you could have more than one "invisible proxy node" representing any given filtered class. OK, now you know that the object is related to *something*, but you don't know *what* so you won't know if you're interested in it until you actually look. This is the general expanding context issue, I guess. But wouldn't you simply want to alt-click to show all relationships? Or perhaps you'd want to alt-click for each type of relationship, e.g. associations, containment, etc.. The issue then is that you would have to lay out the new items dynamically. Do you alter the existing diagram or create a new one, and if the latter containing what? What do you do with the relationships between those newly added nodes and other pieces? Suddenly you have a node existing that wasn't before, and other un-filtered nodes have a relationship to it. Parenthetically, this get's into an area that I'm really interested in, which is moving away from these sort of static art representations on UML and so on and making everything fully dynamic and self-reconfiguring but that's for another day... Sorry, but that's quite a bit of thinking out loud! Bottom-line, the above all assumes that we want to play with layout. If we simply want to fade things out but keep the existing full size layout then again that should be straightforward. So perhaps we should make that the target for now. (In reply to comment #3) [Vlad said on mailing list] > I don't really understand because in UML you can already create views which will > only display relevant UML information coming from large models. Just drag and > drop or use a contextual menu in order to select relevant UML elements and it is > displayed immediately in a new diagram. > Did I miss something ? Actually, come to think of it, if UML tooling already has this feature, we could simply use that feature to auto-populate a new diagram. I'm not sure if that is a general GMF capability or not, does anyone know? We'd have to do that on every change of context, but if the performance was decent, and people were happy with using auto-layout diagrams -- this might be the simplest way to go. But there are some user experience issues to deal with in this case. If a user opens an original hand-edited diagram up, we'd have to think about how that's associated with the auto-created context filtered diagrams and I'm sure there are other issues to figure out. So I'm still inclined to start with simply fading non-context elements out but I need to spend some time playing around with the UML tools and see what might fit in most easily/naturally. (In reply to comment #3) > Miles, this comment on the mailing list might be of interest here. Maybe we can > automatically create such "views" to focus diagrams? (In reply to comment #5) > Actually, come to think of it, if UML tooling already has this feature, we > could simply use that feature to auto-populate a new diagram. Um, the reason I'd "come to think of it" was that that was what Thomas had just said. Duh.. Just a quick update on this. This ends up being one of the key parts of the effort. It's taking quite a bit of time to get various aspects to work. For example, there is the issue of what to do with reference highlighting. There aren't actually EMF model element analogs for these that map to the diagram domain object WRT class hierarchies for example. Also, some of these aren't decorator managed, so I've had to play a lot of games with managed figures to get this to work properly. It still doesn't totally, right now I'm struggling with getting the edges to appear on first activation of a node that is connected with a reference to existing nodes. But the parts that do look pretty cool. :) Please feel free to reopen if you'd like to see things handled differently. Easy to change. |