Re: wnck_screen_get_windows() returns empty window list

[Havoc Pennington <hp redhat com>]

Elijah Newren wrote:
> We could get rid of this stumbling block, I believe, by calling
> wnck_screen_force_update() within wnck_screen_construct().  But, there
> might have been a reason to not do that, so I need to ask Havoc if
> such a change would be a good idea or not.

My guess with no research is that I wanted to avoid having to "get the 
current state" after constructing the screen, i.e.
 screen = wnck_screen_new();
 signal_connect(screen, "window-added", handler);
then right now it can rely on the handler being called for all windows, 
if you did the update in the constructor then you have to add code here 
to manually call the handler for all existing windows.

I'm just guessing... you might want to look at what the panel applets 
really do.

The overall idea here is that async is almost always the correct way to 
write an X app, unless it's a run-once-and-exit command line utility, 
and so metacity and libwnck/wnck-using-applets are all completely async. 
If you're writing all the async stuff anyhow there's no point putting a 
possibly-inefficient or possible-reentrancy-issue-causing forced update 
in the constructor. It just encourages bugs where you init one way and 
then handle changes another way, or race conditions.

The other rule for async sanity of course is "don't write through the 
cache" i.e. if we have a local copy of the data and ask the server to 
change it, don't change the local copy, just let the change notification 
from the server update it. Elijah you'll be well familiar with this from 
metacity but also gconf etc. Anyway I imagine people will find this 
confusing as well...

libwnck as a whole is an atrociously not-designed-for-public-use API 
though, sort of very "GTK 1.0" ... I'd certainly suggest that anyone 
using libwnck be prepared to dive into the libwnck source code and 
diagnose oddities.

Havoc