-
Notifications
You must be signed in to change notification settings - Fork 0
Profiles And Matching
Profiles define a workspace. Each app entry defines how one or more real Windows windows are identified, launched when allowed, and placed.
A profile contains:
- name and optional description
- optional profile target monitor
- ordered app entries
An app entry can override the profile monitor. This supports profiles that span multiple displays.
Dashboard capture snapshots visible, non-minimized top-level windows on the selected monitor. It excludes WindowAutoLayout and saves enough identity and display data for a ready-to-restore profile.
Capture replaces the profile's current app list. Review the result before saving over a carefully hand-tuned profile.
Signals include:
| Signal | Example |
|---|---|
| Process name |
obs64.exe, vesktop.exe, brave.exe
|
| Executable path | Exact Win32 path when Windows exposes it |
| Launch PID | Process created by the current explicit restore |
| Title rule | Contains, exact, starts with, ends with, or regex |
| Class name | Stable Win32 window class for advanced filtering |
| Visibility/state | Visible, minimized, or hidden/tray rules |
For most desktop apps, process name plus a captured layout is the best starting point.
Use title rules when one process owns several meaningful windows. Keep them broad enough to survive changing tabs, documents, scenes, and status text.
Regular expressions are validated before config save/import. An invalid expression appears in config validation instead of failing silently during restore.
| Setting | Behavior |
|---|---|
| Restore if minimized | Restores a matching minimized frame before placement |
| Pull hidden/tray windows | Allows hidden matching windows to be recovered |
| Wake running tray apps | Asks a running process to expose its main surface |
| Allow empty title | Permits intentionally untitled windows |
These settings do not launch a new process by themselves.
Explicit and startup restore may launch a missing app when the global Launch apps that are closed option is enabled. Discovery can use:
- configured executable path
- configured arguments and working directory
- package/Store identity
- Windows App Paths
- Start Menu shortcuts
- common installation folders
PATH
WindowAutoLayout waits through small updater/splash windows for the real surface. Launch detection is bounded by the entry timeout.
Automatic event restores never launch a closed app.
Current profiles store a hardware-backed Windows monitor interface identity plus a friendly model name. This survives ordinary DISPLAY1/DISPLAY2 renumbering better than a display index.
Legacy display-number targets are migrated conservatively. If a saved physical layout cannot fit its old numbered display but cleanly fits another connected monitor, migration can repair the target; an explicit stable hardware identity is trusted.
Layouts are stored as physical monitor-relative pixels together with captured:
- full display width and height
- work-area origin, width, and height
- scale percentage
If the same display geometry remains connected, saved coordinates remain exact. If resolution or work area changes, WindowAutoLayout maps the rectangle into the current display/work area and clamps unsafe off-screen bounds.
After a move, final DWM frame bounds are sampled at bounded intervals. Two stable matching reads within one pixel finish the restore. Persistent drift is reported with expected and actual bounds.
Windows can block a normal process from controlling an elevated app. Run the target app without administrator rights when possible, or run WindowAutoLayout at the same integrity level for that session.
WindowAutoLayout documentation. Repository: https://github.com/Riqqqque/WindowAutoLayout