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

18 views
Skip to first unread message

Andreas Falkenhahn

unread,
Mar 15, 2021, 2:41:03 PMMar 15
to wx-u...@googlegroups.com
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

unread,
Mar 15, 2021, 2:46:19 PMMar 15
to wx-u...@googlegroups.com
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

unread,
Mar 15, 2021, 2:56:38 PMMar 15
to Igor Korot
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

unread,
Mar 15, 2021, 3:15:56 PMMar 15
to wx-u...@googlegroups.com
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

unread,
Mar 16, 2021, 11:22:33 PMMar 16
to wx-u...@googlegroups.com, Lauri Nurmi
maxima popens gnuplot which comes as an appbundle.I never had any complaints that this doesn't work...

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.

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

Andreas Falkenhahn

unread,
Mar 18, 2021, 12:28:38 PMMar 18
to Lauri Nurmi
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...
Reply all
Reply to author
Forward
0 new messages