Re: wnck_screen_get_windows() returns empty window list

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]