ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Schneider (JIRA)" <j...@apache.org>
Subject [jira] Commented: (IVYDE-208) Ivy Resolve Visualizer
Date Mon, 05 Oct 2009 15:14:31 GMT

    [ https://issues.apache.org/jira/browse/IVYDE-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762211#action_12762211
] 

Jon Schneider commented on IVYDE-208:
-------------------------------------

h4. Thumbnail Previewer

Good work on the thumbnail previewer!  I like it.  It is included in the most recent patch.

h4. Mouse Scroll Zoom
I have some bad news on the mouse scroll zoom functionality.  We would use this method from
the AbstractZoomableViewer:

{code:Title=AbstractZoomableViewer.java}
public abstract class AbstractZoomableViewer extends StructuredViewer {
	public void zoomTo(int x, int y, int width, int height) {
		Rectangle r = new Rectangle(x,y,width,height);
		if (r.isEmpty()) {
			getZoomManager().setZoomAsText("100%");
		} else {
			getZoomManager().zoomTo(r);
		}
	}
...
}
{code}

Unfortunately, the body of ZoomManager.zoomTo(..) is commented out, so this method really
does nothing.  ZoomManager has other methods that could be used, but it is a restricted access
class.  I don't see a way around this at this point in time.

h4.  Search behavior

Currently search highlights matching nodes.  Since the viewer currently can only view one
root node at a time, I don't think it would make sense to change the default behavior to focusing
over highlighting.  What use cases do you have in mind that would benefit from focusing over
highlighting?  The use cases I had in mind for search were:
# Highlighting a particular organization's contribution to the resolved classpath entries.
# Highlighting multiple revisions of a particular module name.

h4.  "Focus on file" behavior changed

What I said earlier about having to resolve before focusing is no longer true.  The focus
action looks for a resolve report on the container state.  If a report is not found, it launches
a resolve and views the results after the resolve is complete.  This process takes place in
a background job; it does not block the workspace.


> Ivy Resolve Visualizer
> ----------------------
>
>                 Key: IVYDE-208
>                 URL: https://issues.apache.org/jira/browse/IVYDE-208
>             Project: IvyDE
>          Issue Type: New Feature
>            Reporter: Jon Schneider
>         Attachments: evicted.gif, focus.gif, ivyde-208.patch, ivyde-208.patch, ivyde-208.patch,
ivyde-208.patch, screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg, screenshot-4.jpg, screenshot-5.jpg
>
>
> I am kind of excited about this one.  I would like to be able to see the resolve report
depicted graphically, showing me clearly how particular dependencies wound up on the classpath,
what nodes got evicted, what dependencies a particular transitive dependency has, etc etc.
 Ivy can sometimes fall into the category of "automagically" doing so much for us on the classpath,
that developers can take it for granted.  Especially when a version conflict arises out of
a resolution (by which two different revisions are resolved that aren't under the same eviction
context), I see developers getting very confused.  I hope this visualization will help them
understand.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message