Hi Sebastien! First of all, thank you very much for your suggestions :)
I get your point and I think this is the real problem. I guess gsettings command line tool from the snap is storing the correct key/value inside the snap, but the "native" dconf database is not getting the new value, because the change wasn't made using "native" gsettings command line tool. I have tried to search dconf database within snap confinement, but I couldn't find it. Where should I search for it to see if the new value for the wallpaper was set there? P.S.: I've been searching within the tree which is in /snap/wallpaperdownloader/current with no luck. Thank you very much again :D 2016-09-06 11:42 GMT+02:00 Sebastien Bacher <[email protected]>: > Le 30/08/2016 à 10:15, Eloy García (PC Actual) a écrit : > > Thanks for your answer, but I forgot to say I tried gsettings and > > unity7 interfaces with no success. Nevertheless, I only put those > > interfaces in snapcraft.yml, but I didn't do anyting else > > (configurations, tweaks...). Adding more information, this is the > > script executed when wallpaperdownloader is launched. Maybe it is here > > where I should add some mappings to the "native" environment? > > > Hey again, > > Did you figure it out? The gsettings command talk over dbus to the > service which is in the user session, so the key should be written in > your user db, the confined code in the snap doesn't get back the value > since dconf does that by mapping a file from the user directory so it > might mean your frontend might not get the new value of the key. Can you > check from the outside the value of the key? > > If you use the shared desktop launcher it includes an hack to symlink > the snap dconf db to the real one which should make reading work as well > > Cheers, > > Sebastien Bacher > > -- Eloy García Almadén
-- Snapcraft mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
