[14:18] <stgraber> jodh: so far no feedback is good feedback I guess? :) I saw you made a bunch of edits to the wiki page, will quickly go through them in a minute.
[14:19] <jodh> stgraber: just one comment so far (to upstart-devel only): https://lists.ubuntu.com/archives/upstart-devel/2012-November/001988.html
[14:24] <stgraber> jodh: ah, I guess I should subscribe to upstart-devel ;)
[14:26] <stgraber> jodh: I'm not sure I really see the point of having public and private events considering that the effect on the system will be public anyway (and anything passing on the system bus is public)
[14:26] <stgraber> jodh: but if that becomes useful, I guess we can always implement a :sysprivate: namespace for those
[14:28] <jodh> stgraber: the problem is that if we don't have public/private events, a user job may 'accidentially' change state based on a system event. Hence, it would be convenience if the user had to choice of either having a job react to a named event from any source, or only react if its a system event, or only react if its a user event.
[14:31] <stgraber> jodh: right, but the current design does that. You can simply do "start on :user:dbus" to only react to the dbus job of the user instance of upstart
[14:33] <stgraber> jodh: My interpretation of Evan's e-mail is that he wants to add some private/public flag to "initctl emit" so that if you do "initctl emit blah" against the system upstart the event won't be sent to the session instances
[14:33] <stgraber> jodh: but that you'd have to explicitly do "initctl emit :all:blah" to have it be sent to the instances
[14:55] <jodh> stgraber: right - I think we were talking "cross-purposes" there - I though you were saying we didn't need :user: and :sys:. Just replying to his mail...
[16:25] <stgraber> stgraber@arkose-tmpCXgHdn:~/Desktop/upstart$ ./test 
[16:25] <stgraber> Got a change: /org/gnome/nautilus/desktop/volumes-visible
[16:25] <stgraber> jodh: ^ :)
[16:26] <stgraber> using the dconf API to get any gsettings change. Now I just need to decode the new value and plug that thing into an upstart bridge (figured it'd be a reasonable way to refresh my memory on nih/upstart coding)
[16:47] <jodh> stgraber: awesome! ;)
[17:04] <stgraber> jodh: monitoring dconf is really quite easy :) http://paste.ubuntu.com/1372844/
[17:05] <jodh> stgraber: nice :)
[19:29] <stgraber> jodh: oh, one thing that'll be fun in the dconf bridge is that I'll need both libnih and glib, need to figure out what to do with the main loop :)
[19:30] <SpamapS> stgraber: out of the question to have two processes?
[19:32] <stgraber> SpamapS: well, ideally I'd like the dconf bridge to be a single process. The only real source of events will be on the glib side, so I'm trying to avoid the nih main loop entirely for now, if that doesn't work, I'll probably just end up replacing nih by glib for that bridge and glib-dbus instead of nih-dbus