Wow, thanks!  With this information I found the ApplePersistenceIgnoreState 
key, and I've committed a fix that should prevent the 
org.python.python.savedState file from ever being created or used.  This fixes 
the problem of new windows not being displayed after finishLaunching got 
called.  It also explains why the problem was only showing up with certain 
builds of python and not pypy.  There is an Xcode build setting that can be 
checked to prevent automatic state restoration for the application and I'm 
guessing the python from python.org doesn't have this set.

When you run a pyglet program from the terminal, there is a warning message 
saying that it won't be saving or restoring state.  But I think I can live with 
that.

--phillip

On Dec 7, 2012, at 1:20 PM, Steve Willis <[email protected]> wrote:

> Yes. In fact, I am very new to Pyglet, and initially encountered this issue 
> when trying the first "Hello, World" example in the Pyglet documentation. The 
> development version runs without error and the Python process is running, but 
> no window appears. After suppressing the creation of the 
> org.python.python.savedState file, everything has gone smoothly.
> 
> A little research tells me that this file, and the many others like it, are 
> part of the feature which can be configured with the "Close windows when 
> quitting an application" checkbox found in System Preferences | General. In 
> my case, checking this box did not solve the problem by itself, but the file 
> is related to this feature allowing for OSX to restore the window state and 
> open documents within for compliant applications.
> 
> I have also observed that this file is not created immediately in all cases. 
> Before suppressing the creation of the file by locking permissions on the 
> Application State folder (disabling this feature for all other applications 
> as well), I tried manually deleting it while developing a simple test 
> application. In some cases, it was several minutes before the file was 
> created. In some cases I could even launch my application again after its 
> creation, but not consistently. The only method that has proved reliable is 
> to avoid creating the file in the first place.
> 
> One final tidbit: I also tried simply checking for the existence of this file 
> and deleting it when found as the first task in my Python script. This did 
> not work. As a result, I suspect that the file is created at the time Pyglet 
> is initialized on import, and not necessarily at the time a window is 
> actually displayed. 
> 
> Steve
> 
> On Friday, December 7, 2012 11:49:39 AM UTC-7, Nathan wrote:
> On Fri, Dec 7, 2012 at 11:28 AM, Steve Willis <[email protected]> wrote:
> I am using the latest development Pyglet from the mercurial repository on OSX 
> 10.8 without issue, aside from the need to suppress the Application State 
> file as described previously. I haven't run any tests outside of my own 
> project, but it seems to be very stable thus far.
> 
> Steve 
> 
> 
> That is so weird that you have to suppress the creation of the 
> "~/Library/Saved Application State/org.python.python.savedState" directory.  
> That directory exists on all my 10.8 installations, but has never caused a 
> problem.
> 
> Does the problem occur even if you do a basic "hello world" pyglet app?
> 
> ~ Nathan
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pyglet-users" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/pyglet-users/-/2jopLtpcMh0J.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/pyglet-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"pyglet-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/pyglet-users?hl=en.

Reply via email to