Wx Menubars and other issues for mac releases

Scripting Issues
1

Using panda 1.8.1 with yesterday’s daily build of the runtime (which btw, is not linked on the site: http://www.panda3d.org/download.php?platform=osx&version=devel&runtime)

I’m having some very odd issues with my mac release for one of my panda projects. It makes heavy use of wx.

I can work around the nasty wx linking error by installing “wxPython2.8-osx-unicode-2.8.12.1-universal-py2.7” onto the target machine. Even if the install “failed” it fixes the issue (I think it installes the .so, then failed because there is no python2.7, but we only needs the .so files. Maybe this is a hint for how to fix panda’s wx package?)

So I now have a .p3d, .app, and .pkg which all work the same.

These all just get one entry in the menu bar, with just the default stuff and Quit. For the p3d, the Menu is name “Panda3D” and for my ppackaged app, it has the application name (the one passed to ppackage with -n, not the nice display_name I set in the pdef, which is use for the .app and .pkg names).

So I only get the menu for my application, none of my custom menus, and the application menu has the wrong name (should be the display_name from the pdef).

Also, if I click on my application’s icon in the doc when its running to being it to the front, it does not being it to the front, and even removes it from being the focused window if it had the focus. Using “Command-Tab” (like windows alt-tab) to select it also does not being any of its windows to the front. This even is true for modal dialogs!

I’m using OpenGLPandaWindow from WxPandaWindow.py inside a wx window for my panda windows, and wx for the menubar, dialogs etc.

Also, the .app build’s output from my running application shows up in the system.log in the console, but not in panda3d’s log directory like I’m used to.

None of these issues occur on Windows (everything is fine there).

2

I made a trivial test (Just import direct.directbase.DirectStart; run()) and it still has the focus problems. Thus, that issue, while it effects all the windows from wx, is not specific to wx windows.

On mac, if you run a p3d (or a build .app), and click on panda in the doc, you app loses focus. Command-Tab to focus it also does not work. Clicking on it in the dock and holding reviles all of an applications windows, which is none for panda apps.

On Mac, the runtime does not correctly associate application windows with the application. This may have to do with panda running the application in a sub-process, I’m not sure.

This is very bad, very breaking, and horribly aggravating to a user. If I, for example, open up a web browser infront of my panda app to report this bug, to get my app back in front, I have to hide my browser, I can’t being my app to the front.

My effort to test with the non-daily build of the runtime failed due to the certificate issues.

My issues of not being able to control the content of the menu-bar in p3d and .app builds with wx might be related to this.

3

Perhaps the issue is that there are really two applications in play at the same time, Panda’s and wx’s, and that one of them is getting priority over another? Also, is your build of wxPython a Carbon or a Cocoa build?

4

I think the lack of menu bar might be related to the fact than none of the application windows belong to the application (bringing panda to the front removes the focus from the panda windows), and this even happens WITHOUT wx. The issues with the wx menubar is what got me here, but since my menu bar is associated with my windows, and something is clearly broken with the windows (both panda, and wx windows, even with just the default panda window), I think it makes more sense to ignore wx when debugging this for now. It might be 2 separate issues, but the issue effecting all panda apps on mac seems more serious that an issue with wx menubars.

As for the version of wxPython, I am using the provided wxPython package, combined with an install of “wxPython2.8-osx-unicode-2.8.12.1-universal-py2.7” on Snow Leopard. Since they didn’t have an option for Cocoa vs Carbon when I got it, I’ll assume its Carbon, but it dons’t say anywhere in the installer.

One thing I noticed: my keyboard shortcuts still work, but the menus don’t show.

5

Another thing that my be of interest:

When I run my trivial .p3d (just import direct start and run()) by double-clicking on it, closing the panda window does not quite the runtime. If I run the same p3d from the terminal, or the python source from the terminal, closing the panda window quits the application.

Shall I just start filing bugs for all these things? I think they might be related, but we have a total of 4 distinct runtime bugs here so far on mac:

  • Panda runtime on mac does not give the focus to its windows (panda and/or wx windows) when clicked in the doc, or selected via Command-Tab. (I tried runtime 1.0.4, as well as my recent daily build, both failed. 1.0.0 won’t install over a newer version, so I couldn’t test it)
  • When the runtime is not the active application, and you click on a panda window, what ever application was in front continues to show its menubar (ex: I can have the menubar indicating Finder is in-front, while I have a window from the panda runtime focused)
  • Wx menubars do not work with the runtime.
  • When not launched from the terminal, the runtime does not quit when closing the default panda window. (Edit: Also, Command-Q just closes the window. You need to do Command-Q twice to quit.)

I should note that the “Installing Panda…” window of the runtime works correctly. If its just that window, Command-Tab works, etc. None of the above bugs apply until the download is done. Once done, even if the runtime is no longer in-front, the new panda window is shown on-top of all other windows and given the focus, but the menubar does not switch to the menubar for the runtime (ex: I currently have the panda window in-front and selected, and the menubar for Finder is up, suggesting this window belongs to Finder, but I can make it appear to belong to any application)

6

Can you reproduce any of these issues with the SDK? I’m not entirely sure if these issues will still be relevant when we start building for Cocoa for 1.9.0.

7

The SDK is fine. No issues at all (well, none of these issues).

Edit: These issues occur with every p3d, and every pdeployed application (standalone, and installed). From what I can tell, it happens in runtime 1.0.4, and the daily build I’ve been using, though I can only build new releases with the daily build due to certificate issues, I verified the bugs in an old p3d I made back in November with runtime 1.0.4.

Edit: I tested with one of my .p3d files from February 2010, and the issue is still there, so its not a panda 1.8 thing. I think this issue may have always been here, but I haven’t tried to do a serious release with mac support before, so I haven’t really looked into it/reported it. I’d like to repeat that the install progress window while downloading has none of these issues, so at least something it working right in that respect.

The daily SDK builds are on the 1.9.0 branch right? So if I try then, that should answer the question on if they are ok? (Edit: There arn’t any Mac daily builds of the SDK on the site, so I can’t test that)

Edit some more: I tried the astroids demo from this site (downloaded the .p3d, which btw has an expired certificate). It also has the issues. So its not just stuff I package.

8

Hmm, I can reproduce the issue with asteroids.p3d from the gallery. Clicking the app icon does not make the window come to the foreground.

I don’t really know how the plugin works on OS X. I do know that the plugin creates its own toplevel window hosting the loading screen, and that it then runs P3DPython.app as a subprocess, which embeds Python and hosts the actual game. Beyond that, the subprocess stuff comes into play, which is really David’s work.

The plugin hasn’t been ported to use the newer CoreAnimation API yet, though (it still uses QuickDraw), which will be a daunting task that I’m not exactly looking forward to. Doing so may help us with this issue as well, though. In any case, there’s no current way to use the plugin with the Cocoa renderer even if you did build the entire runtime distribution from source.

Addendum: Ah, I just stumbled over an old discussion with drwr that sheds a bit more light. Originally, p3dpython was a standalone executable which caused it to appear as a second dock item; drwr introduced P3DPython.app in order to prevent that second dock item from appearing, I believe, but this had the side-effect of the app no longer being associated with any dock icon at all.

So, this is simply an issue that has been here from the start and we’ve never found a solution for. I don’t know if it’s possible on OS X to group a separate application or executable under the same dock icon, however; this may not be possible.

But, I’m not convinced that we strictly need to run P3DPython.app as a separate process when running the standalone runtime; but that could just be my ignorance of the system talking. I’ll have to ask drwr about that.

9

Ok. I see the extra process.

Personally, I wouldn’t mind having 2 applications in the doc. Having a doc item that works, and one that does not seems better than just one that does not.

I’d love to have a fix, even if crude. I’ve seen commercial games that have a separate launcher application, its not too bad (though I’d prefer to avoid it for my non game project).

I noticed, at least when launched from the GUI, that a -psn_… (process serial number) argument is passed in, which is supposed to be used for this kind of thing I think.

Hopefully David can provide a fix. Thanks for looking into this!

10

Intriguing, but I don’t think that we can do anything with the PSN. It’s associated with the PID, which is going to be different for the subprocess.

The fundamental problem is that the subprocess creates its own NSApplication in its own address space. I do have an idea on how to solve this for the standalone runtime, which would be to load p3dpython as a library and use fork to duplicate the panda3d executable for any other sessions that need to be run, but I don’t know if that would work at all. Plus, this won’t work for the plugin.

The workaround in order to get two dock icons is to edit your pdeployed tree, find P3DPython.app, edit the plist file, and remove the LSUIElement entry.

If you’re feeling ambitious, you could try removing P3DPython.app entirely, which will make it fall back to loading libp3dpython.dylib, which may run in the same address space. EDIT: No, sorry, this won’t work - Panda only falls back to libp3dpython.dll on Windows. I was misled by the fact that we still ship it on Linux and Mac OS X.

Well, perhaps I’m thinking about this the wrong way. The problem that we’re trying to solve is that P3DPython.app doesn’t come to the foreground when you click the Panda3D dock icon, isn’t it? Then perhaps we should do exactly that - listen for the event that tells us when the Panda3D window has been focused, and then focus the P3DPython app instead, showing its menu and dock icon. Would that work for you?

11

We have lots of issues caused by this:

  • When clicking on the doc icon, the window is not brought to the front
  • When clicking and holding on the doc icon, the the set of windows for the application reviled is empty
  • When clicking on one of the application windows, the application is not brought to the front (thus leaving the old menu bar)
  • Command-Tab does not work to select
  • To quit, you have to quit the app, then the runtime (command-q twice)
  • And this might also be the cause of my menubar not showing (but its keyboard short cuts work)

I’m sure there are also other issues which vary based on the version of OSX you have, since different ones vary slightly about the tricks they have (for example, the click and hold on a doc icon to select a application window new in Snow Leopard, and its broken). I bet application specific expose is broken too, as well as interactions with spaces, maybe some of the screen shot stuff, apple events etc. A whole lot of stuff is broken by this, and patching one or 2 of them will just result in almost standard behavior on some versions of OSX, but it would never work right.

12

I fount the info.plist in P3DPython.app, and made the change. Now I have my Wx menus, focus stuff works, its all working! Everything is as it should be, other than the extra runtime application thats running.

Well, the application name shown in the menubar is P3DPython, not my application’s real name, but I can live with that for now.

This will be fine for my beta-testing phase. Thanks!

13

Well, as long as you’re modifying the plist file manually, you can change the name that appears in the menu from the same plist file, can’t you?