Current State and Future Updates

[exytral]

With the release of 2.1.0 — comprising the display engine rewrite, native COM audio rewrite, script execution, custom themes, CLI revamp, and more — Display Profile Manager has reached feature-complete maturity. Active development is on indefinite pause. However, bug fixes, compatibility updates, and well-considered feature requests and PRs are not at all out of the picture; and updates will still be developed when necessary.

Special thanks to:

• @zac15987 for creating and documenting the original Display Profile Manager project
  • @jarandal for adding screen rotation and initial HDR support in PR #8
• @jonathanasdf for adding initial clone display support in PR #14
  • @rvahilario for further iterating on clone display support and adding unit testing in PR #23
• @grandoth and @xtrilla for investigating and diagnosing the AudioSwitcher resource leak in #10

As well as everyone else that contributed by reporting issues and requesting features. Thank you.

---

Features that are presently ruled out from future work.

Automations

• Profile Triggers - automatically apply profiles based on set conditions and events
  • Conceptually simple but can quickly fall apart in practice. Triggers that fire on app launch, running process, display connect/disconnect, and other events are straightforward individually. The problem is deciding what happens when multiple conditions are satisfied at once—which one takes priority and what should the end result be according to (potentially non-obvious) user intent. When DPM fails to change a desktop layout or audio settings, the fault lies with the app because the user should be guarded from saving invalid configurations—if automations were added natively, logic errors would then also become DPM responsibility. It is less of a "cannot" and more of a "will not" be added. For users who want automation, the CLI was revamped to become perfectly suited for applying profiles in the background (with an external script or app)—it is up to the end user to see that vision through.
• Window Management — launch or move apps into specific positions, sizes, or virtual desktops
  • Out of scope for DPM. PowerToys Workspaces is purpose-built for this and generates a .lnk shortcut that DPM can execute as a profile script.

WPF Limitations

• Layout Editor - preview desktop layout on a virtual canvas, with intuitive drag-and-drop
  • WPF measures and arranges elements through a fixed tree of control templates. A real layout editor reflects and renders actual monitor coordinates and supports drag-and-drop repositioning. Marrying the two is unfortunately infeasible (and is more appropriate as a full rewrite as a web app 👀). For now, achieving desired layouts rely on creating the layout in Windows display settings, saving the configuration in DPM, and manually editing the .dpm file for any pixel-perfect adjustments.
• Rich Themes - custom blur, backgrounds, and per element overrides
  • The current theme system is a quick and lean color-replacement layer (Theme.xaml) over a shared control structure (Base.xaml). Advanced per-element customization (like what is possible in web apps and custom CSS) increases complication immensely, requiring a refactor for every single UI element to support style overrides.
• Translations - dynamic theme system, but for text elements
  • Text elements unfortunately suffer the same refactoring burden issue. Additionally, the current UI layout (buttons, spacing, etc) is static and was form-fitted to the size of English words.
• Per-script Toggles enable/disable scripts individually
  • The required fields exist in the data model. However, the current workflow for modifying profile settings (the script section in this case) is to select a profile, open the edit window, scroll to the section, make the desired changes, and saving the profile. Practically speaking, duplicating a profile and modifying the scripts section mostly fulfills the same desired outcome.

[exytral]

2.1.1 Update — Automations

• Profile Triggers — native automation triggers remain out of scope for the reasons above. That said, 2.1.1 ships DPM Shortcut Builder, a tool that helps automate switching profiles when launching a game or app. Rather than DPM actively monitoring running processes or system events, DPM Shortcut Builder creates a shortcut that switches to a chosen display profile before the target launches, then waits on the process handle and restores the previous (or another chosen) profile when it exits — no background polling, no persistent task. That said, launching two shortcuts simultaneously will cause both to attempt a restore on exit, with the last one winning. Avoiding or resolving those conflicts is still the user's responsibility, same as any external automation.