Window inactive and not put to front on app startup on macOS in some situations

[Andreas Falkenhahn]

I'm having a strange issue with wxWidgets 3.1.4 on macOS which wasn't there in 3.1.0. When I start the minimal sample (or any other wxWidgets app) like below, the app's window is neither put to the front and nor does it get activated. It's opened in the background and it is inactive instead. This is the line:

$ ./minimal.app/Contents/MacOS/minimal

When I start it using Finder or using "open" from bash, however, it works correctly, e.g. this works correctly:

$ open minimal.app

However, using wxWidgets 3.1.0 the first method is working correctly as well so it looks like the cause is in wxWidgets, not in macOS. Does anybody have an idea what change between wxWidgets 3.1.0 and 3.1.4 could have triggered this change in behaviour? I'd really like to have the old behaviour back so I'm wondering if anybody knows what is responsible for this change in behaviour...

--
Best regards,
Andreas Falkenhahn mailto:and...@falkenhahn.com

[Igor Korot]

Hi,

On Mon, Mar 15, 2021 at 1:41 PM Andreas Falkenhahn
<and...@falkenhahn.com> wrote:
>
> I'm having a strange issue with wxWidgets 3.1.4 on macOS which wasn't there in 3.1.0. When I start the minimal sample (or any other wxWidgets app) like below, the app's window is neither put to the front and nor does it get activated. It's opened in the background and it is inactive instead. This is the line:
>
> $ ./minimal.app/Contents/MacOS/minimal

You really, really, really shouldn't do that.

The native OSX behavior is to use Application Bundle and so running it
like this doesn't guarantee\
that everything will work correctly.

In particular the menus will not be active and some other tools might not work.

>
> When I start it using Finder or using "open" from bash, however, it works correctly, e.g. this works correctly:
>
> $ open minimal.app
>
> However, using wxWidgets 3.1.0 the first method is working correctly as well so it looks like the cause is in wxWidgets, not in macOS. Does anybody have an idea what change between wxWidgets 3.1.0 and 3.1.4 could have triggered this change in behaviour? I'd really like to have the old behaviour back so I'm wondering if anybody knows what is responsible for this change in behaviour...

From what I heard, OSX will prohibit using *nix-style application run
in the near future.

Thank you.

>
> --
> Best regards,
> Andreas Falkenhahn mailto:and...@falkenhahn.com
>

> --
> Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
>
> To unsubscribe, send email to wx-users+u...@googlegroups.com
> or visit http://groups.google.com/group/wx-users
> ---
> You received this message because you are subscribed to the Google Groups "wx-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wx-users+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/1421360441.20210315194204%40falkenhahn.com.

[Andreas Falkenhahn]

Hi Igor,

On 15.03.2021 at 19:46 Igor Korot wrote:

> You really, really, really shouldn't do that.

I know. But I'd still like to know what is responsible in wxWidgets for this change in behaviour. It was working correctly in 3.1.0, after all...

>From what I heard, OSX will prohibit using *nix-style application run
>in the near future.

Hopefully not. I need to capture the program's stdout so I'm using popen()
to run it which of course requires me to start the app Unix-style.

[Lauri Nurmi]

Andreas Falkenhahn kirjoitti 15.3.2021 klo 20:42:
> I'm having a strange issue with wxWidgets 3.1.4 on macOS which wasn't there in 3.1.0. When I start the minimal sample (or any other wxWidgets app) like below, the app's window is neither put to the front and nor does it get activated.

There's https://github.com/wxWidgets/wxWidgets/pull/2216 -- already in
git master -- which sounds a lot like a solution to what you are describing.

[Gunter Königsmann]

maxima popens gnuplot which comes as an appbundle.I never had any complaints that this doesn't work...

-- 
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to wx-users+u...@googlegroups.com
or visit http://groups.google.com/group/wx-users

You received this message because you are subscribed to the Google Groups "wx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-users+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/210268a7-61de-a096-0a3b-577db44339ee%40iki.fi.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Andreas Falkenhahn]

On 15.03.2021 at 20:15 Lauri Nurmi wrote:

> There's https://github.com/wxWidgets/wxWidgets/pull/2216 -- already in
> git master -- which sounds a lot like a solution to what you are describing.

Thanks, adding

[NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
[NSApp activateIgnoringOtherApps: YES];

indeed solves the problem.

However, those lines are only executed for non-bundled apps. In my case it's different: My app is bundled but the executable inside the bundle is started directly, e.g. like this:

$ ./minimal.app/Contents/MacOS/minimal

In that case, the two lines quoted above aren't executed because the executable is inside a bundle.

So is it really true that always running those two lines causes issues? AFAICS Tk always executes them so maybe wxWidgets should do that too because, as I said, in my case the fix from #2216 is useless because it is only called for non-bundled apps, but not when running executables inside bundles directly...