Michael Ekstrand wrote: > > So, basically, you shouldn't look for a way to listen to the signals > from within GDK - you need to look for a way to interact with the > events causing these signals *before* (or after, depending on what you > need) they reach GTK. So, conceptually, if there exists some code: > Maybe I don't understand what the goal is here. If all you want is to know when one of the events in the Subject line happens, then the simplest platform independent low-level way to do it is the gdk_window_set_filter. If you want to track down how double buffering is being done, then you need to look at the GdkWindow API documentation for the gdk_window_begin_paint_* and gdk_window_end_paint functions. <rant> My original point was that this information is in the GdkWindow API documentation and locating it wasn't hard, even if you know little about GTK+. The technique is the same no matter what system you are looking at. You know what functionality is desired or appears to be a problem. Therefore, your first action is to look for API functions related to that functionality. In most reasonably designed libraries, the starting place is typically the most obvious. Those of us who have been doing this a long time either lose patience or don't even bother replying because having someone else give you answers that are easy to find rewards you for not using common sense; it makes lazy, sloppy programmers. Yeah, GTK+ is getting big and awkward, but some logic went into the design. You can depend on that. </rant> -- ------------------------------------------------------------------------ Mark Leisher Computing Research Lab They never open their mouths New Mexico State University without subtracting from the Box 30001, MSC 3CRL sum of human knowledge. Las Cruces, NM 88003 -- Thomas Bracket Reed (1839-1902) _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
