Difference between revisions of "AbstractTextEditor Font Management"
(Hints on Managing Fonts in an AbstractTextEditor)
Revision as of 20:00, 5 February 2009
The AbstractTextEditor class is the base class of all the textual editors in Eclipse. If you want to build a plugin that displays text in the main editor area, you will inevitably end up looking at the class as the basis of your work.
By and large, it's pretty straightforward to create your own text editor. The API to this class gives you opportunities to take comprehensive control. One area that is a bit convoluted, however, is font management.
AbstractTextEditor implements a font scheme tied to the org.eclipse.ui.editors extension point. When you define an editor, one of the attributes of the editor extension is a symbolicFontName. If you leave it blank, it defaults to the value of JFaceResources.TEXT_FONT.
The symbolic font name is a key into the font resources defined in org.eclipse.ui.themes. Users can bind specific fonts to these symbolic names in the 'Fonts and Colors' preferences page.
The scheme, then, is as follows:
If you leave symbolicFontName blank, your editor will share the generic Text Editor font.
If you don't want to share the generic Text Editor font, you must define a symbolic font name via an extension in org.eclipse.ui.themes. Then you put that ID into the symbolicFontName. Now users can choose a font that will be applied to all instances of your editor.
This might not be meet your needs. What if you need a more fine-grained control of the font? For example, what if your editor is expected to work with text in different languages, and you want to have the font depend on the language? The theme system doesn't give you any help here.
On first glance, you might think that you were stuck. All the critical functions of AbstractTextEditor seem to be private or final. Things are not quite as bad as they seem.
The mapping from symbolicFontName to a concrete FontData is a preference, stored in a preference store. And you have control over the editor's preference store. This leads to the following scheme.
First, decide how you want to select the font. It might be a preference of yours, it might be a scheme for selecting from multiple of the symbolicFontName fonts. In your editor, set up property change listeners for whatever preferences you want to respect.
Second, create your own preference store. Push the font selection you want into that store under the JFaceResources.TEXT_FONT key.
Finally, create a ChainedPreferenceStore that chains from this local preference store to your normal plugin preference store. Push your chained preference store into the editor.
Now, whenever you get an indication of a change to the font on your preference, you push it into the local store under the TEXT_FONT key, and the editor will pick it up from there.
Note that the PreferenceConverter class is your friend in moving this data around. The TEXT_FONT should be a FontData object. Notification on these preferences (e.g., as managed by a FontFieldEditor) show up as an array of FontData objects.