Re: [gtkmm] Talk about a major rewrite

[Paul Davis <pbd op net>]

>If I understand you correctly, I think I've run into similar issues, and 
>my GUI classes are cluttered with ugly boolean flags like 
>in_changed_handler_ that I test to avoid redundancy or infinite loops. 

yep, thats the sort of thing you end up with. i frequently avoid it
with (pseudo-code):
	
	if (widget.state() != model.state()) {
             widget.change_state();
        }

but this still causes a loop at least once, and so in some cases the
bool flags end up being necessary. yuck.

>Even though my models check for actual change before emiting 
>notification on setters, with rounding errors I can get into  loops 
>between model/view updates. Also sometimes the model is on another 
>machine over the network with other clients updating it too so I can get 
>into ugly timing race conditions or "loops around the whole network".

this is analogous to the multi-thread/multi-controller model on one
machine. it gets ugly really fast. 

>However can't we think of the main event loop as simply reading events 
>one at a time and calling functions to process them? Isn't this 
>analogous to reading bytes from stdin and processing them until EOF? I 
>guess it doesn't seem that dark to me. 

you've never used a recursive call to Gtk::Main:run() eh? :)

popup a non-modal dialog, and do a recursive run(). now think hard
about what's happening... and how to exit the program at this point if
asked to ...

--p