Bugzilla – Full Text Bug Listing
| Summary: | [rulers][api] Provide simpler way to add a decorator to a composite ruler | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Yaniv Inbar <yaniv> |
| Component: | Text | Assignee: | Tom Hofmann <eclipse> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | daniel_megert, david, ekuleshov, stori |
| Version: | 2.1 | ||
| Target Milestone: | 3.3 M1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Yaniv Inbar
Kai please comment Post 2.1 *** Bug 136909 has been marked as a duplicate of this bug. *** . *** Bug 137830 has been marked as a duplicate of this bug. *** See bug 137830 for another request for adding a decorator: before or after a given column. To provide this a column would need an ID. *** Bug 85751 has been marked as a duplicate of this bug. *** From bug 85751 comment 3: If we added API for contributed columns, we would probably also provide an abstract base implementation taking care of boilerplate code and offering some event/notification mechanism for line-events (like "line selected", "line clicked"). One problem that would arise is that we have to stay compatible with the existing API of CompositeRuler. CompositeRuler makes some assumptions about the contained ruler columns (e.g. every column consists of a single Canvas and no child controls) that we should get rid of before adding the API. Other questions that need to be answered: * context menu - should the ruler continue to show the same context menu for all columns, or should a column (optionally) be able to have its own? * accessibility - with more and more information in the ruler, can we offer a way to make the ruler accessible (e.g. give focus to the ruler)? * painting: currently all ruler columns implement their own double-buffer painting, which may not scale well. * column ordering - this is currently done by the editor as the controlling instance - how would ordering work with arbitrary columns? * overview ruler - should there also be additional overview rulers? probably... * resizing - should rulers support (horizontal) resizing? this would be interesting to "expand" the condensed information upon user request (In reply to comment #8) > * painting: currently all ruler columns implement their own > double-buffer painting, which may not scale well. I add up to 20 columns, and haven't seen an issue with performance. Maybe deal with this if/when it becomes a problem? I have released a first cut of the extension point work > 20060727. The code and extension point is still in the flux - interested parties are encouraged to provide feedback. The earlier the better. - New extension point org.eclipse.ui.workbench.texteditor.rulerColumn - allows to add columns - target a specific editor (by editor id), or a content type and its subtypes - specify placement relative to other columns and by weight - implementations must subclass org.eclipse.ui.texteditor.rulers.RulerColumn - RulerColumnRegistry supporting the extension point in org.eclipse.ui.texteditor.rulers package. Interested editors can query for columns matching an editor. - AbstractTextEditor (RCP) supports the extension point by initially creating all matching columns that set the 'enable' attribute to true. - An editor's rulers can be managed via the IColumnSupport interface that can be queried via getAdapter(IColumnSupport.class). IColumnSupport allows to show and hide specific columns. - AbstractDecoratedTextEditor adds a generic editor preference that stores which rulers are currently enabled (supported by RulerColumnPreferenceAdapter). Rulers that set the "includeInMenu" attribute to true get a ruler context menu entry to show/hide the column. - As proof-of-concept, the annotation ruler column code has been removed from AbstractDecoratedTextEditor and replaced by a contribution to the extension point. =============== Open questions: - is the targeting mechanism (by editorId, contentTypeId) flexible enough, too flexible, just right? - is the placement mechanism sufficient? What would be the alternative? - is it a good thing to make IColumnSupport accessible to the outside? This gives anyone that can get a hold of the editor the power to add and remove columns from the vertical ruler. =============== Remaining issues: - provide a default subclass of RulerColumn that contributors can use and that takes care of much of the painting, mouse handling etc. code. - rework the line number column to use the extension point. The hard part is that AbstractDecoratedTextEditor has API (createLineNumberRulerColumn, fLineNumberRulerColumn) that we have to support, and also the somewhat complicated combination of line numbers / quick diff / revision info. - all the fancy additional stuff mentioned in comment 8: - resizing - custom context menu - accessibility Fixed > 20060803 As said, the extension point and basic implementation is there. AbstractTextEditor does no longer respect the extension point to not break existing subclasses. However, the org.eclipse.ui.texteditor.rulers package contains all the code to read ruler contributions, so it is easy for editor implementations to support the extension point. AbstractDecoratedTextEditor fully supports the extension point and manages the set of visible columns in a preference. The line number and quick diff columns have been reworked to use the extension point as well. The remaining issues are captured here: - bug 152744: resizing, context menu, accessibility... - bug 152743: abstract base class for column implementations verified in I20060807-2000 by implementing my own ruler Is there any way to create multiple instances of a column, parameterized to display different information at runtime? Currently in createPartControl of my editor I create multiple instances of my column, passing parameters to the constructor to differentiate the columns. (I parse the document and pass the parsed representation along with a parameter that defines which aspect should be displayed by the column.) I assume you mean via the new extension point. If so, your column can implement IExecutableExtension and then configure it in setInitializationData(...). Use the IConfigurationElement to check which ruler it is. |