Trying to reduce necessity to manually craft a XAML style, I’ve added presentation parameters and tab coloring rules to Tabs Studio. While a custom XAML style allows seamless integration of different visual adornments together, it takes some time to make it right. Presentation parameters are a new layer between a default style and a custom style. It implements most common style options thus simplifying a custom XAML style.
Presentation is a new tab in Tabs Studio options and it replaces the Quick Style dialog. Font size, Close tab button style and Animation are now presentation options instead of a part of Quick Style generated style. Selected tab style, Previously selected tab and Non-document tab options from the old Quick Style dialog can now be represented as tab coloring rules:
A tab coloring rule has 5 filtering options and a definition for a tab background brush. Checked boolean options apply the rule to tabs with the corresponding property set to True (e.g. IsTabSelected), unchecked – to False and undefined – to all tabs. Regular expression options apply Regex.IsMatch with the corresponding property (e.g. TabName) when the regex is not empty (see Regular Expression Language Elements MSDN page for .NET regular expressions details).
Two more examples. The Forms rule applies to tabs with the name starting from Form when this tab is not selected and not previously selected. The WindowsFormsApplication1 project rule applies when tab’s project name contains WindowsFormsApplication1 and tab name doesn’t start from Form.
Tab background definition must be a Brush descendant. Different options to specify a color in XAML are listed on the Color documentation page.
Everything that presentation parameters do can be achieved in a XAML style. For example, the following style is equivalent to what a tab coloring rule generates internally:
<Style TargetType="TabsStudio:Tab" BasedOn="{StaticResource DefaultTabStyle}"> <Style.Triggers> <MultiDataTrigger> <MultiDataTrigger.Conditions> <Condition Binding="{Binding Path=IsTabSelected, RelativeSource={RelativeSource Self}}" Value="False"/> <Condition Binding="{Binding Path=IsPreviouslySelectedTab, RelativeSource={RelativeSource Self}}" Value="False"/> <Condition Binding="{Binding Path=IsDocument, RelativeSource={RelativeSource Self}}" Value="True"/> <Condition Binding="{Binding Path=TabName, RelativeSource={RelativeSource Self}, Converter={StaticResource RegexMatch},ConverterParameter='^Class'}" Value="True"/> <Condition Binding="{Binding Path=ProjectName, RelativeSource={RelativeSource Self}, Converter={StaticResource RegexMatch},ConverterParameter='^Windows'}" Value="True"/> </MultiDataTrigger.Conditions> <Setter Property="Background"> <Setter.Value> <SolidColorBrush Color="Red"/> </Setter.Value> </Setter> </MultiDataTrigger> </Style.Triggers> </Style>
There is one more convenience feature to set tab color. On the right click context menu there is now the Set color… command:
When adding a new rule using this command the options are pre-populated with the tab item parameters and when a matching rule(s) already exists then the Set Color choice dialog is presented:
Download link: TabsStudio v2.1.6.
This functionality look promising, but may I suggest to add under Tab name a Tab extension regex? Unless I miss something I can’t use a regex like ^.*\.cpp$ to enable a color for c++ file (for example). Could be usefull IMHO
Comment by Laurent — November 9, 2010 @ 1:17 am
Laurent,
A Tab extensions regex certainly can be added. Do you want to color “.h”, “.cpp” and “.cpp .h” tabs differently? Or do you want to color C++, C#, VB tabs differently? Or is it something else?
Comment by Sergey Vlasov — November 9, 2010 @ 9:07 am
As I’am working with C# and C/C++ files currently, I would like to colour differently depending on the language, i.e. the file extension.
Comment by Laurent — November 9, 2010 @ 8:32 pm
I thought about using Project.CodeModel.Language and Project.Kind properties for coloring by language, but a document paths regex looks more universal and reliable. So I’m adding the paths regex.
Comment by Sergey Vlasov — November 10, 2010 @ 8:19 pm
Use of Visual Studio was a good idea, but it’s a bit tricky to use, especially for developer not aware of Visual Studio eXtensibility.
Path is a better way IMHO, and it’s provide new possibility: using color to distinguish location. For example, I use different location depending on the kind of source (driver, VSX, etc.).
Thank you for adding that by the way 🙂
Comment by Laurent — November 10, 2010 @ 8:39 pm