Abstract

Shepherd is an advanced scheduler that can do a wide variety of tasks depending on a number of triggers.

The project will aim to improve on the capabilities of Shepherd. I plan to add more ways of triggering an action and more actions to be taken when the triggers is meet.

Full Description

Shepherd currently has the ability to start and stop processes depending upon time, connection type and power requirements. The goal of my project is to extend the capabilities to include a whole range of triggers and also extend Shepherds capabilities to perform different actions.

In a certain situation you might not want to be disturbed, say for example at your workplace. A configuration might then have a trigger on the SSID of the WLAN-stations at your workplace and the actions might be to silence the phone and set the telepathy presence to Busy.

I plan to add a number of plug-ins to shepherd in order to expand its capabilities as well as help improve on the current code in order to make it stable enough for a release. Shepherd is written in C++ but I also hope to enable functionality for python modules.

Tasks and deliverables

Back-end

The back-end is the most important part of Shepherd and is mostly in place. The back-end uses several parts of Qt, among others QtDBus for inter-process communication and QtNetwork for networking. Utilizing Qt not only makes the code simpler but it does also help improve portability.

The API for the plug-ins (triggers/actions) need to be stabilized in order for the development of new plug-ins to begin. The functionality for python modules does also need to be added.

Each situation should have a priority in order to determine what actions are most important. There might be cases where several situations are applicable but define different values for the same actions.

Front-end

At the moment Shepherd has no graphical user interface. The GUI should give end-users the ability to configure Shepherd as well as add, edit and remove situations. The plan is to use Qt in the form of QtGui for the design of the front end.

Triggers

Each trigger is a criteria in a situation. For example the location can be a trigger, if the device is within a certain range of a point then the criteria are met.

Here follows a list of triggers I plan to implement followed by a list of possible triggers for future implementation.

• WLAN SSID - Check if a WLAN SSID is nearby
• Location - Check if the device is in a certain location
  • GPS - By using the GPS
  • CellID - Or by using the cell-towers, uses less power than GPS.
• Calendar - Check if certain events are happening.

The following triggers might be implemented if time permits.

• Telepathy status - Are certain accounts online/busy/offline?
• Accelerometer - Check if the device is in a certain position
• Proximity sensor - Check if something is nearby, e.g. if the device is in the pocket
• Light sensor - Check if the light is above/below a certain limit.
• Open/closed HW keyboard
• USB Cable connected
  • in Mass storage mode
  • in PC Suite mode
• Headphone connected
• Certain bluetooth devices nearby

All triggers may be negated in order to increase the configuration possibilities.

Actions

When a certain situation arise one or more actions are performed. I’m planning to implement the following list of actions:

• Change profile
• Turn Radio on/off
  • for WLAN
  • for 3G
• Change Telepathy status
• Secure device
• Display a notification

If I have time I will also try to implement some of the following:

• Change volume
• Turn vibration on/off
• Turn screen on/off
• Turn Radio on/off
  • for the FM transmitter
  • for the FM Receiver
  • for GSM
• Go in/out of offline mode
• Send IM/SMS/EMail
• Shut phone off
• Change background
• Change ring-tone

Schedule

April 26 - May 24

Find out what is needed for the different actions and triggers. Take a decision on how the API for plug-ins should look like.

May 24 - June 13

Work on the back-end and make sure the API is stable and usable.

June 14 - June 27

Work on the front-end.

June 28 - July 4

Triggers to be completed:

• Location

Actions to be completed:

• Display notification

July 5 - July 11

Make sure the application works properly, all documentation is in place and everything is in order.

July 11 - July 16

Midterm evaluations.

July 17 - July 25

Triggers to be completed:

• Calendar
• WLAN SSID

Actions to be completed:

• Change profile

July 26 - August 1

Actions to be completed:

• Telepathy status
• Turn WLAN/3G on/off

August 1 - August 9

Actions to be completed:

• Secure device
• Change telepathy status

August 9 - August 16

Make sure the application works properly, all documentation is in place and everything is in order

August 16 - August 20

Final evaluations.

Other commitments

I have no other commitments during the summer and Shepherd will be my highest priority.

Why me

I have long seen the need for an application such as Shepherd and I believe it has a lot of potential. I’m very motivated because of the wide range of use-cases that exists for Shepherd as well as the opportunity for me to learn from and contribute to the community around maemo.

Ever since I heard about Nokia N900 around the release last year and discovered maemo.org I have been looking forward to develop for the maemo platform. I finally feel I have found a device and a community I really feel at home with. I see this project as the perfect opportunity to become a serious developer and begin contribute in order to give back to the community what I feel it has given me.

Last year I participated in GSoC and wrote a command line interface in java to SIP-Communicator, a VoIP and chat client. I have also participated in NCPC, Nordic Collegiate Programming Contest, in both 2008 and 2009 which has helped me improve my problem solving abilities.

I have worked with C++ in school and have written programs ranging from simple command line games to integer factorisation algorithms using GMP. I perform most of my developing in debian using Git in a number of languages, including python.

Community aspects

To be able to change settings automatically is something not only useful to myself, but to a wide range of users. This is evident by the responses to the thread http://talk.maemo.org/showthread.php?t=31524 in talk and also the great respons Locale have recived on the Android platform.

Each plug-in does also serve as a good example on how to utilize the functionality provided within them. This might be useful even for people that are not directly interested in Shepherd but who are searching for a way to perform a particular task provided in one of the plug-ins.

Contact information

Email: linuswa@kth.se IRC: ecksun at freenode

XMPP: linus.wallgren@gmail.com

Skype: ecksun

SIP: linuswa@kth.se

Biography

I’m a student at the Royal institute of technology in Stockholm, Sweden. Currently I’m doing my third year of a five year computer science masters program. At the moment I’m working on my bachelor thesis which is about studying how Q-learning behaves under different circumstances.

As mentioned earlier I participated in GSoC last year when I worked for SIP-Communicator and extended its functionality in order to control the client from the terminal. I did also mention that I competed in the Nordic Collegiate Programming Contest the last two years.

On my spare time, when I’m not at my computer, I practice a mixed martial art called Goshindo or if the weather and time of year allows I love to wake-board.

Application Suppliment

achipa wrote:

I would very much like to see the proposal extended/thought out with regard to the plugin UI. The original problem with plugin UI/API was that it was difficult to make a consistent GUI for the plugins. The plugins should have a unified GUI, it would be bad practice for each plugin to have a separate UI mechanism (except where technically warranted, like spatial input). It would help avoid situations where contributed plugins get outdated and incompatible because they rely on different versions of Qt, bindings, etc. This would also make it reusable for a desktop version of Shepherd.

My respons:

The first part of the GUI the user will see is a list over all available situations, when you press a situation you can see and edit a list of the actions and triggers that are utilized in that particular situation.

Almost all plug-ins will use the same basic types of input:

• Text input
• Drop-down selection
• Slider for numbers
• Do nothing

The first three types will be used by several plug-ins, for example the WLAN SSID trigger might use the text input type and changing profile might use a drop-down selection. For example to shut the phone off does not really require any configuration, which merits the existence of a input type that does nothing. The only plug-in mentioned above that might have use of another type of input is the Location trigger which could use a map for inputting the spatial data.

There will be methods for automatically creating the above input types. This can be done by calling a GUI component of shepherd and asking it to add one of the components. For example the code to configure the WLAN SSID trigger might look something like:

ShepherdGUI::addTextInput("ssid", "Please provide an SSID: ");

If no input type is specified the GUI will assume the plug-in will provide its own GUI and use QUiLoader to load a .ui file in which the plug-in have defined how the configuration interface will look like.

The information entered in the input dialogs can be fetched either by the plug-in asking for it or by a callback, depending on what seems more appropriate when the time comes to decide how the API should look like.