Modify Tool User Interface

[chbrown13]

Wherever values of that variable are set outside of class. Private class and local variables don't have top boxes

[chbrown13]

Not sure what's the best solution for adding the boxes. SWT Widgets? http://www.eclipse.org/swt/widgets/

[CaptainEmerson]

Good question for those of us experience in SWT magic. Two prior implementations to look at...

See upper right of Figure 4.10 in http://repository.lib.ncsu.edu/ir/bitstream/1840.16/9727/1/etd.pdf Here's a starting point for the implementation: https://github.com/DeveloperLiberationFront/FixBugs-Code/blob/master/QuickFix/edu.ncsu.csc.emh.fixbugs.code12/src/edu/ncsu/csc/emh/fixbugs/ui/resolutions/FixBugsLinkedPopup.java

See figure 5.5 in http://people.engr.ncsu.edu/ermurph3/papers/dissertation.pdf

Implementation: https://github.com/DeveloperLiberationFront/refactoring-tools/blob/master/edu.pdx.cs.multiview.smellDetector/src/edu/pdx/cs/multiview/smelldetector/detectors/featureEnvy/FeatureEnvyExplanationWindow.java

[chbrown13]

Ok cool, thanks.

[chbrown13]

Boxes should only pop up when actual parameter is selected.

[chbrown13]

Remove radio buttons from the text box.

[chbrown13]

Temporary UI view- do we care about blocking the Eclipse menu/panel at the top and bottom?

[CaptainEmerson]

You almost certainly want panels nestled right into the editor itself, rather than shells floating above it. This would require some significant hacking, and I don't have any good examples where it's been done before. I think the JavaEditor has a special StyledText. Whatever the StyledText's SWT parent is, you could try to put in some extra panes or something.

[jssmith1]

@CaptainEmerson Something like this?:

Except the plugin Plugin dependencies/console views would be our up/down viewers

[chbrown13]

Do we still want to keep the tool inside of the editor? When we started that was going to be the main advantage of our plugin to make it different from other tools i.e. Call Hierarchy.

[CaptainEmerson]

Yes, still inside the editor. What you have two comments ago is not quite what I had imagined -- the windows wouldn't be separate, they'd be inside. Sort of like the gutter (with disclosure arrows and painted markers) at the left and right of the current editor, but instead on the top and bottom.

[chbrown13]

Might be possible to create a new editor and try to add the new panels there.

[CaptainEmerson]

If you mean a new JavaEditor, I wouldn't try to subclass that or extend it -- it's pretty impossible. What I'd try to do instead is figure out what StyledText the JavaEditor is using, and cram a new widget above and below it.

[chbrown13]

Ok

[chbrown13]

Figured out how to add the panels inside the editor!

[chbrown13]

Things left to do:

• Add links into the shells * Add a listener to redraw the boxes whenever the screen size changes
• Find a way to keep the shells on top when focus is lost but not cover up other applications

[jssmith1]

@chbrown13: After scrum today, @CaptainEmerson brought up a few comments about the current design. One issue we might have with these boxes is that the tops/bottoms of the code view cannot be visible. I.e., If the user scrolls to the top of the view, the box obstructs lines 1-3. I think he was imagining something in the same UI element as the breadcrumbs/horizontal scroll bar.

[chbrown13]

http://grepcode.com/file/repository.grepcode.com/java/eclipse.org/4.2/org.eclipse.jdt/ui/3.8.0/org/eclipse/jdt/internal/ui/javaeditor/breadcrumb/IBreadcrumb.java

[chbrown13]

http://grepcode.com/file/repository.grepcode.com/java/eclipse.org/4.2/org.eclipse.jdt/ui/3.8.0/org/eclipse/jdt/internal/ui/javaeditor/breadcrumb/EditorBreadcrumb.java?av=f

[CaptainEmerson]

Good find!

[chbrown13]

Don't think the breadcrumbs will be possible without recreating the Java editor.

[CaptainEmerson]

Give us some details so that we can help. I guess what you're saying is that there's no extension point to add breadcrumbs. Extension points are just one way to extend Eclipse -- there are others.

One way is to use reflection to navigate the object graph to get the SWT widget you're interested in, then cram in the new widget you want.

Another way is to copy of the class you want to modify into your own source directory, placing it in exactly the same package (e.g. org/eclipse/jdt/JavaEditor or whatever, though I wouldn't copy JavaEditor if you didn't have to -- I'd try to do something smaller). Your copied class will take precedence over the existing class.

[chbrown13]

Ok, do you have any good examples of the second two options? I was unable to find an extension point without using the entire org.eclipse.jdt.ui package.

[CaptainEmerson]

I looked, but I don't. I've done it though, but it's been quite a while. Try it with a simple example, make a small change to the copied class (e.g., add a println), and see if it works for you.

[chbrown13]

Should the packages be copied over into the project like this? No luck so far.

[CaptainEmerson]

Looks right to me. What do you have in those packages? Start with only one class. Does it seem to be compiling? What change did you make in the class? What do you mean by not working?

Can you show the corresponding class file under Plug In Dependencies?

[chbrown13]

I added a bunch of print statements to classes in the new packages (org.eclipse.jdt.internal.javaeditor: ToggleBreadCrumbAction.java and JavaEditorBreadcrumb.java, breadcrumb: BreadcrumbViewer.java and EditorBreadcrumb.java) but nothing prints out when starting the Breadcrumb while the plugin is running. The project compiles and the plugin works fine.

[chbrown13]

Plugin project dependencies

[tyler-albert]

I noticed earlier that my version doesn't highlight text. Check that I didn't mess up the build path or anything build related.

On Friday, February 12, 2016, Chris notifications@github.com wrote:

Plugin project dependencies [image: image] https://cloud.githubusercontent.com/assets/4522684/13020405/3a4d143a-d1a3-11e5-8a3e-3ad0604829eb.png

— Reply to this email directly or view it on GitHub https://github.com/DeveloperLiberationFront/Program-Navigation-Plugin/issues/8#issuecomment-183489499 .

[chbrown13]

Looks good to me, I made some changes to your branch yesterday so that the selected variable should highlight.

[CaptainEmerson]

Simplify. First, remove all the copied code you made. Try setting a breakpoint in the original class. Make sure you can debug through it, and inspect the variables. Second, add one and only one new class. Now add a variable in a method. Set a break point on it, and see if you can inspect its value. This should help you determine which class (the original, or the copied one) is actually being executed. If the old one is still being executed, there’s something wrong with the class loading or compilation order. At this point, I’d either mess with the compiler and runtime settings, or start doing some googling.

Another technique that might help is simplifying. Create a basic hello world class, and package it up into a jar file. Then, make a new project, load the jar file on the classpath, then copy the original file into the source. See if you can successfully do this simpler version of code replacement

[chbrown13]

Ok

[chbrown13]

HelloWorld example kinda worked but occasionally get java.lang.IncompatibleClassChangeError exceptions.

[chbrown13]

I was able to change it when something imported a class from the same path and extend that but we aren't importing anything from the package with the breadcrumbs so checking to see if there's some other way to connect it.

[chbrown13]

Made lots of progress with adding the breadcrumb view, working on integrating with Tyler's changes and trying to figure out how to add one at the bottom.

[chbrown13]

Added border to separate breadcrumb from editor and tabs

[CaptainEmerson]

:+1: