Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#15613 closed defect (fixed)

non-bundled apps no longer work on Mac since 3.0.0-RC1

Reported by: mojca Owned by: csomor
Priority: low Milestone:
Component: wxOSX Version: 3.0.0-rc1
Keywords: Cc: jinxiaoyong@…
Blocked By: Blocking:
Patch: no


Simple non-bundled applications no longer work (using this trick):

We got a report on MacPorts about a crash in Mavericks (see, but Lion fails to show the GUI as well.

The attached minimal example runs fine when compiled against 2.9.5, but fails to start with version 3.0.0-RC1. (In MacPorts I actually backported a few commits from SVN, but I believe that also the original version has the same problem.)

Attachments (1)

hw_wx.cpp download (1.2 KB) - added by mojca 4 years ago.

Download all attachments as: .zip

Change History (15)

Changed 4 years ago by mojca

comment:1 Changed 4 years ago by vadz

  • Milestone 3.0 deleted
  • Priority changed from normal to low

Non bundled apps were never guaranteed to work, this is just how things need to be under OS X. If somebody can make this hack work, all the better, of course, but we don't have any plans to support this.

comment:2 follow-up: Changed 4 years ago by dgud

I had the same issue in erlang port of wxWidgets but I don't believe it's wxWidgets problem.
I fixed it by moving the "hack"/"trick" to before invoking wxWidgets loop instead of in my case in wxApp:OnInit(). That solved the issue.

comment:3 in reply to: ↑ 2 Changed 4 years ago by mojca

Replying to dgud:

I had the same issue in erlang port of wxWidgets but I don't believe it's wxWidgets problem.
I fixed it by moving the "hack"/"trick" to before invoking wxWidgets loop instead of in my case in wxApp:OnInit(). That solved the issue.

Whose fault it is depends on definition then. If it worked in 2.9.5 and stopped working in 3.0.0-rc1, and if the way it has been done in past is now deprecated (and should be replaced by another approach), this should be clearly stated and there should be unambiguous instructions about how this should be used.

However about moving the hack elsewhere for testing: I see there is


in gnuplot source. Should the hack be moved from the beginning of wxtApp::OnInit() to just before CallOnInit() or somewhere else?

comment:4 Changed 4 years ago by mojca

I just want to mention that the code for handling PSN in command-line applications has changed a tiny bit recently (see #15432). The code that removes -psn_ has been moved to another function, so that it also removes the extra argument from gtk applications on Mac. Maybe this removal of -psn_ now happens too soon and

ProcessSerialNumber PSN;
TransformProcessType(&PSN, kProcessTransformToForegroundApplication);

isn't able to determine the PSN number any longer. Honestly the GTK applications never worked properly even after this patch (they keep bouncing in the dock, even though they work ok), but the patch allowed them to start in the first place.

comment:5 Changed 4 years ago by mojca

r74609 still works fine, r74610 and r74611 don't compile, r74612 seems to be problematic based on some testing on Lion. I don't know what influence this has on Mavericks and maybe some other later commits contribute to problems as well.

I tested by running the latest gnuplot with wxt terminal. With r74612 it still works, but I need to manually click on the icon in the dock first.

I can do some further search with bisection to figure out what the later commits do, but it might make sense to figure out whit these three commits do first.

comment:6 Changed 4 years ago by csomor

  • Owner set to csomor
  • Status changed from new to accepted

comment:7 Changed 4 years ago by csomor

I dont' want to run TransformProcessType by default. If people cannot package things into a bundle - for which I can perfectly understand the reasons when coming from command line utilities - then they will have to change a few lines in their sources.

Since according to different sources it may be necessary to call things at different places during app construction depending on the OSX version I cannot provide just a wrapper, I'll have to add a property method

virtual bool         MacNeedsTransformToForegroundApplication()

to wxApp defaulting to false, so a non-bundled app would override this returning true, then I can act accordingly.

comment:8 Changed 4 years ago by vadz

Other than calling this OSXIsGUIApplication() ("OSX" because we agreed to use this prefix for wxOSX-specific methods some time ago, "GUI" and without "Transform" because this should be much more clear for non-Mac people) I'm perfectly fine with this solution.

But this needs to be done before 3.0 as adding a virtual function later wouldn't be ABI-compatible.

comment:9 Changed 4 years ago by csomor

Yes I'll do that now,

actually OSX was meant for all - including iphone - OSX variants, that's why I stuck with Mac, but I can change this, the trouble is that this fix is only needed for non-bundled apps, so IsGUI is misleading …I'll check whether I can reliably find out, whether the main app is in a bundle, then this wouldn't matter probably, don't know about living in python world though ...

comment:10 Changed 4 years ago by mojca

You may ignore this, but just as an idea while dealing with this: what about adding two additional functions (in addition to this boolean) to bring the apps to foreground and background later on? I'm not saying that I need this function right now, but it might be easier to add a function with a consistent name and functionality now rather than later.

For example, due to some problems with Qt, gnuplot had to add the following code some time ago (unrelated to wxWidgets and there must have been some bug somewhere, otherwise this code shouldn't be necessary in the first place):

void removeDockIcon() 
			// Don't display this application in the MAC OS X dock 
			// kProcessTransformToBackgroundApplication only works on Mac OS X 10.7 and later 
			ProcessSerialNumber psn; 
			if (GetCurrentProcess(&psn) == noErr) 
				TransformProcessType(&psn, kProcessTransformToBackgroundApplication); 

If you already play with hiding/unhiding the app, it might make sense to add two functions to bring the app to front or back later on request.

See the following for example: where there are two functions available, hide and unhide.

Apart from that - thank you very much for looking into this. (I would still prefer to see the foreground setting to be the default one, so that those rare background-only GUI applications could change the default, but as long as one will be able to change an app to the foreground, that would still be satisfactory and also a lot better than the approach in 2.8/2.9.)

comment:11 Changed 4 years ago by csomor

thanks we could add the methods later, but the problem for setting the app into the foreground under 3.0 can only be solved by using a flag, doing things in OnInit is already too late - I've got things working now correctly under 10.8,

looking at how to do the non-bundled app discovery now, then I could implement Vadim's API - and this would mean not having to change anything in your code

comment:12 Changed 4 years ago by csomor

btw. I think you should call the base OnInit as the samples do, just to be safe ...

  if ( !wxApp::OnInit() )
     return false;

comment:13 Changed 4 years ago by SC

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [75142]) fixes #15613

comment:14 Changed 4 years ago by SC

(In [75143]) preparing fix for non-bundled osx apps, see #15613 with fix on trunk

Note: See TracTickets for help on using tickets.