On Tue, 2007-10-16 at 16:12 -0600, Jeff Eberl wrote:
[...]
> First is that the display doesn't do anything when my program is doing
> it's thing. So it looks like it freezes. I'm okay with that. I've
> never used threads before, and I'm not sure this is the best project to
> start with.
ofcourse this can be fixed by splitting up whatever your app does into
smaller less cpu/load intensive itterations thus updating the gui more
often, but that involves work (just like integration your execution
into timeout/idle callbacks would involve work).
> Second is the most annoying part. Since there is no loop,
> gtk_main_quit() doesn't work, and when I click the little [X] in the
> corner, the destruction begins, calls my WindowDestroyEvent that I set
> up in the signals, but my program has no idea that the window has been
> destroyed.
How can your program have no idea that the window is being closed
if you set the signal handler for "delete-event" ?
> Then the program keeps making the same calls to gtk. So gtk
> spits out a bunch of messages about how everything is failing.
>
> Is there a way to check to see if the window has been destroyed? I
> could put a member boolean that changes when WindowDestroyEvent gets
> called but that seems like a suspicious hack.
However you do it, its definitely up to you to bookkeep that information
(some might keep a pointer to the active display window and set it to
NULL when the window is destroyed, I dont see how thats better than
a boolean variable).
For elegancy, you might want to add it to a structure that gets passed
around to all callbacks instead of crudely packing it into global scope.
Cheers,
-Tristan
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
