Re: detecting window visibility

[Carlos Pereira <carlos pehoe civil ist utl pt>]

>To me, this is all about having the machine know how to "do the right
>thing" based on the situation.  Here are two scenarios for where I
>want to be able to do this:
>
>Imagine a situation where some computationally expensive process (say,
>animation produced by rendering complex images on-the-fly) is occuring
>in a window.  The polite thing to do is to detect when that window is
>not visible and to automatically pause the animation until that window
>becomes visible again.
>
>Another scenario: when some noteworthy situation occurs, signalling it
>with a visual cue in a window, and combining that with an audio cue if
>and only if that window is not visible.  (In general, I don't like to
>have my computer chirping at me unless it is absolutely necessary.)

Ok, here goes my take on this (if these are old news for you, 
then my apologies):

I have a structure (let's call it app) that keeps a list
of all windows, layers, lights (this is a GTK/Mesa app), etc...
that are being used at the moment. Each window in turn is a structure
that allocates all information regarding what the user calls a window.
This means the address of the window GTK widget, a list of the layers
that the user created, etc... each layer in turn has information like
the type of projection, the color of the background, the active lights,
 etc... this gives you an ideia of the kind of overall design I have.

In all my app I have a single general variable, which is that unique 
so-called app structure. In my call back functions, I pass a pointer 
for the key object, usually the window, but it can be a gl_area, etc... 

Now imagine that, as you said, you want to prevent some heavy animation 
to take place when you switch to a different window: when you change to
the new window, typically some expose event will be triggered, in the
corresponding call back you will have to go through the whole list of
windows, and compare the address with the current window (that was passed
as a gpointer to the call back function). If the address is different, 
then you know that you are in a different window: check if a heavy 
animation is taking place there, if the answer is yes, just switch it off.
(I am not discussing here threads and other tricky things...)

About your second example, the method is basically the same, if you have
a new mail, for example, and you only want to receive a beep if window A
has no focus: in your expose call back function you pass the window gpointer,
which can then be used to update the information used by a timer function
that every 60 sec check for new mail. If a new mail is indeed received,
this function knows the address of the current window and it has just to
compare it with the address of window A: if the address is not the same, beep!

Usually, the situation is simpler: if I am rotating a complex Mesa
picture in a window, and I move the mouse to other window, I will
start rotating the new complex Mesa picture, and this happens
automatically because the data that the call back functions receives when
events are triggered is the current window address (as a gpointer),
which in turn alocates the current layer, which in turn allocates
all the picture information. If I want to rotate the images of different 
windows at the same time, by moving the mouse, then I have to go through the 
whole list of windows, update the picture information that is stored in the 
current layer in each window and then generate expose events for all the 
windows in the list, to force all of them to be redrawn.

Again, note that this window address is the address of my window object,
which in turn contains the GTK object, which in turn contains the GDK (X)
object. So I think this is essentially a question of design, of layout
of your application, one thing is the GUI, the other is the engine!

I hope this gives you some ideias!

Carlos