Background set prior to initial Nitrogen launch not preserved

[sidequestboy]

It would be good if on startup, Nitrogen stored the current state of the desktop to use for example as a fallback in the case discussed in #34 of (no config file->preview background->delete window->"No" to apply changes dialog)

This case happens in general on first launch of Nitrogen if the user chooses "No" to the apply dialog.

I don't know how feasible this is.

[daf]

This is in part why I brought up the "nav" branch - not sure if I ever implemented this part of it but it was always the goal. This it the most robust way to handle the "edge case" discussed in #33. I'm happy to merge that without solving this first, however. It can come after (but before a release).

[sidequestboy]

Trying to find other programs that might do this.
http://bazaar.launchpad.net/~m-buck/+junk/gtk-desktop-info/files these guys special case window managers to find the standard filepath to desktop image - stupid!

conky has a "pseudo-tranparent" setting implemented here:

if (set_transparent) {
    Window parent = win;
    unsigned int i;

    for (i = 0; i < 50 && parent != RootWindow(display, screen); i++) {
        Window r, *children;
        unsigned int n;
        XSetWindowBackgroundPixmap(display, parent, ParentRelative);
        XQueryTree(display, parent, &r, &parent, &children, &n);
        XFree(children);
    }
} else if (colour_set != background_colour) {
    XSetWindowBackground(display, win, background_colour);
    colour_set = background_colour;
}

[daf]

The proper way to handle this is to read the XProp that controls the background pixmap on the root window as we start Nitrogen. Normally, when we first set any bg with Nitrogen, this pixmap is destroyed/freed. If instead of destroying that pixmap, we keep a reference to it until Nitrogen closes, we can get this desired behavior of reverting as if Nitrogen did nothing.

This opens up a possibility of a leak of that old Pixmap if Nitrogen crashed at any point before it was able to commit, but this is not a large concern.

Conky/terminals with "pseudo-transparency" set that ParentRelative mode which allows the root pixmap to come through a mapped window (probably not an entirely correct description) - this doesn't really help us here.

[daf]

I've just had a look at my nav branch (uploaded now: e621b04), but that was an item I hadn't gotten to.

[sidequestboy]

Yes, the reason I brought conky & Xlib's XSetWindowBackgroundPixmap up was that it is one of the few functions I've been able to find that accesses the background pixmap of the root window. We set it with gtk's gdk_window_set_back_pixmap, but I cannot find any reference to a function that gets the pixmap.

This one sounds close (but it's in gtk+-3.0 only): gdk_pixbuf_get_from_window - I can't find any similar function in gtk+-2.0 and this the gtkmm binding: Gdk::Pixbuf::create

But,

If the window you're obtaining data from is partially obscured by other windows, then the contents of the pixbuf areas corresponding to the obscured regions are undefined.

So, still not what we need...

[daf]

We already have this ability in source: https://github.com/l3ib/nitrogen/blob/master/src/SetBG.cc#L149-L164

Instead of calling XKillClient here we simply save the pointer to data_root to be dealt with later. And obviously split this out into a function etc...

You can make a GdkPixmap from a "foreign" ref like the actual X id like we have here, if for some reason we need to put it into the Gdk world, but for the purpose of this I don't think we need anything different, except maybe to convince the root window to repaint - but I think we can find an Xlib call that'd take care of that.

[daf]

Just like #34, as of 53135f0, the initial background prior to Nitrogen's launch is preserved and restored. The previous background does not need to be set with Nitrogen in the first place - it will just read whatever's currently there, set by any application.

This needs testing. I've only had a chance on Xinerama setups so far.