Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CODE][MAJOR] adjusting baseline heuristics for window management selection #750

Open
raggi opened this issue Apr 13, 2024 · 0 comments
Open
Labels

Comments

@raggi
Copy link
Sponsor Collaborator

raggi commented Apr 13, 2024

This is not a short term or simple change/project.

Today we have a very large list of application specializations that we distribute via a commonly used applications.yaml. Many of these application definitions are essentially there to re-adjust to baseline exclusion rules that we have, for example ignoring all layered windows by default.

I've been doing some research with Spy++ from Visual Studio, and with a tool I wrote that's similar but easier to inspect (spy++++ - not released/uploaded yet). It appears we could probably adjust our baseline rules some, and significantly reduce the amount of per-application configuration required.

As a baseline example I've been experimenting with a simple set of rules such as:

  • Ignore* iconic windows
  • Ignore cloaked windows
  • Ignore windows that are not IsVisible (visible all the way up to parent)
  • Ignore windows that are WS_EX_TOOLWINDOW, but not WS_CAPTION

This set of rules gets us really far: we don't get entangled with most of the system windows, we ignore most message windows, and so on.

These aren't perfect though, and so there's refinement to do to get the heuristics just right. These rules are similar to those used in similar products, most recently I've been looking at the rules that FancyZones uses in powertools, which are similar to this baseline set, but with a few extra behaviors - particularly things to avoid splash windows and some more system windows.

This is a very major change, it would essentially supersede a lot of the existing application rules that we have, and also probably change the dialect that we want.

The next step is probably to start to introduce this in a way that entirely avoids breaking existing behavior: plumb some flags in some way that enables us to turn this on/off at runtime/in configuration so that we can experiment with it and make sure that we have a very clear understanding of the changes/regressions.

Once we're confident that the heuristics are a good replacement, we'll need to decide on a way to roll it out. It might be something like adding a "v2" of the application rules, so that when you switch to "v2 mode" then the v1 rules stop applying, or at least gel in some way.

The ideal end goal is that we can eventually drop maintenance of a large application specialization list, cutting it down to a very small list of applications that we need to distribute any knowledge of, and that new novel applications more often work as expected immediately.

@raggi raggi added the wm label Apr 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant