Comment 44 for bug 951000

> @Sebastien, thanks for your reply.
> I have tried the patch; it works good as expected and I have no issue with it.

great ;-)

> The reason I tried "dbus-launch gsettings set org.gnome.desktop.lockdown disable-lock-screen true" was because you
> commented on our private bug and ask us to try dbus-launch. Therefore, I assumed you still expected my reply.

Oh, sorry about that, my first though was to replace the gconftool call by a gsettings one, but that turned out to be too flacky, which is why I changed for the approch used there

> Since it su to guest user, it is reasonable to me that the gsetting can be set properly for guest user, and that is also what I see when I made tests to use "dbus-launch gsettings". I will be very happy to know what kind of difference causes "dbus-launch gsettings" not function in your side but my side.

Well, it's maybe due to the way I tested/debugged it (running the guest-session add script by hand) because I was getting the warnings robert_ancell mentioned earlier: "unable to create directory '/run/user/1000/dconf': Permission denied. dconf will not work properly.".

In any case going through: su -> dbus activation (dbus-launch) -> starting dconf-service -> write the key is lots of steps and seems not the most robust way, it's also expensive since it's going through user loginn dbus activation, etc.

The bug here also showed that the "run a command through su and rely on infos to be written to the right place" was flacky (the gconftool->migration approch worked half of the time), so I was reluctant building on the same base.

In summary: I think the current approch is safer, just log in an let the session run the command, no dbus activation, no su hackering ... just a normal command running in the user session context ;-)

I hope that makes sense