Bugzilla – Full Text Bug Listing
| Summary: | [context] display task context using Visualiser | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Eugene Kuleshov <ekuleshov> | ||||||
| Component: | Mylyn | Assignee: | Project Inbox <mylyn-triaged> | ||||||
| Status: | CLOSED MOVED | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P5 | CC: | jed.anderson, mik.kersten, mpchapman, wes.coelho | ||||||
| Version: | unspecified | Keywords: | helpwanted | ||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Eugene Kuleshov
This is a neat idea Eugene. I actually helped with the design of the visualizer and so was wondering if such a thing could be useful. When you get a chance, could you write up a description of how you would like to use such a tool? I thought you did. :-) Basically I was thinking of - is an additional data provider for Visualizer that will show interst levels collected by Mylar. I was wondering if that could help to observe most unstable and problematic parts of the code. Similar information probably can be visualized by CVS provider, but it won't have information on dependent resource (e.g. indirectly affected by the original interest). Again, I'm not completely sure what kind of information is actually collected by Mylar, but I'd really like to see it somehow. Yes, we do collect that data, and the Active Search facility finds dependancies. So I think that this kind of visualization support might make sense. I still don't have a sense for how much people use the visualizer for coding though, beyond demos for which it's great :) I'm going to add this report to our list of interesting enhancements, which I'll be putting online before too long. As you mentioned before, it would be cool if I could just tag it and that would happen automatically! Here's an update on my adventures with the visualiser so far: The version of the visualiser that is available for download independently from AJDT doesn't seem to work properly for Eclipse 3.2. An error is reported when you try to access the preference page, which is necessary for setting the provider (error invoking code from ___.jface). I tried to get the visualiser to use a stub Mylar provider without access to the preference page by setting its priority very high in plugin.xml, but this didn't work. Out of the box, the visualiser doesn't seem to display Mylar landmarks when using the default Resources and Markers provider. I haven't figured out why not yet. One of two versions of the visualiser that are available from CVS under the AJDT project works as a stand-alone project after removing a dependency on AspectJ from the manifest and editing the .project file so that the regular java builder is used. This visualiser uses a different plugin.xml schema than the downloadable version. I'm assuming it would be best to target this version and hope that the visualiser download is updated soon. As a first cut on the Mylar provider's functionality, should it just show the classes and declarations in the currently active composite context that have a DOI greater than some threshold value? Yes, your assumptions sound right, and it is best to target the version in CVS that you describe and worry about merging and distribution issues later (since that will be relatively wasy with the Visualiser being a Technology project). As a first cut, I suggest the following: - Populate the visualier with the interesting resources. To get them call: MylarPlugin.getContextManager().getActiveContextResources(); - Color the file bars according to the degree of interest. A simple and naive and Java-only implementation could be something like: - for each line in the file get the corresponding Java element - call MylarPlugin.getContextManager().getNode(identifier) .getDegreeOfInterest().isInteresting() Yes, your assumptions sound right, and it is best to target the version in CVS
that you describe and worry about merging and distribution issues later (since
that will be relatively wasy with the Visualiser being a Technology project).
As a first cut, I suggest the following:
- Populate the visualier with the interesting resources. To get them call:
MylarPlugin.getContextManager().getActiveContextResources();
- Color the file bars according to the degree of interest. A simple and naive
and Java-only implementation could be something like:
- for each line in the file get the corresponding Java element
- call MylarPlugin.getContextManager().getNode(identifier)
.getDegreeOfInterest().isInteresting()
and if true color it, identifier is IJavaElement.getHandleIdentifier()
Note that this isn't a marker-based based approach, and I think that a
marker-based approach will be too limited for us. If this starts working we can
consider using the highlighter to show relative interest levels, showing which
parts were viewed and which were edited, shwing predicted interest, etc.
Oops, this bug wasn't assigned to me and I didn't put myself on the cc list so I just got your message now. I implemented a simple provider that works much like you suggested except that landmarks appear in a darker shade of blue than members that are just interesting. I used getContextManager().getActiveContext ().getInteresting() instead of the call you suggested. This seems to work but please let me know if I should change it. It would be good if you could take a look at this initial implementation and let me know of any changes I should make. There are a few complications though. The provider is currently implemented in a new project rather than in the sandbox because I didn't want to make it necessary to have GEF to use the visualiser. Does it makes sense to add a new project, maybe also calling it a sandbox? The other snag is that the only visualiser where I could get the preference page to work was the 1.1 version from CVS. This looks like an older version and requires some tweaking to make it run. I will try harder to the the version in AJDT_src work and maybe get some help from the people who maintain it. It's probably best if you look at this after I get that sorted out but I'd be happy to send you the project and three steps for getting the 1.1 visualiser ready if you would like to look at the Mylar provider sooner. Besides working out the Visualiser preference page problem, I still need to look into writing some test cases for the provider. Matt: could you take a look at comment #7 and let Wes konw which version of the Visualiser he should be extending? Wes: regarding API use that's right. And no, you can feel free to give the sandbox a dependency on GEF, since part of the point of the mylar.sandbox is that it can have all sorts of dependencies until we figure out where things should go, and nothing in there gets released. So feel free to attach the patch for me to take a look at. Wes, I recommend using the version of the visualiser from under AJDT_src in CVS. It is newer than the standalone version, and the preference page works perfectly for me under Eclipse 3.2M2, when installed as part of AJDT. To build it from source, you need to install AJDT first, as it is an AspectJ project. Alternatively you can take a built version from AJDT - the only other dependency it has is on the org.aspectj.runtime plugin. Hope that helps, Matt. Created attachment 28193 [details]
Patch for mylar.sandbox
Here is a patch containing the first draft of a simple visualiser provider for
Mylar. Thanks for the comments, Matt. What I ended up doing is installing the
latest developer build for AJDT and making the sandbox depend on the visualiser
plugin. The preference page works great in this version and the visualiser has
the updated look (and the porting wasn't a big deal). I also tried taking the
visualiser jar from the plugin and putting it in the sandbox project. This
compiled but at runtime the visualiser didn't pick up the Mylar provider. So at
the moment the visualiser plugin from the latest AJDT developer build (3.2M2)
must be installed for the visualiser to work.
Note that the provider seems to be working but is not even close to being well
tested :)
Mik, are you going to include this provider with Mylar? I wonder if you can include Visualizer runtime to the Mylar update site... Thanks Eugene, I don't think that it's acceptable to ask people to update using an additional update site, so we do have to come up with a convenient way to download the Visualiser once our integration is done: 1) include a Visualiser feature on our update site 2) only depend on the Visualiser as a JAR and bundle that JAR In the end I think that we should move towards (1), and hopefully at some point the update manager will allow us to depend on a feature that's part of another update site (I recall a bug being open for that). But until we figure out what UI it may be better to do (2). E.g., we might just have a Task Context Visualization view with multiple layouts and as such not need a Visualiser view that supports multiple providers. How do you see yourself using the Visualiser for task contexts? I figure that I'll want it for inspecting task contexts when I'm looking at an old or unfamiliar one, and perhaps before committing. Wow, nice work! I did some quick tests, it updates the context model as I navigate, and overall looks quite impressive. I'm also impressed with how elegant and slim the extension is (so kudos to the Visualiser folks too :) I've moved this to a new project which you'll need to check out called org.eclipse.mylar.viz (that's where we can put the force directed stuff too, once that gets more mature). I also did some refactoring and extension point clean-up, so take a quick look at that. I hope to make the viz stuff a new feature that depends on a Visualiser feature, hopefully coming from the AJDT update site. Let's consider some UI issues for this. How about we have the higlight color come from the task context? This can be really useful if you enable mutlipe task contexts (try it by turning on this Task List preference, it already works). This should mimick Mylar's label decorator to get the colors so that it's consistent. This would mean that the Visualiser menu probably wouldn't be used to assign colors. But would that break the extensibility model at all or is it doable? One other checkbox that could be relevant to add to the menu is predicted interest (DegreeOfInterest.isPredicted() || .isPropagated()). - We could have the default color come from the context (unless the context color is white) and then allow users to change the color with the visualiser menu if they really want to. Should it use a darker shade of the context color for landmarks and a lighter one for predicted interest? (In reply to comment #15) > We could have the default color come from the context (unless the context > color is white) and then allow users to change the color with the visualiser > menu if they really want to. I like this. It provide enough flexibility. > Should it use a darker shade of the context color for landmarks and a lighter > one for predicted interest? I was going to suggest to add these 3 colors to Mylar color chooser... then bolding may become redundant or at least could be choosen by the users. To make the change to have java members colored according to their highlight color, I need to get the context id corresponding to the java member (so the id of the context can be used to get the corresponding task and then the highlight color). IMylarElement memberContextNode = MylarPlugin.getContextManager().getNode (member.getHandleIdentifier()); gets me a CompositeContextNode, but CompositeContextNodes don't have IDs and I get null when I call getContext() on this node. Any ideas on how to get around this? CompositeContextNodes do have ids. What I'm really looking for is the parent "context" containing the "context node" that corresponds to the java element. The method compositeContextNode.getContext() looks like it should return the node with the highest interest that it contains. Is this considered the parent context node? Either way, the result is null. I'm hoping that you don't need to worry about nodes at all, and CompositeContextNode's are an implementation detail. If what you have is a node, then you can easily get it's highlight color from UiUtil. Will that suffice or am I missing something? If what you have is the element then you just need to get the node for that element. If it's not as easy as that then I should give you some additional API, because the mapping from node to context needs to be handled by mylar.ui (e.g. for nodes that appear in two contexts it has a mode for highlighting them in a different color). Also, regarding Eugene's comment relying on mylar.ui (i.e. UiUtil or some additional API) will ensure that decoration of all views is handled in one place, making customization easy. I have a node (CompositeContextNode) and I can probably get the color from UiUtil, but what I also need is the context that the context node belongs to so that I can get the context ID which I can then use get the corresponding task so I can get the name of that task for the visualiser menu. (I get null when I try to get a task corresponding to the CompositeContextNode itself) Whenever possible try to use IMylarElement and don't cast to CompositeContextNode (which is about to be renamed fyi). There seem to be seperate issues here: 1) getting the highlight color and label for each task - get the list of active tasks: MylarTasklistPlugin.getDefault().getTaskListManager().getTaskList().getActiveTasks() - to get the highlighter call: MylarTasklistPlugin.getDefault().getHighlighter().getHighlightColor(task) - to get the label call task.getDescription(true) 2) don't use per-task highlighters, and instead always check the highlight color when drawing the stripe by asking UiUtil what the highlight for that particular stripe should be. Let me know if that helps... I need the particular task whose context contains the IJavaElement for which the visualiser wants a stripe rather than a list of active tasks. Is there an easy way to get this? (I need that task so that I can create or find the IMarkupKind corresponding to the task so it can be assigned to the stripe. The IMarkupKind corresponds to kinds that show up in the visualiser menu.) By the way, I'm using IMylarElement (I just know that it's a CompositeContextNode because I'm trying to figure out what's going on). Gotcha, I hadn't understood that's what you were doing. For that you can use UiUtil, but it was probably failing because your askign for the highlight for a type or file, and those tend to have a propagated or predicted interest (and as such no highlight color). I added a new method: UiUtil.getBackgroundForElement(element, resolveContextColor) If you set resolveContextColor=true you should get the color associated with the context, not the element. If that doesn't work let me kow where that method is failing. That should be great for getting the color, but I also need the actual task (that corresponds to the context that contains the IJavaElement) so that I can get the text string name for the visualiser menu (and so that I know what IMarkup kind to assign to the stripe). Oops, right. I just added a new method, let me know if it does the trick: MylarContextManager.getDominantContextHandleForElement(..) Created attachment 28347 [details]
Patch for mylar.viz
Thanks for the new API, Mik.
Here is a patch containing an updated provider that allows multiple contexts to
be displayed in different colors. There are a number of issues for further
discussion on this:
- Currently, the color comes from the highlighter color for the task unless:
a. The task color is too light. In this case the default color (blue) is used.
"Light" is currently defined as colors with RGB values greater than 225, 225,
and 200, respectively.
b. The color for the task has been overridden using the visualiser menu.
- Since each task now has a single color, there is no way to differentiate
predicted or propagated interest, so the visualiser currently does not show
elements with predicted or propagated interest.
- When should visualiser menu items go away? Currently, once a task with a
context is activated, its corresponding item stays in the menu. Is it
worthwhile to try to set up a mechanism to remove a task from the menu if it is
not active yet preserve the settings in case it becomes active again?
I applied the patch and it's looking very good. The issues with updating the list of tasks are a problem, but I think the root of the problem is the fact that the Visaulizer Menu is not a very useful view when Mylar is around. And I cosider the cost of imposing an additional view on users to be extremely high. I need to mull over this for a couple of days, and will post some thoughts on the UI. In the meantime, if anyone has ideas on use cases for visualizations of task contexts please consider posting them on this report. Wes, I think that we have all the pieced that we need to wrap this up and you've done the hard work, so let's plan to pair program on it this week. Sounds good. If you can think of any changes or new features that should be added to the visualizer provider before a prototype is made available, please let me know. (In reply to comment #30) > If you can think of any changes or new features that should be added to the > visualizer provider before a prototype is made available, please let me know. I have one. Not really related to this issue, but as a general visualizer UI improvement. If you have time can you take a look at issue 85624. Thanks. https://bugs.eclipse.org/bugs/show_bug.cgi?id=85624 Hi Eugene, thanks for posting a link to that report. I think the visualiser rendering you propose could be more effective for advanced users. The Mylar context visualiser is currently only a data provider for the Visualiser so it's limited in how the data is presented. Although it may be possible to contribute a new rendering to the Visualiser I think it's beyond the scope of the current prototype for now. Agreed. Let's get the Visualizer support released, and then prioritize enhancements such as the horizontal-style rendering. Wesley: I've been cosidering having the mylar.viz component contribute a *single* view that provides the Visualiser's SeeSoft layout, but can also render using other layouts (e.g. the spring graph view from Zest). I'm thinking this could be better than adding a new view for each visualization that we support. But my concern here is that there are only two vizualizations on the table. And the use cases may be quite different because the SeeSoft layout is source-line specific and the spring viewer is about elements and relations. Part of what's bugging me is that the Visualiser adds two new views, and I feel like the menu view should be a drop-down or dialog. But maybe the right solution here is for us to propose that straightforward patch, and try to use the visualizer directly? (In reply to comment #33) > Part of what's bugging me is that the Visualiser adds two new views, and I feel > like the menu view should be a drop-down or dialog. But maybe the right > solution here is for us to propose that straightforward patch, and try to use > the visualizer directly? BTW, menu view can be used as a quickview, so it won't take any screen real estate. I agree that it doesn't yet make sense to make a common Mylar visualization view while there are only two very different visualizations available. Regarding the two-view requirement for the visualiser: Now that the color is determined by the highlighter and the contexts to show are determined by the active contexts in the task list, can we just use the visualizer without the visualizer menu view? Yup, the Visualiser menu is totally redundant with the task list. We basically have a special cased Visualiser, and what I think that we should do for now is not use it as plug-ins, just use the JAR and provide our own single view. I do want to make sure that we don't fork the Visualiser and instead contribute back changes, and would like to depend on it in plug-in form at some point in the near future. But at this stage our use is just too different and the current UI isn't right. This will also ensure that Mylar builds out of CVS (which has always been the goal but was broken by the Visualiser dependency) and doesn't require multiple update sites. FYI: I've been trying to get this to work using only the visualiser jar but I keep getting errors saying that the extension points are unknown. I've tried copying the extension point schemas to the project as well as parts of the original visualiser plugin.xml but I haven't had any luck. The errors don't occur when I have the visualiser project from cvs open, only when I close that project. I've tried copying all but the source folder into the mylar.viz project but this didn't help. I'll keep trying but please let me know if you can think any ideas to try... It may be that there are some extension points hard-coded into the Visualizer. But it could also be the runtime Eclipse being confused if you're seeing problems after copying over the extension points. You should try to run this in a fresh runtime workspace and ensure that the configuration data is cleared, and that you're using the right set of plug-ins. But I plan on taking a look at this myself tomorrow, since deciding how to couple to the Visualiser is a major decision. I haven't even been able to get it to run yet using only the jar. If you're going to take a look at this tomorrow then it would be great if we could pair it :) Sounds good. Let's plan to meet up. Folks, please consider to use visualizer as is. There are too many views already and also there could be some conflicts with the visualizer that is contributed by AJDT. For the record, the standalone version of the Visualiser has been updated: http://www.eclipse.org/ajdt/visualiser/ This version, 2.2, is built from the latest available source, and works on Eclipse 3.1 onwards, including 3.2M3. To reduce the dependencies, this release does NOT require AspectJ at runtime (only development-time aspects are used in this project). Also, the previously bundled draw2d.jar has been removed (only SWT is required now), and the visualiser plugin can be used as a single JAR file. Wow, that's excellent Matt! Perfect for our needs. I'll plan to figure out how to integrate this next week. Eugene: how do you see yourself using this feature? To keep open when coding, or for reviewing contexts after reactivating? I could imagine it being useful for reviewing multiple contexts (e.g. everything done this week), but we don't have a good UI for that yet. We will need this for context attachemnts, as described in: http://dev.eclipse.org/mhonarc/lists/mylar-dev/msg00341.html Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn |