Community
Participate
Working Groups
In order to manipulate context elements such as version control information or break points the context editor tab should provide extensibility for contributing additional data. This could either be implemented through a structure bridge like extension or using the common navigator framework.
Shawn, how does Tasktop do that for the web browser integration? Does it use a CNF extension? Sebastian, thanks for the proposed implementation at https://git.eclipse.org/r/#/c/6337/. It's a feasible approach but the changes to IContextContributor look very similar to structure bridges so I'm wondering if there is a common abstraction? Or could we actually implement a structure bridge for breakpoints and similar elements?
Tasktop does this via the CNF as we have support for showing the web context structurally in the project explorer. This seems like the most reasonable approach, if we can have a structure bridge, otherwise, maybe we need support to add a section like the invisible elements for extra information like breakpoints that will never fall below the interest line
Sebastian, are we actually going to track interest for the breakpoints (or for change sets for instance)? I'm wondering if the concept of a structure bridge could still make sense even if we didn't track interest. It would be a very generic and extensible mechanism to visualize and manipulate hierarchical structures. It would be particularly useful in this case if the operations that we need to support are the same such as removing from context.
(In reply to comment #3) > Sebastian, are we actually going to track interest for the breakpoints (or for > change sets for instance)? Tracking interest for breakpoints is not planned as of yet, but might make sense in the future. For example we might link the interest of file related breakpoints (e.g. java line breakpoints) with the interest of the file, thus removing the breakpoint when the file becomes uninteresting. Or also find other ways to play with interest... for example, a breakpoint which was hit only once might become less interesting than a breakpoint used several times. More or less, the only reason for the proposed change is to hide complexity. I'm not sure if structure bridges provide the same capabilities, but it's in fact possible to realize it with cnf. I pushed a prototype implementation of a breakpoints plugin using the proposed API. Perhaps it helps to see if it's similar to structure bridge implementations: https://git.eclipse.org/r/#/c/6338/1/org.eclipse.mylyn.context.breakpoints/src/org/eclipse/mylyn/internal/context/breakpoints/BreakpointsContextContributor.java This class provides anything required to display and manage breakpoints in the context editor.
(In reply to comment #4) > Tracking interest for breakpoints is not planned as of yet, but might make sense > in the future. For example we might link the interest of file related > breakpoints (e.g. java line breakpoints) with the interest of the file, thus > removing the breakpoint when the file becomes uninteresting. Or also find other > ways to play with interest... for example, a breakpoint which was hit only once > might become less interesting than a breakpoint used several times. I would be very cautious about automatically deleting breakpoints since they would not be easy to get back and deleting them means a loss of information. Automatically disabling them *might* be useful. My experience though is that sometimes important breakpoints are set on methods that would not even otherwise be part of the context, meaning that their DOI is low, so we might need a different way of determining the interest of breakpoints.
(In reply to comment #5) > I would be very cautious about automatically deleting breakpoints since they > would not be easy to get back and deleting them means a loss of information. > Automatically disabling them *might* be useful. My experience though is that > sometimes important breakpoints are set on methods that would not even > otherwise be part of the context, meaning that their DOI is low, so we might > need a different way of determining the interest of breakpoints. Agreed. I'll open another bug to further discuss interest handling for breakpoints. I just pushed an alternative implementation of the mylyn debug plugin based on AbstractStructureBridges instead of new API for discussion. Please have a look at Patch Set 3 of https://git.eclipse.org/r/#/c/6338/. It seems to produce more code than the former approach, but implementation was pretty straight forward. So I'm good with both ways.
(In reply to comment #6) > Agreed. I'll open another bug to further discuss interest handling for > breakpoints. https://bugs.eclipse.org/bugs/show_bug.cgi?id=385479
This is already supported by the structure bridge.
