-
Notifications
You must be signed in to change notification settings - Fork 77
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
osx: dialogs very inconsistent when used without other Cocoa calls #15
Comments
Does your program have other GUI elements? I've noticed strange behaviours on OSX if dialog is the only thing interacting with Cocoa, like keystrokes going straight through the dialog. No real idea why; does that apply to your situation? |
@sqweek , Yes I am using "github.com/0xAX/notificator" for showing notifications. |
Ok. That invokes another process to display the notification though, so there's probably no other Cocoa activity within your app itself? As you've discovered dialog isn't reliable yet in this kind of standalone usage, sorry! Maybe there's some initialisation which needs to be called or something. You might be able to learn something from go.wde's OSX backend - I use it with dialog to good effect. But it's probably not a straightforward solution, and I don't have heaps of spare time to investigate at the moment. |
Thanks @sqweek , I will try to dig more. |
Did you find a fix for this? Otherwise I think it should stay open, though I'll edit the title a bit to reflect my current understanding. |
Hi everyone! I don't know if you're still having this issue, but it's an issue I was personally facing. I fixed it by simply adding the following line to the initialisation of NSApp. :) MagicCap/MagicCap@5b24a33 |
Could anyone provide more context to the previous or any solution? Its not clear to me how to implement Jakes solution. Im currently facing the same issue with a directory selector dialog on macos. You've suggested that it may work in the presence of other cocoa calls? Is there anyway to open a headless window or something in the background to give the call some more stability? Thanks for the great library otherwise. Been really easy to use on other platforms. |
Jake's modification is orthogonal to dialog itself -- it tweaks the cocoa initialisation. If you don't have any other cocoa code then it's not something you can apply. I never really intended for this to be used as a standalone library to spawn dialogs which is why it doesn't work great in that environment. It may be enough to import github.com/skelterjohn/go.wde/init -- this doesn't spawn a window but it does do some setup. |
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.
YesNo dialog very inconsistent on MacOS.
I am using the same API given in the description
dialog.Message("%s", "Do you want to exit?").Title("Are you sure?").YesNo()
sometimes dialog wouldn't be shown and sometimes dialog stays on screen even if a button is clicked.
The text was updated successfully, but these errors were encountered: