Merge lp:~rtandy/compiz/lp1232299 into lp:compiz/0.9.11
Status: | Merged |
---|---|
Approved by: | Brandon Schaefer |
Approved revision: | 3851 |
Merged at revision: | 3859 |
Proposed branch: | lp:~rtandy/compiz/lp1232299 |
Merge into: | lp:compiz/0.9.11 |
Diff against target: |
77 lines (+21/-6) 2 files modified
compizconfig/gsettings/gsettings_backend_shared/ccs_gsettings_backend.c (+12/-6) compizconfig/libcompizconfig/src/main.c (+9/-0) |
To merge this branch: | bzr merge lp:~rtandy/compiz/lp1232299 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Brandon Schaefer (community) | Approve | ||
Review via email: mp+214394@code.launchpad.net |
Commit message
Fix gnome-flashback session starting Unity plugins. Change the profile back after processing settings upgrades. When changing profile, discard existing GSettings wrappers pointing to the old profile. Fixes: 1232299
Description of the change
This is my attempt to fix bug 1232299.
The scenario: you're logging into an environment other than Unity (so the profile is probably Default), and there are settings upgrades that haven't been applied yet. Easy to reproduce: install gnome-session-
The settings upgrade machinery changes the profile to process upgrades. It needs to change it back afterwards.
The GSettings profile caches a wrapper for each schema. When it retrieves one by schema name, it needs to make sure that it actually does wrap the expected path, because the path includes the profile name, and exchange it for a new one if necessary.
I didn't measure the performance hit of checking the path name on each wrapper lookup. It might be better (more efficient) to clear the list and start from scratch when the profile changes.
I also don't know for sure whether freeing the wrapper is actually safe. I didn't find any places where it looked like other code was holding references to it, but that doesn't mean they don't exist.
I experienced one crash in unityshell while testing this (didn't have unity's dbgsym installed at the time, sadly) but I can't reproduce it now so I don't know whether or not my changes caused it.
This is almost certainly too risky for trusty at this time, but I'd love to see it in an SRU eventually.
> It might be better (more efficient) to clear the list and start from scratch when the profile changes.
Thinking about that again this morning, that almost certainly makes more sense. I've re-pushed the branch doing it that way instead. Had to move one function earlier in the file so the declaration would be visible. Apologies for the noise.