Initial window events unspecified, untested

[GoogleCodeExporter]

The events that will be received after making a window visible, or creating it 
visible, are currently  
undefined.  We can expect some combination/permutation of resize, expose and 
show.

A deterministic order should be specified, a test case written and then 
platforms modified to meet 
the test.

While at it, remove all event dispatching that isn't from a dispatch_events 
call, move into a queue 
(carbon does this for some events, see _queued_events for example).  This will 
alleviate need for 
on_resize workaround when creating a new visible window.

Original issue reported on code.google.com by Alex.Hol...@gmail.com on 10 Jul 2007 at 1:46

[GoogleCodeExporter]

This approach significantly changes the way Windows are initialised. Prior to 
this
approach, a Window() construction would result in an on_resize(). It no longer 
does,
and an application developer must now invoke window.dispatch_events() at least 
once
to get the context set up as per on_resize(). Or invoke on_resize ;)

Maybe this is just a documentation issue...

Original comment by r1chardj0n3s on 10 Jul 2007 at 4:32

[GoogleCodeExporter]

Why would the developer care what the projection is prior to entering the 
runloop?  All examples, docs etc use

while not win.has_exit:
    win.dispatch_events()   # this first
    render()   # then this
    win.flip()

Original comment by Alex.Hol...@gmail.com on 10 Jul 2007 at 7:37

[GoogleCodeExporter]

Pre-rendering. But then it's reasonable that anyone doing pre-rendering also 
control
their projection. My snark was entirely due to the hours lost tracking down the 
change ;)

Original comment by r1chardj0n3s on 10 Jul 2007 at 7:54

[GoogleCodeExporter]

Fixed for all platforms in r1114

Original comment by Alex.Hol...@gmail.com on 7 Aug 2007 at 12:45

• Changed state: Fixed