Re: [User feedback request] Shepherd
 

I like the sound of this context aware framework, sounds similar to Graham Cobb's DBUS scripts: http://www.cobb.uk.net/770/index.html#dbus-scripts

Just thinking about usability, and power consumption mainly, how many of these things/events have dbus messages?

Afaiu the network up/down/change stuff has messages one could listen for (and therefore not need to poll).

Things like the accelerometer are probably half way, some dbus messages exist, but to obtain more accurate data than simply portrait|landscape one would need to poll the sysfs device.

Same goes for location, really course data is pretty much free, but to get more accurate data the GPS will need to be running.

Attila, how do you currently hook into events? And do you have some test code available?

Re: [User feedback request] Shepherd
 

Mostly using stuff via (Qt-)DBUS. I try to stay away from polling, but for some things it's inevitable). The whole architecture is pluggable - the idea is that you register a plugin that can signal the framework that a condition is met. These plugins are pretty independent, so the actual implementation (listen to dbus, poll, alarmd, use some other service, etc) is left to the plugin.

Another thing wrt to power usage - I plan on labeling plugins regarding their power usage pattern. DBUS/alarmd based things get a green mark, things that need occasional (relatively cheap) polling get yellow, and things that actively use juice (like GPS) get a red power rating. That's the inital (not yet implemented) idea, anyway, so people could really think twice if they wish to enable a particular plugin.

This could mean two location plugins, too, a yellow, coarse location enabler, and a red, 'full' GPS one. These can also be chained - i.e. if the coarse location gives us Amsterdam, we won't bother turning on the GPS/checking if we are in a particular street in Paris.

I'm slowly stabilizing the plugin/action API. When I'm confident enough that daily breakages of these will not occur I plan on pushing the whole thing to extras-devel. Until that happens, the code is pretty fluid, so not much use from it (you can't really test the plugins without the shepherd part)...

Re: [User feedback request] Shepherd
 

Whatever happened with this?

Re: [User feedback request] Shepherd
 

In progress :) It needs two things before it's released to the public:

a) stable API so the plugins do not get outdated on a weekly basis

b) finish the GUI so it's end user friendly - I have finished a few dialogs but it's far from robust/complete.

As soon as I have it ready on a level where people might start using it or contributing without fear of serious breakage (as it hooks/affect pretty low level APIs, it will be in extras-devel).

Re: [User feedback request] Shepherd
 

Doesn't seem to be here (at least not using thread search), so I'd like to request a no-ip.com updater that will send an update whenever your device's IP address changes.

Re: [User feedback request] Shepherd
 

I wonder if there is a DBUS message for IP changes, there is for connection changes but I'm not sure for DHCP or NAT-ed address changes... The update itself is just a oneliner action plugin (=script).

Re: [User feedback request] Shepherd
 

Maybe I should bug fiferboy to add it to his IP address widget. :)

Re: [User feedback request] Shepherd
 

There's the Dyndns & SSH thread.

Re: [User feedback request] Shepherd
 

A while back a thread was started about an s60 application called mobots. As it is in some sense similar to Shepherd I thought I'd mention it here, for inspiration or whatever.

Re: [User feedback request] Shepherd
 

any news on this? i'd love to try it out :]