Summary: | [Markers] Problems view redefinable default action depending on marker type | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Norbert Plött <norbert.ploett> |
Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | aleherb+eclipse, andrew.ferguson, angvoz.dev, dalexiev, eclipse.sprigogin, gunnar, jamesblackburn+eclipse, loskutov, miwako.tokugawa, nicolas.lalevee, robin, stori, wladimir.safonov |
Version: | 3.2 | Keywords: | helpwanted |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: | |||
Bug Depends on: | 162505 | ||
Bug Blocks: | 382321, 383619 |
Description
Norbert Plött
2006-08-28 08:19:59 EDT
I think what would make the most sense is an addition to the markerSupport extension point - perhaps we should add something like a markerActionMapping that maps an type to an action. Another possible way to solve this problem is to fix bug 22284. (In reply to comment #2) > Another possible way to solve this problem is to fix bug 22284. Sounds like a silver bullet: Very elegant, but extremely hard to come by. (The bug has been open for years but nobody fixed it) It sure is outside the range of my (CDT) competence. This is also an issue with a view - we should solve it at the UI level not the core level. I see the issue with both our commercial app and open source FindBugs project. In our commercial app (www.verigy.com) we have huge in-memory resources which cannot be mapped to any IResource (we can operate even without to have a single IProject in the workspace). This resources can hovewer have warnings/errors/etc markers, so we are doing extremely dubious operations to create and maintain "hidden" file structure in a "hidden" project => this is the only way we can re-use all existing "markers" views. Of course, this does not work well and we have multiple issues... In the FindBugs plugin (http://findbugs.sourceforge.net/) I'm currently trying to analyse jar/class files which are packaged inside war/ear/etc archives and I'm facing similar issues as in our commercial app... If jar is external, I can create a marker only for the project, but then the marker is absolutely meaningless within all the "markers" views (no sorting/no double click/no goto) and of course the marker is not shown in the (external) class file editor... Of course fixing bug 22284 would be nice thing, but considering amount of changes which would be needed, it is probably not realistic. What is about small but practical solution? I'm wondering if IMarker interface can be extended by adding URI information: "public URI getURI()" method can be used to provide ANY application specific address inside the marker. Additionally, a new "URIHandlers" extension point can be used to serve as support for editor/marker management within IDE (note that this handler is not bound to IMarker interface). possible URIHandler interface: /** * @return non empty array with the list of supported URI "sheme:" parts */ String[] getSupportedURIShemes() /** * (OPTIONAL, if getSupportedURIShemes() is enough) * @return non empty array with the list of supported marker types */ String[] getSupportedMarkerTypes() /** * (OPTIONAL, if getSupportedURIShemes() is enough) * @return true if the given location is supported by the handler */ boolean isSupported(URI location) /** * Open given location within the given page */ IWorkbenchPart open(IWorkbenchPage page, URI location); /** * Navigates to the given location within the given part */ boolean goto(IWorkbenchPart part, URI location); /** * @return human readable location description to show in the UI */ String translateForHumans(URI location); Having that, IDE.openEditor(IWorkbenchPage page, IMarker marker) can first check if there an MarkerHandler is available for given marker type/sheme/location, and then just redirect the call to the handler. The changes to the marker view's can also be minimal: even without the additional getURI() method, the ExtendedMarkersView.openMarkerInEditor() can check if marker's "location" attribute can be parsed as "URI" and if yes, check if there an MarkerHandler available for given uri, and then just redirect the call to the handler. What do you think about it? |