Hi,
Sven de Marothy wrote:
This should fix PR #16203, and also make for a general improvement.
In short: The main GTK loop is not started statically in GtkToolkit,
but rather on creating the first window peer. (as it should be).
In long:
On destroying the last window peer, we call gtk to end the main
loop and the thread exits. If a new window is opened, we create
a new thread object and restart the main gtk loop.
I also moved all the stuff related to this (except native methods)
out from GtkToolkit and into a new GtkMainThread class. This should
help reduce the clutter in the already ugly GtkToolkit class.
It seems to work just fine for me, but being a rather central thing
I'd like some feedback and testing before committing it.
(Obviously not intended for the 0.92 release)
Thanks for tackling this. On Sun's implementation, according to this document:
http://java.sun.com/j2se/1.5.0/docs/api/java/awt/doc-files/AWTThreadIssues.html
the three exit conditions are:
* There are no displayable AWT or Swing components.
* There are no native events in the native event queue.
* There are no AWT events in java EventQueues.
The first two conditions are satisfied by quitting the GTK main thread (no
native events) when there are no windows left (no displayable AWT or Swing
components). I'm wondering if we need a check for the third condition before
quitting the GTK main loop.
Tom
