-
Notifications
You must be signed in to change notification settings - Fork 3
🪟 Window contexts
Window contexts let you limit layers or individual assignments to specific windows.
A context can match:
- a process name
- a window class
- a window title
- a predefined group
- nested combinations of all of the above
This is useful when the same event should behave differently in different applications, windows, tabs, panels, or other title states.
By default, a layer is active everywhere, and assignments inside it follow the layer's scope.
If a layer has window rules, Cadans checks the currently active window and decides whether that layer should be active in the current context.
Individual assignments can also have their own window rules. By default, an assignment rule is combined with the layer rule, so the assignment is available only where both rules match.
An assignment rule can start with ! to override the layer rule for that assignment:
!firefox.exe
This makes the assignment use its own rule instead of being limited by the layer's rule. Leave the assignment rule empty to follow only the layer rule.
Context tracking is enabled only when at least one active layer or assignment uses window rules, automatically switches to a simplified tracking mode when no active rules contain title conditions, and relies on Windows event subscriptions rather than continuous polling.
Layer window rules are configured in the layer meta editing form. Assignment window rules are configured in the assignment editing form.
The following sections describe what kinds of conditions can be used inside those rules.
Use executable names as shown in Task Manager:
firefox.exe
chrome.exe
explorer.exe
Process names are case-insensitive.
For explicit syntax, you can also use:
p:firefox.exe
Use the c: prefix to match a window class:
c:XamlExplorerHostIslandWindow
This matches windows whose class is XamlExplorerHostIslandWindow.
A class can be used either as a standalone condition or as a refinement of another condition:
explorer.exe[c:XamlExplorerHostIslandWindow]
This means:
Explorer windows whose class is XamlExplorerHostIslandWindow
Use the t: prefix to match a window title using a regular expression:
t:^Cadans|^GitHub
This matches windows whose title starts with Cadans or GitHub.
Title rules use AutoHotkey regular expressions (PCRE-based syntax).
You can also refine a process or class with a title rule:
firefox.exe[t:i)Cadans]
explorer.exe[t:^Task View$]
This means:
Firefox windows whose title, by current tab, contains Cadans (case-insensitive)
Explorer windows whose title is exactly Task View
You can also refine refinements:
explorer.exe[c:XamlExplorerHostIslandWindow[t:^Task View$]]
This means:
process is explorer.exe
and class is XamlExplorerHostIslandWindow
and title is exactly Task View
Nested rules are useful when one process contains many different internal windows or panels.
Use - to invert a condition level.
-firefox.exe – all windows except Firefox
firefox.exe[-t:Google] – Firefox windows, excluding titles containing Google
-firefox.exe[t:Google] – all windows, except Firefox windows whose title contains Google
-firefox.exe[-t:Google] – all windows, except Firefox windows whose title does NOT contain Google (in other words: Firefox windows with Google in the title still match)
Window rules can contain multiple independent conditions separated by commas:
c:XamlExplorerHostIslandWindow, firefox.exe[-t:Google|Yahoo], t:^Total Commander
-explorer.exe[t:File Explorer$], -browsers[-firefox.exe, -chrome.exe], -games
Do not mix inversion on the same level.
Either all conditions are normal, or all are inverted, within a single level.
You can define reusable groups in the settings and use them inside window rules.
Example:
browsers = firefox.exe, chrome.exe, msedge.exe, opera.exe, vivaldi.exe
Then a window rule can simply be:
browsers
or:
-browsers
Groups can also be refined:
browsers[t:Cadans]
Meaning:
browser windows whose title contains Cadans
For browsers, this usually means the active tab title contains Cadans.
This is equivalent to:
firefox.exe[t:Cadans], chrome.exe[t:Cadans], …
Inverted refinements also work:
browsers[-t:i)Google]
Meaning:
browser windows whose title does NOT contain Google
Groups use the same syntax as ordinary rules and may themselves contain refinements:
browsers = firefox.exe[-t:Google], chrome.exe[-t:Yahoo], …
Use caution when refining groups that already contain refinements.
You can also use refinements to exclude items from a group:
browsers[-firefox.exe]
Treated directly as browsers without firefox:
chrome.exe, msedge.exe, opera.exe, vivaldi.exe
Assignment rules use the same syntax as layer rules:
browsers[t:Cadans]
c:XamlExplorerHostIslandWindow
-games
By default, assignment rules narrow the layer scope.
Example:
layer_rule = browsers
assignment_rule = t:Cadans
The assignment is available only in browser windows whose title contains Cadans.
To make an assignment ignore the layer rule, start its rule with !:
layer_rule = browsers
assignment_rule = !explorer.exe
The assignment is available in Explorer even though the layer itself is scoped to browsers.
Leave a layer rule empty to keep the layer active everywhere.
Leave an assignment rule empty to make the assignment follow only its layer rule.
In the context dropdown, Cadans may compress matching process sets back into their group names when possible.
For example, all browser processes in the one context will be displayed just as browsers.
Refinements like browsers[-t:Google] are preserved.
Hold Alt over the selected context to see the fully expanded form.
Contexts with identical runtime behavior are merged into a single displayed context.
Conversely, a single layer or assignment rule may split into multiple visible contexts depending on how other active rules interact with it.
Example:
layer1_rule = browsers
layer2_rule = browsers, games
Displayed contexts:
browsers (layer1 & layer2)
games (layer2)
With Alt you can see which layer and assignment rules formed the current context.
Window contexts are based on the currently active foreground window.
Cadans tracks foreground changes, title changes, and some additional window events to handle special Windows UI transitions such as Task View, Explorer panels, and the taskbar.
Some Windows shell elements are not ordinary application windows, so their process/class/title values may look unusual.