macOS: Activate NSApp and put the windows on top

[karelbilek]

Currently, macOS dialogs don't really work correctly, because the NSApp is not properly activated and, in case of dialogs, is not put on top.

This commit fixes that. Also, I deleted the comment in example, as it's no longer true with these changes.

[sqweek]

Hmm... Note that dialog's primary use case is to run alongside an existing GUI app and provide access to native dialogs. example/simple is not representative of this, as the comment hints at.

Changing the underlying library like this to get example/simple to work concerns me because:

1. dialog is a library not an application; it doesn't really have any business twiddling application level knobs
2. I'm not a fan of forcing dialogs to the top because I don't want to interfere with the system/end-user's focus policy

It's also been awhile since I touched cocoa and I don't have a good test environment these days. Reading through this stackoverflow answer I think there is a reasonable argument that spawning a dialog qualifies as an exception where it is ok to call [NSApp activateIgnoringOtherApps:YES], but unless there is a demonstrable issue when used alongside a GUI I don't really want to risk changing behaviour.

[karelbilek]

can I at least put it as an option? :)

On Sun 18. 2. 2024 at 11:17, sqweek @.***> wrote:

Hmm... Note that dialog's primary use case is to run alongside an existing GUI app and provide access to native dialogs. example/simple is not representative of this, as the comment hints at.

Changing the underlying library like this to get example/simple to work concerns me because:

1. dialog is a library not an application; it doesn't really have any business twiddling application level knobs
2. I'm not a fan of forcing dialogs to the top because I don't want to interfere with the system/end-user's focus policy

It's also been awhile since I touched cocoa and I don't have a good test environment these days. Reading through this stackoverflow answer https://stackoverflow.com/questions/25318524/what-exactly-should-i-pass-to-nsapp-activateignoringotherapps-to-get-my-appl I think there is a reasonable argument that spawning a dialog qualifies as an exception where it is ok to call [NSApp activateIgnoringOtherApps:YES], but unless there is a demonstrable issue when used alongside a GUI I don't really want to risk changing behaviour.

— Reply to this email directly, view it on GitHub https://github.com/sqweek/dialog/pull/81#issuecomment-1951084524, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAZT4NKP5J5CPWYFKYHMLLYUHIM7AVCNFSM6AAAAABDNOFBVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJRGA4DINJSGQ . You are receiving this because you authored the thread.Message ID: @.***>

[karelbilek]

one of the ways I Have been using dialog for is semi-terminal app... basically some quick and dirty terminal app that still can make some simple gui

I think this still would be useful.

On Sun 18. 2. 2024 at 12:03, Karel Bílek @.***> wrote:

can I at least put it as an option? :)

On Sun 18. 2. 2024 at 11:17, sqweek @.***> wrote:

Hmm... Note that dialog's primary use case is to run alongside an existing GUI app and provide access to native dialogs. example/simple is not representative of this, as the comment hints at.

Changing the underlying library like this to get example/simple to work concerns me because:

1. dialog is a library not an application; it doesn't really have any business twiddling application level knobs
2. I'm not a fan of forcing dialogs to the top because I don't want to interfere with the system/end-user's focus policy

It's also been awhile since I touched cocoa and I don't have a good test environment these days. Reading through this stackoverflow answer https://stackoverflow.com/questions/25318524/what-exactly-should-i-pass-to-nsapp-activateignoringotherapps-to-get-my-appl I think there is a reasonable argument that spawning a dialog qualifies as an exception where it is ok to call [NSApp activateIgnoringOtherApps:YES], but unless there is a demonstrable issue when used alongside a GUI I don't really want to risk changing behaviour.

— Reply to this email directly, view it on GitHub https://github.com/sqweek/dialog/pull/81#issuecomment-1951084524, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAZT4NKP5J5CPWYFKYHMLLYUHIM7AVCNFSM6AAAAABDNOFBVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJRGA4DINJSGQ . You are receiving this because you authored the thread.Message ID: @.***>

[sqweek]

I'm not outright opposed to a "put me on top of everything else" option -- see #7 for previous discussion. Your code might provide the final piece to that puzzle; as I mentioned there I didn't think it was possible on OSX.

edit: and if this enables the command-line use case then all the better

[karelbilek]

Hah, thanks for the tip; setting it as ...Accessory (conditionally?) actually fixes the issues easier than making it a separate app, and it doesn't need any OnTop options.

[karelbilek]

See now

[sqweek]

Thanks very much! I squashed and landed with two very minor modifications:

• setActivationPolicy() renamed to checkActivationPolicy() to better reflect its conditional behaviour
• updated README.md to track the minimum required macOS version (10.6+ for NSApplicationActivationPolicyAccessory)