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

osx: dialogs very inconsistent when used without other Cocoa calls #15

Closed
nakshay opened this issue May 27, 2018 · 8 comments · Fixed by lucidoc/dialog#1
Closed

osx: dialogs very inconsistent when used without other Cocoa calls #15

nakshay opened this issue May 27, 2018 · 8 comments · Fixed by lucidoc/dialog#1
Labels
osx specific to the OSX implementation

Comments

@nakshay
Copy link

nakshay commented May 27, 2018

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.

@sqweek
Copy link
Owner

sqweek commented May 29, 2018

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?

@nakshay
Copy link
Author

nakshay commented May 29, 2018

@sqweek , Yes I am using "github.com/0xAX/notificator" for showing notifications.

@sqweek
Copy link
Owner

sqweek commented May 29, 2018

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.

@nakshay
Copy link
Author

nakshay commented May 29, 2018

Thanks @sqweek , I will try to dig more.

@nakshay nakshay closed this as completed May 29, 2018
@sqweek
Copy link
Owner

sqweek commented Jun 11, 2018

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.

@sqweek sqweek reopened this Jun 11, 2018
@sqweek sqweek changed the title YesNo dialog very inconsistent on MacOS osx: dialogs very inconsistent when used without other Cocoa calls Jun 11, 2018
@IAmJSD
Copy link

IAmJSD commented Apr 3, 2020

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

@jipson7
Copy link

jipson7 commented May 16, 2020

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.

@sqweek
Copy link
Owner

sqweek commented May 21, 2020

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.

@sqweek sqweek added the osx specific to the OSX implementation label Sep 11, 2020
@sqweek sqweek closed this as completed in 0651055 Feb 26, 2024
prosavage pushed a commit to lucidoc/dialog that referenced this issue Mar 20, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
osx specific to the OSX implementation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants