primstar 0.9.16 and the Mac
I've been trying to switch over to Primstar for my sculptie work (I had been using Jass 1.41) because it solves an issue with baking cylinders that I ran into (see: http://forums.secondlife.com/showthread.php?t=345290)
Thankfully, the bake dialog works just enough for me, but the add a new sculptie dialog doesn't.
For some reason, input isn't fed properly into the dialog when the dialog window is marked "override redirect" in your Tk "ModalRoot" class.
If I change that ModalRoot class to use either no overrideredict, then the input works, and the shape menu works, etc. but unfortunately, this causes blender to crash and burn eventually if not immediately after the dialog is dismissed. A simple test example is this:
Insert this line in ModalRoot just before the call to self.overrideredirect(True) is called:
if platform != "darwin":
Then, run blender, and add a new sculpt mesh. The window will appear, all the controls will work, and you'll get a sculpt mesh added. The focus will be somewhere odd, so click on the desktop somewhere then click back on blender.
Blender will now crash trivially - just minimize the window. If it doesn't crash precisely there, then try to restore the window. *boom*
When I get more time, I'll take another crack at eliminating the crash...
I'm wondering why this style of GUI was done in the first place? Gaia's UI doesn't have these issues at all...
Thanks 
I've attached my *ugly*
I've attached my *ugly* workaround for primstar crashes on the Mac.
For some magical reason, having the blender script toss an exception when it's finished "resolves" the TK crashing issue so that blender stops crashing...
This is NOT a fix, but a workaround:
First, you get the nag from blender about the script error. Second, once you've done this once, blender will refuse to minimize from the option-click on the desktop, and it will refuse to un-minimize from the Dock (workaround: bring up expose and hit the blender window to bring it back - tested only in Snow Leopard).
What I've learned is this: using the TK quit/destroy/etc. methods doesn't fully remove the window from the underlying Mac specific code, which later on triggers a crash when you attempt to minimize the blender window, as the lower level code is trying to send an event, and TK is trying to find some information in it's hash tables, and then panic's because it's searching a dead hash table...
Leaving the window as overrideredirect solves that issue, but then they become unusable from the keyboard, and the popup menu will no longer function. Oy.
An alternative workaround would be to switch the gui to use a display of checkboxes like Gaia's Jass gui instead of the menu, and then it would "work" but still not be drivable from the keyboard. This solution would also port well...
Lose lose lose
Primstar "hacks" on Mac
Not many active Mac users around, (that I know), so all you can help positively with is welcome! You can track/reveal Primstar issues (bugs) at the right place: Issues it's a nice way to keep things organized and up-to-date.
I'm Manny not Domino, I don't know what he thinks about it, but fixes and its processes are quite sensitive, you should use the Issues tracker otherwise while trying to help you might end-up confussing or introducing bugs in those new users Primstar installations/configurations, and that's not positive for the project from my perspective, so giving away hackings/workarounds/altered/modified scripts, whatever you call it, is just sensitive.
Please, don't take it wrong, I'm not trying to be destructive but protective.
Oh, I was just trying to be
Oh, I was just trying to be helpful to Domino by providing my "hacks" so he could take a look a them. They are confined to the Mac, so won't affect any other platforms. Also, my zip file above only has the couple of files I touched which means someone else would have to go out of their way to get in trouble with them
And, I wasn't aware of the Issues part of this site, so whoops!
Thank's Fizz
It is helpful, a patch file would have been better (diff -u oldfile newfile).
I'm working through them and incorporating changes into Primstar now. Do you use git Fizz? If not I'll attach a test version when I'm done.
The GUI change came about after Gaia submitted her gui to replace the original one. You can follow the long discussion and coding issues that came up in the Area 55 mailing list archives during June 2009.
I think this message sums up the choices as I saw them at the time. And yes I'm still optimistic that we can capture all the necessary events to make tkinter seamless - though if I'd known then how many platform unique problems there would be, I'd have chosen differently.
Mac tweaks
I've attached altered versions of the three files you changed. I've based the changes on two assumptions:
1) tkinter on Mac isn't releasing grab correctly.
2) quit / destroy cycle wasn't working correctly.
Whether the changes fix this or not, I look forward to hearing about
You're very clever Domino.
You're very clever Domino. That works much better than my hack.
So no more exception messages in the console log
And blender "appears" to be stable. I did some basic testing with adding a sculpt mesh (worked fine) and baking a mesh (also worked fine).
The remaining, teeny tiny issue, is that the focus is "lost" when the dialog tears down, it doesn't move back to the blender window, so you have to click on the window border to bring it back into focus.
Nicely done!
Could you try this?
At the end of the add_mesh or render script, after root.destroy() add these lines
if gui.platform == "darwin": os.system('''/usr/bin/osascript -e 'tell app "Finder" to set frontmost of process "Blender" to true' ''')Actually it might be worth trying removing the grab_release - now the gui is destroyed properly, it might not need that - maybe I'm releasing Blender's focus instead.
And as we are in such different timezones, if it does need the extra lines (and they work), could you try them in the destroy_handler method of ModalRoot instead - I don't expect it to work, but if it does it saves having to add the lines to the individual scripts.
Testing 0.9.21 on Mac
I've added a version of this test to Primstar 0.9.21 - I can take it out again if it doesn't help
It'd still be useful to know whether removing grab_release was a better option if you could test that as well please.
So I tried the 0.9.21
So I tried the 0.9.21 release, "out of the box", and it works no better than before, with regards to Mac focus issues. No new noise in the system logs either (other than the stupid adobe one that all Mac photoshop users are dealing with right now).
I'm not sure which grab_release you're refering to, so if you let me know, I'll give it a whirl
grab_release tests
In add_mesh_sculpt_mesh.py it's on line 585, and in render_sculptie.py it's on line 444
in gui.py on line 240, could you add a print to make sure that the code there is being called but isn't working? It might be worth trying with a lowercase b on blender too. Not sure how the application name is seen by the finder, so I guessed. If you know how to find that out and make sure it's correct, better still.
Thanks
Ok, I did some more testing,
Ok, I did some more testing, and this version is a bit worse? than the previous version...
When I tried to select an image to bake with for the alpha layer, it didn't seem to work. The cursor would change to this bakers hat thingy, and then nothing would happen. I looked at the console, and saw an exception in "alpha.getPixelI" which leads me to believe that my prior (erroneus...) choice of alpha image was still being used, even after I had fixed the alpha image to be the proper sized image...
Alpha image protection
That's a bug, I've fixed it in git so it'll be in 0.9.22
And... I tried minimizing a
And... I tried minimizing a blender window after doing a bake, and blender crashes
Sigh, it was so promising...
We'll get there
Was? It still is promising. This is a complicated problem, but there will be a solution, everything we eliminate gets us closer.
Worst case scenario is I go cap in hand to the local colleges and see if they are willing to let me have a couple of hours use of a Mac. Or find some friendly SL person with an old Mac they are willing to donate as a test machine. Or a Mac Primstar user close to me (NW UK) with a good coffee supply who fancies picking my brain in return for letting me on their machine for a bit.
There's still lots of options
What sort of crash is it? Freezing or exit to desktop?
I tried commenting out the
I tried commenting out the grab_release's, and that didn't fix anything. In the 0.9.22 code, they are only present in the exception path, which means my comments had no effect since no exception happened
By the way, how do *you* enable the debug messages you've got. I've just been hacking that code to always print them...
I also tried, again, the osascript thingy you suggested, but that just gets blender into a funky mode, and doesn't solve the problem, so no help there. The mode I'm talking about is that you wave the mouse around and when it leaves the 3D view area, the freshly added mesh disappears! Middle-click or something like that gets it out of that mode, so I'm pretty sure the osascript hack is a dead end.
With your 0.9.22 code, attempting to option-click to minimize the application window results in a crash to the desktop. An interesting piece of data here, that may help things, is that blender doesn't normally minimize properly, in the best of times. What it does is properly minimize (the window gets hidden), but it won't restore properly under Snow Leopard. You have to go find the window, using Expose, to bring it back. After running primstar, that same behavior results in a crash (so its gets worse...). Seems like blender isn't quite the proper Mac citzen all by itself. Maybe a post within the blender forum's will shed some light? I dunno...Also, you might be able to find a knowledgable Mac blender developer there who can use your code and work out the glitches? Might go faster than this round trip via different timezones
The most obscure setting in Blender
There's a RT (runtime?) variable in the animation panel of the render settings in the scene buttons. By default it's set to 0. The higher you set it, the more of my debug statements will show up. Generally speaking I work in steps of 10, with inbetween numbers being finer detail of information for that level of debugging. so if there's a gui.debug(60, "some message") you are interested in, set rt to 60 or higher.
I'll have a think about the problem, as far as I know there's no one else has attempted this level of tkinter use in Blender. I might write a little test gui that fully records all events then we can see exactly what's going on. If there is a Blender bug affecting it, we might be stuck. Though with the 2.5 branch of Blender it sounds like there won't be a stable production ready release for about a year. That could mean we'll see 2.49c, 2.49d, but I'd prefer to get it as close as possible to working correctly in the meantime.
Post new comment