macOS: Activate NSApp and put the windows on top #81
Conversation
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.
|
Hmm... Note that dialog's primary use case is to run alongside an existing GUI app and provide access to native dialogs. Changing the underlying library like this to get
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 |
|
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
<#81 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAZT4NKP5J5CPWYFKYHMLLYUHIM7AVCNFSM6AAAAABDNOFBVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJRGA4DINJSGQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
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
> <#81 (comment)>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAAZT4NKP5J5CPWYFKYHMLLYUHIM7AVCNFSM6AAAAABDNOFBVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJRGA4DINJSGQ>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
|
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 |
cocoa/dlg.m
Outdated
| @@ -52,6 +52,11 @@ - (DlgResult)run { | |||
| [alert addButtonWithTitle:@"OK"]; | |||
| break; | |||
| } | |||
| [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular]; | |||
There was a problem hiding this comment.
Judging by the docs, the type of command-line usage you are talking about should probably use NSApplicationActivationPolicyAccessory?
This is the kind of application-level decision that I don't think dialog really has any business fiddling with, however I would be ok with this being done conditionally -- ie. if [NSApp activationPolicy] is NSApplicationActivationPolicyProhibited then it's reasonable for dialog to change it in the interest of ease-of-use, but if it is already set to another value then we shouldn't touch it.
|
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
force-pushed
the
fix_macos_nsapp_activation
branch
from
75f530b to
a2449a9
Compare
|
See now |
|
Thanks very much! I squashed and landed with two very minor modifications:
|
Currently, macOS dialogs don't work from the command-line, because the NSApp activation policy defaults to "Prohibited" in that context. This commit fixes that by setting the "Accessory" activation policy before opening a dialog, if (and only if) we are in the Prohibited state. Closes sqweek#81. Fixes sqweek#15.
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.