[osx, parallax+, wx3] App starts with its window hidden and window size reset

[noenedrops]

I'm not sure if this was reported before (I haven't found anything similar in issues), but since 1.6.0 the app started to launch like this: https://www.youtube.com/watch?v=Qgnj1OYM6HU — watch how the top menu changes from sole "pyfa" to the whole set of menu items, but still no window appears.

• 'show all windows' in the app's dock menu doesn't bring the app window on
• app window only appears if I click on the app icon in dock
• if I don't open pyfa's window that way, when I Cmd+Tab to it, app window doesn't appear and app's main menu doesn't appear either
• the app doesn't preserve window size that was set earlier.

[thorr18]

I have the same issue and use the same work-around.
Like you, I basically have to open Pyfa twice. Issue is with 1.16.x -mac-wx3 , but not 1.15.x

[blitzmann]

I noticed the same this with my testing, but never got around to looking at it. It must be a wxpython 3 thing, I'll search around and see if I can find any solutions

Also, didn't notice the window size being reset. I'll have to test.

[blitzmann]

I cannot reproduce the window size being reset. The size is whatever I set it to last run.

Please note that for settings to be saved pyfa must be closed properly. Killing the process or otherwise ending the program abruptly won't save it. Perhaps this is what is happening with you?

[blitzmann]

Also, must actually be a os x skeleton thing, and starting pyfa from pycharm pops the app up without issue. =/

[thorr18]

In my testing, the window resize is preserved each time, unless I maximize the window before exiting. In that case the window size is lost.
Window position is lost, even when window size is preserved.

[thorr18]

Executing Pyfa without the launcher:

When I run the app directly from deeper within the package, I do not have the hidden window issue:
Bs-MBP:Dlbuilds bem$ ./pyfa1162.app/Contents/MacOS/pyfa
Pyfa window showed up, though it did still exhibit the other OSX issues I checked for.

Using open command:

When I use the open command, behavior is same as the launcher shown in the video, I have to run it a second time to bring the window into visible. The fit calculations are already complete as soon as I run it the second time so it doesn't actually run the program from start again. It just finds that it is already running hidden and brings the window up.
Running package, as if using launcher:
Bs-MBP:Dlbuilds bem$ open ./pyfa1162.app
Can't find a way to get window visible, so running open a second time:
Bs-MBP:Dlbuilds bem$ open ./pyfa1162.app
Now can use Pyfa.

My testing of the issues in this thread using OSX 10.11.x

*Hidden window issue: 1.16.x only (but it's OK when executing pyfa directly without 'launcher' or 'open')
*Losing window position: occurs using both 1.15 & 1.16
*Losing window size: No loss occurs. Size is preserved.
*Losing size & position after maximizing: occurs using either 1.15 or 1.16 (the non-maximized size is lost, the position is lost, and the maximized state is not preserved).

[thorr18]

I just tested with the non-wx3 version. The hidden window issue does not occur. This is a wx3 issue only.

[blitzmann]

http://stackoverflow.com/questions/12992316/tkinter-py2app-created-application-doesnt-show-window-on-initial-launch

Building the build with argv_emulation = False seems to work to bring the program to the front with a bit more tweaking. After setting this, I was getting errors about not handling a -p option. I added this dummy option to pyfa.py and printed it out to see exactly what it was and it returned this: sn_0_532610, which seems to change on every run (I also got sn_0_540804 for example)

Very strange, and I'm not at all sure why this is. But, the important thing is that the "starting hidden" bug is solved and I can just ignore this -p argument. I'll try to find some more concrete answers on why this happens (not sure if OSX is adding the -p option, or if it's py2app, or what).

Will keep this open until it's actually fixed in the repo.

Again, not sure about the window position as I've never really experienced the position saving for me, but maybe this fixes that as well.

[blitzmann]

Quick update:

seems it's not really a -p argument, rather the OSX launcher tacks on something like -psn_0_540804. It seems that OSX does this when opening applications, and it's supposed to handle file drops or some such. I am not sure why it's never been a problem before (probably because argv_emulation took care of it somehow)

[blitzmann]

I'm going to close this as the new binaries seem to have fixed this as far as I can tell. If issue persists after the next release, please reopen.