On Sat, 2010-09-18 at 17:32 +0000, Darren Hart wrote: > On Sat, Sep 18, 2010 at 10:12 AM, Daniel Rogers <dsrogers@xxxxxx> wrote: > > > Then when the network comes up set the properties in $HOME/.nm/gconf > > without a running gconfd with gconftool --direct: > > > > gconftool --direct --config-source=xml:readwrite:$HOME/.nm/gconf --load= > > $HOME/.nm/system.proxy.xml /system/proxy > > gconftool --direct --config-source=xml:readwrite:$HOME/.nm/gconf --load= > > $HOME/.nm/system.http_proxy.xml /system/http_proxy > > #this part forces all running gconfd-2's to reload read-only data. > > killall -q -HUP gconfd-2 > > > Where do you run this script from? The nm dispatcher scripts are run > as root, so the $HOME would expand to /root, rather than > /home/<myuser>... I have a dispatcher script that dispatches per user and per location. http://www.phasevelocity.org/~daniel/nm-scripts.tgz > Hrm, that is the sort of breakage I was trying to avoid by using the > gconf tool. Why use gconf at all if breaks the GNOME tooling? It would > be far easier to just write to /etc/environment and a similar user > file that the .bashrc can source. I suppose this doesn't setup the > gnome proxy for apps that use that... ugh... It doesn't break everything else, just gnome-network-settings. Everything else is still able to use gconf to get the system proxy settings. Regarding /etc/environment ... you could gather enough information about your login session to figure out how to connect to gconfd in another session, and set it there. Or use a custom gnome-session setup that always puts the socket in the same place (perhaps in /var/cache or /var/run). I didn't mind losing the functionality of gnome-network-settings, since it wasn't particularly useful to me anyway. -- Daniel Rogers mobile: 510-379-8302 home: 925-429-5109 office: 415-979-3740 _______________________________________________ gnome-list mailing list gnome-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gnome-list
