Differentiating 'focused window changes' events. How do I ignore pop-over windows?

[gaufde]

@Nige_S

@gaufde

Apparently windows in MacOS can have different accessibility roles (for example, window, dialog, etc.).

That was the reason for my comment about window properties earlier. But these will be unreliable across applications (so you're back to special-casing) and won't work for tabs.

Hmm, I don't think I understand why this would be unreliable? It seems to me like MacOS requires apps to put different accessibility roles on windows (I assume so screen readers can understand GUI changes). Why wouldn't it be safe to ignore everything except for windows that have a subrole:"AXStandardWindow"?

@Nige_S

@gaufde

Because the panel is smaller than the "main" window it is attached to, my cursor jumps to the panel if it isn't already positioned where the panel appears (which is unlikely).

Are you sure it isn't just jumping to the centre of the "main" window, which just happens to be where the panel is?

Yeah, in PyCharm one of the problematic windows it is this little one that appears as a drop down:

Keyboard maestro will trigger on that and move the mouse to the center of the drop down options.

@Nige_S

Windows that the OS differentiates for trigger purposes, windows detected via AppleScript and System Events, and windows reported by applications via KM's Window tokens are different. I think you can use that by treating %WindowFrame%1% as a proxy -- if it remains the same then the window hasn't changed, even if you've switched/added/removed tabs or popped the KM Actions pane.

There's a chance of false negatives if you switch between two windows that have the same, pixel-exact, position and size.

This seems to work for me in KM, Finder, Terminal, and Safari.

Ignore Popups? v2.kmmacros (4.5 KB)

Oh, I think I am understanding your suggestion better now. I might need to modify it some since my window tiling utility means that I am likely to have windows with identical frames.

Is this suggestion related to the fact that %WindowFrame%1% is often but not always equal to %WindowFrame%0%?

[Nr.5-need_input]

@gaufde

that %WindowFrame%1% is often but not always equal to %WindowFrame%0%?

There is no Token like %WindowFrame%0%. The Indexing is not zero based. It starts with 1 for the frontmost window and counts upwards from there.

Greetings from Germany

Tobias

[gaufde]

@Nr.5-need_input

There is no Token like %WindowFrame%0%. The Indexing is not zero based. It starts with 1 for the frontmost window and counts upwards from there.

Really? It works for me:

Image

Check window frame types.kmmacros (2.7 KB)

Result when opening the KM action panel:

___
WindowName1: Keyboard Maestro Editor — Ignore Popups? v3
WindowName0: New Action
FrontWindowName: New Action
WindowFrame1: 444,256,1684,1031
WindowFrame0: 601,338,450,913
FrontWindowFrame: 601,338,450,913
___

[griffman]

@gaufde

Hmm, I don't think I understand why this would be unreliable? It seems to me like MacOS requires apps to put different accessibility roles on windows

This may be one of the issues you run into: Non-standard windows, most likely to be found in Electron and Java apps, may not have the role information you need. It is not required in the sense that you can't have a window without it, just that some Accessibility-related things need that information to work properly. (At least that's my understanding of it.)

-rob.

[Nige_S]

@gaufde

Hmm, I don't think I understand why this would be unreliable? It seems to me like MacOS requires apps to put different accessibility roles on windows

I suspect that, unlike many other attributes, those are put in by the UI Frameworks rather than being "developer choice". But note that one of those values is AXUnknown -- who knows how many different window "types" that may crop up on! But you know the apps you're working with, it shouldn't take you long to check them and all their windows.

But even if it is reliable, you've still got the "Spoon Problem". When you close the KM Actions pane you trigger the macro, the front window will have the AXStandardWindow subrole, so the macro will run and the pointer reposition even though you didn't want it to.

@gaufde

Yeah, in PyCharm one of the problematic windows

Sounds PyCharm behaves differently to KM. Which implies you're dealing with different problematic windows, and you're back to special-casing. Easy enough to check though, just make a simple KM macro with a "Display Text: %WindowFrame%1%" action, run it with and without that pane showing, compare the results.

But isn't PyCharm a Java app? In which case, all bets on "sensible macOS behaviour" are off

@gaufde

Oh, I think I am understanding your suggestion better now. I might need to modify it some since my window tiling utility means that I am likely to have windows with identical frames.

You can add an app tag, as before. Then it will only be a problem when switching between identically positioned windows in the same app.

This isn't a life-critical macro where one false pointer move opens you to a million dollar law suit (I hope!). Often a simple, no consequence on failure, 99% reliable macro is better than one that works 100% of the time but needs rewriting any time one of a dozen apps gets updated...

@gaufde

Is this suggestion related to the fact that %WindowFrame%1% is often but not always equal to %WindowFrame%0%

No, I just tend to think in window indexes and there is no "0th index" so I forget about %WindowFrame%0%.

%FrontWindowFrame%, %WindowFrame%Front%, and %WindowFrame%0% are synonymous, referencing the frontmost window. The manual says that's "Usually the same as index 1" so I guess there are times when it isn't -- and I should probably make more of an effort to use Front or 0.

The point is that, in every app I tested, opening/closing a tab or pane didn't change the dimensions of what KM sees as "window 1".

[gaufde]

@Nr.5-need_input

May I ask you why you are referring to AppleScript and Objective-C API‘s ?!

I was researching those options because Hammerspoon was showing different behavior to KM. Apple's APIs seemed like the common element to research.

@griffman

This may be one of the issues you run into: Non-standard windows, most likely to be found in Electron and Java apps, may not have the role information you need. It is not required in the sense that you can't have a window without it, just that some Accessibility-related things need that information to work properly. (At least that's my understanding of it.)

-rob.

I see what you are saying! That makes sense, though at first glance it looks like AXStandardWindow was reasonably reliable.

@Nige_S

@gaufde

Yeah, in PyCharm one of the problematic windows

Sounds PyCharm behaves differently to KM. Which implies you're dealing with different problematic windows, and you're back to special-casing. Easy enough to check though, just make a simple KM macro with a "Display Text: %WindowFrame%1%" action, run it with and without that pane showing, compare the results.

I think that this is not an issue. The behavior seems very similar if not identical to opening and closing the KM action panel:

Without drop down open
-----
%WindowName%0%: PythonProject – test.py
%WindowName%1%: PythonProject – test.py
%WindowFrame%0%: 416,193,1728,1079
%WindowFrame%1%: 416,193,1728,1079

With drop down open
-----
%WindowName%0%: 
%WindowName%1%: PythonProject – test.py
%WindowFrame%0%: 1779,225,605,240
%WindowFrame%1%: 416,193,1728,1079

@Nige_S

Often a simple, no consequence on failure, 99% reliable macro is better than one that works 100% of the time but needs rewriting any time one of a dozen apps gets updated...

I completely agree! Ultimately, I think your solution in Ignore Popups? v2 is the best set of trade-offs that we have found so far. Adding the app name and window names will also help reduce edge cases.

Interestingly, it seems like using Front/index 0 instead of index 1 in your Ignore Popups? v2 does not work well at all. So, your observation that

@Nige_S

The point is that, in every app I tested, opening/closing a tab or pane didn't change the dimensions of what KM sees as "window 1".

seems quite reliable, but opening/closing a pane/popover seems to almost always change what KM sees as "window 0".

[Nige_S]

@gaufde

seems quite reliable, but opening/closing a pane/popover seems to almost always change what KM sees as "window 0"

<ObDisclaimer>
I am not a programmer -- this is observation and supposition, not deep knowledge of macOS's windowing system!
</ObDisclaimer>

The "frontmost window" of an app is the window that currently has focus -- it includes all window "types" and can include dialogs.

The "first window" of an app is the first "document" window in the z-stack -- think of it as the frontmost of only the windows listed in the apps "Window" menu.

These are often, but not always, the same. Generally you'll know current window state because it's set by whatever you did immediately prior to any test. Sometimes, usually in more generic macros, you won't and shouldn't assume "frontmost" and "first" are the same.

You can see the differences for yourself in KM. Have a macro that displays the "frontmost" window size, run it without and then with the Action pane showing. Then leave the pane up but select an action in your macro and run the macro again -- it'll report the size of the "main" KM window, even though the Action pane is still there, because you've focused the "main" window by selecting an action in it. Do the same but referencing the "first" window and you'll get the same size reported all the time.

[gaufde]

@Nige_S

The "frontmost window" of an app is the window that currently has focus -- it includes all window "types" and can include dialogs.

The "first window" of an app is the first "document" window in the z-stack -- think of it as the frontmost of only the windows listed in the apps "Window" menu.

This is basically the same conclusion I've come to as well!

In any case, I think that overall this discussion was very productive. Thank you everyone for the help!