Created attachment 115011 [details] [review]
Adds libwnck to reload the background preferences on workspace change

Hm. What about having the GnomeBG listen for the switch instead and simply letting that issue the normal "changed" signal.

(Also, some minor quibbles concerning non-matching coding style.)

To do that we'd have to have the concept of the GnomeBG object tracking the gconf key; since currently a GnomeBG is only synchronised to gconf when an explicit save request is made.

The obvious advantage with doing it that way would be you don't have to copy and paste the code in g-s-d and nautilus. Do you see any disadantages? Or advantages of doing it the other way around?

Having thought about it a bit more its not clear exactly how you would define the semantics of a GnomeBG tracking the gconf keys.
There are two cases:
1. The gconf key changes
2. The current active workspace changes

Case 1 is straight forward since you can just record the notify id from the gconf api in the GnomeBG object and emit the changed signal in the callback.

Case 2 is not so easy to define; in some cases e.g. the capplet you'd want the GnomeBG object to track gconf but not workspace changes, but in other cases you'd want to track both types of changes i.e. in g-s-d and nautilus. Other bugs suggest though that knowing the difference between the two types of changes is useful; there's a bug for people who want different sets of icons on the desktop which would imply changing XDGHOME or something similar on workspace change and you could also implement per workspace sound theme support too; in that case you'd be duplicating the workspace change code again, it would seem more appropriate and semantically correct to have the code in the settings-daemon rather than in the individual libraries.

An alternative would be to place the code into gnome-desktop as a separate workspace configuration object, which could aggregate the different per workspace settings e.g. background, sound theme etc.. and do the signal emission there; we can mirror the libwnck api and have a ScreenSettings object that contains multiple WorkspaceSettings objects; then the API would become well defined for the cases above; WorkspaceSettings would emit signals in case 1, ScreenSettings would signal changes in case 2. I think this would be the best way forward since it avoids copy n paste code and has the flexibility to be extended in the future.

Fair enough. If you can get an ok from the nautilus camp as well, I'm fine with this approach.

Any update on this ?

Per-workspace backgrounds are a relatively common feature request ...

If I understand correctly, workspace means monitor #1, #2 etc. in multi-monitor setup, right? So different background image for every one of them? What about different settings like zoom/stretch/tile etc.?

The gnome_bg_load_from_preferences() call in your patch takes a workspace number argument, do you have that gnome-bg patch somewhere? Otherwise you would have to deal with storage of values for additional screens, now with GSettings.

I'm not familiar with libwnck much, is there a significant difference to those "monitors-changed" and "size-changed" signals of GdkScreen that we're using now?

Anyway, I agree this should go to gnome-bg since gnome-settings-daemon and nautilus share that code now.

(In reply to comment #3)
> To do that we'd have to have the concept of the GnomeBG object tracking the
> gconf key; since currently a GnomeBG is only synchronised to gconf when an
> explicit save request is made.
This is still true with GSettings and we can't add monitoring to GnomeBG since settings can be loaded from different places and workarounds could be in place, so at the end monitoring wouldn't work as expected (false notifications, misses).

This doesn't really make a lot of sense in GNOME 3 with dynamic workspaces I think. Perhaps this can be implemented as an extension?

Especially as gnome-shell will soon handle the background on its own. See bug 682427.