Merge lp:~charlesk/indicator-datetime/lp-1233176 into lp:~indicator-applet-developers/indicator-datetime/trunk.13.10
Status: | Merged |
---|---|
Approved by: | Ted Gould on 2013-10-17 |
Approved revision: | 289 |
Merged at revision: | 277 |
Proposed branch: | lp:~charlesk/indicator-datetime/lp-1233176 |
Merge into: | lp:~indicator-applet-developers/indicator-datetime/trunk.13.10 |
Diff against target: |
1389 lines (+861/-107) 13 files modified
README (+7/-1) configure.ac (+2/-0) debian/control (+1/-0) src/Makefile.am (+2/-0) src/main.c (+45/-4) src/planner-eds.c (+179/-70) src/planner-eds.h (+0/-2) src/planner-mock.c (+178/-0) src/planner-mock.h (+58/-0) src/planner.c (+20/-0) src/planner.h (+4/-2) src/service.c (+359/-27) src/service.h (+6/-1) |
To merge this branch: | bzr merge lp:~charlesk/indicator-datetime/lp-1233176 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
PS Jenkins bot (community) | continuous-integration | Approve on 2013-10-17 | |
Ted Gould (community) | 2013-10-09 | Approve on 2013-10-17 | |
Review via email:
|
Description of the change
== Changes to planner-eds:
The get-appointments GTask has a new task subtype for pulling an ECalComponent's uris asynchronously.
When get_appointments() is called, create one GTask. We add subtasks to it for each client we know of for calling e_cal_client_
== Testing changes:
Make "planner" a property in IndicatorDateti
Add a mechanism for testing snap decisions without an EDS backend.
== Service changes:
Every time the appointment list changes, walk through it to find the alarm that will occur the soonest. Set a timer to wake up at that time. When the timer is reached, pop up a snap decision for each alarm set to that time. If the user clicks "OK", dispatch the URL associated with that alarm.
Made the appointment menuitems clickable, they now dispatch the appointment's URL.
Ted Gould (ted) wrote : | # |
I'm worried a bit about the alarm implementation, it seems like just checking for alarms every minute is a not as eloquent as we can be. We know when the next alarm is, we should wait that amount of time.
I haven't seen the final designs here, but I'm a bit surprised that we're launching the app when the alarm goes off. This will cause a focus change. Which means that you can potentially have your work interrupted by an alarm. It seems to me that there should be a notification with the option to ignore or open the URL.
Charles Kerr (charlesk) wrote : | # |
> We know when the next alarm is, we should wait that amount of time.
That's a great point. Fixed in r271 - r272
> I'm a bit surprised that we're launching the app when the alarm goes off.
What we planned in the meeting was keeping indicator-datetime as much of a pass-through as possible wrt understanding what's getting dispatched. What do you suggest we do here?
PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:274
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild:
http://
Nekhelesh Ramananthan (nik90) wrote : | # |
> I'm a bit surprised that we're launching the app when the alarm goes off.
>
> What we planned in the meeting was keeping indicator-datetime as much of a
> pass-through as possible wrt understanding what's getting dispatched. What do
> you suggest we do here?
When an alarm is triggered, the indicator date-time should only create a snap decision as shown in https:/
The clock app is opened only when the user clicks on one of the alarms in the indicator-date-time
Matthew Paul Thomas (mpt) wrote : | # |
> When an alarm is triggered, the indicator date-time should only create a snap decision
I'm surprised that indicator-datetime is doing *anything* with alarms other than listing them. What if I install an alternative calendar app? What if I install a sleep app with an alarm that goes off within a half-hour window, such that indicator-datetime can't display its exact time in advance? What if we decide to redesign the status bar such that indicator-datetime is no longer used? None of that should affect whether alarms go off. That should be up to the app, not a menu that happens to (but doesn't inevitably) display upcoming alarms.
> as shown in https:/
We don't know your Gmail password. ;-)
Ted Gould (ted) wrote : | # |
On Mon, 2013-10-14 at 09:28 +0000, Matthew Paul Thomas wrote:
> > When an alarm is triggered, the indicator date-time should only
> create a snap decision
>
>
>
> I'm surprised that indicator-datetime is doing *anything* with alarms
> other than listing them. What if I install an alternative calendar
> app? What if I install a sleep app with an alarm that goes off within
> a half-hour window, such that indicator-datetime can't display its
> exact time in advance? What if we decide to redesign the status bar
> such that indicator-datetime is no longer used? None of that should
> affect whether alarms go off. That should be up to the app, not a menu
> that happens to (but doesn't inevitably) display upcoming alarms.
Apps are not allowed to run in the background, and we don't want them
to. What we're allowing is them to add events to a shared calendar, and
then having a service that looks at that shared calendar and prompts the
user if they want to act at that time. That service happens to be
indicator-datetime today as it already has to have that information to
display it in the indicator. There is no technical reason it has to be
indicator-datetime in the future, just a convenience for implementation
today. If the user does interact with the snap decision or click on the
item in the indicator at that time we are invoking the app to do what it
wishes.
Nekhelesh Ramananthan (nik90) wrote : | # |
@mpt, the indicator date-time is the only one monitoring the EDS service. Any application that creates an alarm will save it to the EDS backend which the date-time indicator will then pick up. In the Ubuntu Touch, the clock app and the calendar are the 2 apps which do this at the moment. So it doesn't matter if the indicator date-time design is changed, it will still continue to monitor the EDS and trigger the snap decision when appropriate.
> > When an alarm is triggered, the indicator date-time should only create a
> snap decision
>
> I'm surprised that indicator-datetime is doing *anything* with alarms other
> than listing them. What if I install an alternative calendar app? What if I
> install a sleep app with an alarm that goes off within a half-hour window,
> such that indicator-datetime can't display its exact time in advance? What if
> we decide to redesign the status bar such that indicator-datetime is no longer
> used? None of that should affect whether alarms go off. That should be up to
> the app, not a menu that happens to (but doesn't inevitably) display upcoming
> alarms.
>
Ooops sry, didnt realise that..The mockup given to use by the designers can be seen at http://
> > as shown in https:/
> We don't know your Gmail password. ;-)
Nekhelesh Ramananthan (nik90) wrote : | # |
Charles can we get this in asap before the freeze. This is critical to alarm functionality.
Charles Kerr (charlesk) wrote : | # |
So after several iterations:
1. Single-action snap decisions apparently aren't supported by the Unity notification server, so they never appear.
2. Zero-action notifications do show up; however, the expiration period isn't supported and so it unconditionally vanishes after a few seconds whether the user clicks it or not.
So, for this iteration I've gone with a two-button popup, "OK" and "Cancel", where Cancel is a no-op and OK dispatches the appointment's URL.
PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:287
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild:
http://
- 288. By Charles Kerr on 2013-10-17
-
change ok/cancel buttons to the slightly-
more-informativ e show/dismiss - 289. By Charles Kerr on 2013-10-17
-
in the alarm snap decision, add x-canonical-
private- button- tint hint to highlight the 'Show' button
PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:289
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild:
http://
PASSED: Continuous integration, rev:270 jenkins. qa.ubuntu. com/job/ indicator- datetime- ci/109/ jenkins. qa.ubuntu. com/job/ indicator- datetime- saucy-amd64- ci/63 jenkins. qa.ubuntu. com/job/ indicator- datetime- saucy-armhf- ci/64 jenkins. qa.ubuntu. com/job/ indicator- datetime- saucy-armhf- ci/64/artifact/ work/output/ *zip*/output. zip
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild: 10.97.0. 26:8080/ job/indicator- datetime- ci/109/ rebuild
http://