The past several days we’ve been cleaning up code (running code analysis, fixing XML comment errors, making sure all strings are resources, etc.) as we finalize the features for the first public beta of SyntaxEditor for WPF.
One area that still needed some work is themes and how highlighting styles function. We implemented a lot of neat features that will make it easy to have your apps work just like how Visual Studio does.
Configurable UI properties via XAML
First, as a base default for themes, we allow easy configuration of SyntaxEditor UI elements via simple properties on the SyntaxEditor class. For instance, say you’d like to set the background of the line number margin. For that, you’d use set the LineNumberMarginBackground property. Want to set the font size as well? You’d use the LineNumberMarginFontSize property.
These properties can be set via XAML Styles, directly in XAML on SyntaxEditor instances, or programmatically.
That’s all fine and good, however we wanted to allow you to get really advanced by optionally giving end users the ability to change all aspects of the editor UI. Some end users really value the ability to create dark or other alternate themes for their editors.
Using display item classification types and related styles
As we looked at Visual Studio’s settings dialog, on the Fonts and Colors page, you can change the styles used for all logical classification types. However they also have special classification types for things like Plain Text and Line Numbers etc.
We’ve updated our own infrastructure to define several similar “special” display item classification types. If you choose to register them, they will appear in our version of the Fonts and Colors page and will allow end users to override those aspects of the editor’s UI.
In terms of priority, any non-default value of a display item style will take precedence over a related default SyntaxEditor property setting (described in the previous section). If the display item style’s property is a default value, the fallback value of the SyntaxEditor property setting is used.
In the screenshot above you can see the first four items in the list are the new special display item classification types. All the rest were added for specific languages. The classification types are also properly ordered such that Plain Text, being the most important, appears at the top of the list, followed by other special display items. Then the remainder of classification types are sorted alphabetically. The classification types are automatically sorted this way for you via the IHighlightingStyleRegistry.ClassificationTypes property, which is what the ListBox is bound to.
Regarding the controls on the right of the list, we currently are using the brush picker included in the Sample Browser, but in the final WPF Studio 5.0 release we plan on using a new BrushEditBox that is part of Editors for WPF. We have built a small text style preview control that appears at the bottom right of the screenshot. It updates dynamically when a new display item is selected, or one of the related style properties is changed. This small preview control is included with SyntaxEditor.
So to sum up, when the display item classification types feature is used, end users can change the style properties for Plain Text, etc. Changing the Plain Text style alters the default foreground and background of the editor. Line Numbers alters the foreground/background of the line number margin, etc. With these features, it’s easy to implement an options dialog just like in Visual Studio. The screenshot above is from our open source QuickStart.
Dynamic updates to UI
Regardless of whether you change the standard WPF display properties on the SyntaxEditor or if you change display item classification type styles, the changes are reflected immediately in the SyntaxEditor user interface.
End-user editing capabilities of highlighting styles
During our work, we also found that for some styles, it doesn’t make sense for users to be able to alter certain properties. For instance, a Visual White Space display item only needs to have its Foreground configurable. It wouldn’t make sense to allow Bold or Italic.
Thus we have also updated our IHighlightingStyle interface to have properties that indicate which properties can be altered in a user interface.
In the screenshot above you can see how the Indicator Margin display item only allows the item background to be selected since none of the other properties really make sense for that item.
Importing Visual Studio .vssettings files for themes
One final thing we did to really show off these new features is to allow import of Visual Studio .vssettings files to define the styles used in the editor. This is really cool.
A while back, Scott Hanselman posted links to a bunch of VS themes that people have defined. See this URL:
http://www.hanselman.com/blog/VisualStudioProgrammerThemesGallery.aspx
So with one line of code, SyntaxEditor can import any of these settings files and update itself appropriately. Our main demo will show this off once released. It has an Import Visual Studio Settings… menu item on the File menu that allows you to pick a .vssettings file and import it, even in XBAP.
Here are some screenshots of various themes from that site loaded into SyntaxEditor:
Again, all it took was one line of code to load those.
Nearing public beta release
I know a lot of you are anxious to get your hands on this product to start working with it. I hope by these blog posts, you can see the level of detail we’re putting into the design of features and why the product has taken a while to get to this point.
We plan on starting on documentation topics and adding some preliminary designer support shortly. After that, it should be ready for public beta!