Need a mechanism for specifying what happens when an ical menuitem is clicked

Bug #1426519 reported by Charles Kerr on 2015-02-27
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Ubuntu Calendar App
Undecided
Kunal Parmar
Ubuntu Clock App
Medium
Unassigned
indicator-datetime (Ubuntu)
Medium
Charles Kerr
Vivid
Undecided
Unassigned
qtorganizer5-eds (Ubuntu)
Undecided
Unassigned
Vivid
Undecided
Unassigned
reminders-app (Ubuntu)
Undecided
Unassigned

Bug Description

indicator-datetime needs a way to dispatch an arbitrary URL when a user clicks on an ical event menuitem.

In practice, datetime currently has clock-app hardwired for dispatching alarms (dispatch_url('appid://com.ubuntu.clock/clock/current-user-version')) and calendar-app for everything else (dispatch_url('appid://com.ubuntu.calendar/calendar/current-user-version')).

There are two use cases that can be supported by datetime handling the URL property <http://www.kanzaki.com/docs/ical/url.html>:

(1) Clicking on an alarm menuitem opens up clock-app to that specific alarm, rather than to clock-app's main page. Clock-app could specify the information it needs in the URL, then open the right page when passed that information later. indicator-datetime would act as a simple pass-through.

(2) non-calendar, non-alarm items such as from the reminders app as requested by mzanetti. The pattern would be the same as clock-app: Reminders would add whatever URL it wants, then datetime would act as a simple pass-through. This is preferable to adding more special cases to indicator-datetime.

See also related bug <https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1431384> which discusses abstracting out the icon shown in ical events' menuitems

Related branches

Charles Kerr (charlesk) wrote :

Adding stakeholders to also-affects for feedback/comments

Nekhelesh Ramananthan (nik90) wrote :

In the description, you mentioned that "Clock-app could specify the information it needs in the URL, then open the right page when passed that information later. indicator-datetime would act as a simple pass-through." Isn't it the other way around? The use case that I see is that when the user presses on an alarm shown in i-dt, i-dt then passes the necessary information that clock app requires to identify the alarm chosen by the user to open it.

I would still need to discuss with zsombor as to what information is required by the alarms API to open a specific alarm.

Charles Kerr (charlesk) on 2015-03-12
summary: - i-dt should support ical's "url" property for launching related apps
+ Need a mechanism for specifying what happens when an ical menuitem is
+ clickced

nik90, what I mean is that the necessary information you're referring to would be encoded in the URL that is provided by clock-app (or by the alarm controls in ubuntu-ui-toollkit, depending on where that logic lives).

So I'd like to replace the current implentation ('url_dispatch("appid://com.ubuntu.calendar/calendar/current-user-version")') with something like 'url_dispatch(event.url)' where the url would be provided by clock/calendar/reminder and would read something like, say, 'appid://com.ubuntu.calendar/calendar/current-user-version?alarm=someAlarmId'

This would require clock-app (or the alarm controls) to add this code, but the advantage of this approach is it scales to future third-party apps as well as adding reminder to the current pool of clock & calendar.

description: updated
summary: Need a mechanism for specifying what happens when an ical menuitem is
- clickced
+ clicked
Changed in indicator-datetime (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in reminders-app (Ubuntu):
status: New → Confirmed
Changed in ubuntu-calendar-app (Ubuntu):
status: New → Confirmed
no longer affects: ubuntu-calendar-app (Ubuntu)
Changed in ubuntu-calendar-app:
milestone: none → 2015-04-02
assignee: nobody → Kunal Parmar (pkunal-parmar)
Changed in ubuntu-calendar-app:
status: New → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qtorganizer5-eds - 0.1.1+15.04.20150508.2-0ubuntu1

---------------
qtorganizer5-eds (0.1.1+15.04.20150508.2-0ubuntu1) vivid; urgency=medium

  [ CI Train Bot ]
  * New rebuild forced.

  [ Renato Araujo Oliveira Filho ]
  * Added a new extra metadata property in collection (read-only
    property). (LP: #1347836)
  * Avoid filter or sort results if not necessary.
  * Implemented support for extended details. (LP: #1426519)
  * Optimize query by filtering collections related with the current
    query.
  * Removed missing debug.
  * Revert wrong commit.
  * Save a trigger for reminders with with secondsBeforeStart equals 0.
    (LP: #1440878)

 -- CI Train Bot <email address hidden> Fri, 08 May 2015 20:01:44 +0000

Changed in qtorganizer5-eds (Ubuntu):
status: New → Fix Released
Changed in ubuntu-clock-app:
importance: Undecided → Medium
status: New → Triaged

Fix committed into lp:ubuntu-calendar-app at revision 697, scheduled for release in ubuntu-calendar-app, milestone rtm14

Changed in ubuntu-calendar-app:
status: In Progress → Fix Committed
Changed in ubuntu-clock-app:
milestone: none → 3.x.backlog
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in indicator-datetime (Ubuntu Vivid):
status: New → Confirmed
Changed in qtorganizer5-eds (Ubuntu Vivid):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers