MessagingMenuTelepathy

Differences between revisions 1 and 2
⇤ ← Revision 1 as of 2010-05-03 13:25:03 →
Size: 2627
Editor: cpe-065-190-158-029
Comment:
← Revision 2 as of 2010-05-18 19:22:05 → ⇥
Size: 5311
Editor: cpe-065-190-158-029
Comment:
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. See also CategorySpec for examples. Provide a simple desktop service that provides an interface between telepathy and the messaging menu.
Line 14: Line 14:
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.		 There should be no end user facing changes, this project is simply provide feature parity with what was included in Karmic and Lucid.
Line 20: Line 18:
This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. In Karmic and Lucid, we shipped a pretty heavy patch to empathy adding messaging menu support. This patch is pretty hard to maintain as is and would be much better suited as a service that runs independent of empathy. The ability to run this outside of empathy is a new feature of telepathy, that will make this much more sustainable.
Line 22: Line 20:
== User stories == Also note upstream empathy is removing much of the code we patch to provide this functionality, which would be a significant investment to rework.
Line 26: Line 24:
== Design ==

You can have subsections that better describe specific parts of the issue.		 Telepathy has a new base class, TpSimpleApprover which can be used to create such an approver. However, it was just merged in last week so has had very minimal testing. There are also currently not any vala bindings, which shouldn't be hard to handle, just an unknown.
Line 32: Line 28:
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: Create a new desktop service (indicator-approver), which runs at login time. It will register with telepathy as an approver as well as with the messaging menu. Telepathy will send events to indicator-approver, which will add the event to the messaging menu.
Line 36: Line 32:
Should cover changes required to the UI, or specific UI that is required to implement this None
Line 40: Line 36:
Code changes should include an overview of what needs to change, and in some cases even the specific details. Remove the need for our massive patch to empathy.
Line 44: Line 40:
Include:
 * data migration, if any
 * redirects from old URLs to new ones, if any
 * how users will be pointed to the new way of doing things, if necessary.		 None
Line 51: Line 44:
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.		 Login to a Maverick desktop session, when there is an inbound chat, call, file transfer, etc, there should be an entry added to the messaging menu. When clicked, the event should be raised and cleared from the messaging menu.
Line 57: Line 48:
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. None
Line 61: Line 52:
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. === Notes ===
Empathy/Telepathy

Indicator applet : pretty intrusive patch want to move them to a new separate application
for maverick, for inbound call that require immediate attention, morph the applet into a window

Re implement the indicator as an approver.
Empathy is going to be modified to integrate better with mission control (~1 week),
which mean the applet can ask for the conversation to be open and Empathy will open it

Question : Can the applet be notified when the conversation is open so it can stop blinking (or if it fail)
A : All the approver get notified for opened and closed channel that need dispatching

Question : Is the logger an observer ? A : Yes

Question : Should the applet be an observer as well?
A : It may prove useful for channel that get automatically approved
For this use case it won't actually be needed

Cassidy : we now have easy API to implement approver, it will be binded in Python, JS, etc..
with GObject introspection
the binding API is not stable yet, will be for 3.0 probably
Example approver in java script
Examples code in tp-glib for approver

Seb128 want to talk about the bug reporting process, especially integration with apport.
Cassidy wrote code for that which get automatically the logs from telepathy and hand it to apport
the concern is for privacy, we could accidently upload private user info (password not included)

Question from ploum : Could we automatically remove the user info from the logs?
A : it will prove difficult, except if we want to have crazy regex everywhere,
also we may remove useful debug info

Maverick will probably have an option to only mark one file as private execpt of the whole bug report

There is a number of patches from ubuntu on the upstream bugzilla which got reviewed
by upstream and got no responses from ubuntu dev

It will make sense to merge the patch to disable the tray icon later, since there
will be other approvers such as gnome-shell who want it

Rob explain libfolks for metacontacts and why it's not in empathy or tp-glib directly
ubuntu? is coding a contact picker. Rob suggest them using libfolks
Libfolks aggregate data from different source, it need a writable source to know how to group contacts
More than one writable source may lead to synchronisation problems
http://telepathy.freedesktop.org/wiki/Folks

Return to the log: Question from seb128 : should we send the log every time ? Which components log should we send?
A : We need at least Empathy and mission-control and one of the connection manager log.
We could ask the user which account has failed so we know which CM log to send.

Question from seb128 : Is there anything during the unstable cycle we should be aware of? We should always use the newest version?
New major version of mission-control soon but should be ok.
Question : Will 5.5.X be stable for Gnome 3.0 ? Should ubuntu ship it?
It may be useful to receive feedback. We could have it in the PPA so we can test it, but usually we only put in the PPA version which is going to ship in the next ubuntu version.
-> Yes have it in ubuntu
 

ACTION: (kenvandine) apport hook to send logs in bug report, default set to not send log

Summary

Provide a simple desktop service that provides an interface between telepathy and the messaging menu.

Release Note

There should be no end user facing changes, this project is simply provide feature parity with what was included in Karmic and Lucid.

Rationale

In Karmic and Lucid, we shipped a pretty heavy patch to empathy adding messaging menu support. This patch is pretty hard to maintain as is and would be much better suited as a service that runs independent of empathy. The ability to run this outside of empathy is a new feature of telepathy, that will make this much more sustainable.

Also note upstream empathy is removing much of the code we patch to provide this functionality, which would be a significant investment to rework.

Assumptions

Telepathy has a new base class, TpSimpleApprover which can be used to create such an approver. However, it was just merged in last week so has had very minimal testing. There are also currently not any vala bindings, which shouldn't be hard to handle, just an unknown.

Implementation

Create a new desktop service (indicator-approver), which runs at login time. It will register with telepathy as an approver as well as with the messaging menu. Telepathy will send events to indicator-approver, which will add the event to the messaging menu.

UI Changes

None

Code Changes

Remove the need for our massive patch to empathy.

Migration

None

Test/Demo Plan

Login to a Maverick desktop session, when there is an inbound chat, call, file transfer, etc, there should be an entry added to the messaging menu. When clicked, the event should be raised and cleared from the messaging menu.

Unresolved issues

None

BoF agenda and discussion

Notes

Empathy/Telepathy

Indicator applet : pretty intrusive patch want to move them to a new separate application for maverick, for inbound call that require immediate attention, morph the applet into a window

Re implement the indicator as an approver. Empathy is going to be modified to integrate better with mission control (~1 week), which mean the applet can ask for the conversation to be open and Empathy will open it

Question : Can the applet be notified when the conversation is open so it can stop blinking (or if it fail) A : All the approver get notified for opened and closed channel that need dispatching

Question : Is the logger an observer ? A : Yes

Question : Should the applet be an observer as well? A : It may prove useful for channel that get automatically approved For this use case it won't actually be needed

Cassidy : we now have easy API to implement approver, it will be binded in Python, JS, etc.. with GObject introspection the binding API is not stable yet, will be for 3.0 probably Example approver in java script Examples code in tp-glib for approver

Seb128 want to talk about the bug reporting process, especially integration with apport. Cassidy wrote code for that which get automatically the logs from telepathy and hand it to apport the concern is for privacy, we could accidently upload private user info (password not included)

Question from ploum : Could we automatically remove the user info from the logs? A : it will prove difficult, except if we want to have crazy regex everywhere, also we may remove useful debug info

Maverick will probably have an option to only mark one file as private execpt of the whole bug report

There is a number of patches from ubuntu on the upstream bugzilla which got reviewed by upstream and got no responses from ubuntu dev

It will make sense to merge the patch to disable the tray icon later, since there will be other approvers such as gnome-shell who want it

Rob explain libfolks for metacontacts and why it's not in empathy or tp-glib directly ubuntu? is coding a contact picker. Rob suggest them using libfolks Libfolks aggregate data from different source, it need a writable source to know how to group contacts More than one writable source may lead to synchronisation problems http://telepathy.freedesktop.org/wiki/Folks

Return to the log: Question from seb128 : should we send the log every time ? Which components log should we send? A : We need at least Empathy and mission-control and one of the connection manager log. We could ask the user which account has failed so we know which CM log to send.

Question from seb128 : Is there anything during the unstable cycle we should be aware of? We should always use the newest version? New major version of mission-control soon but should be ok. Question : Will 5.5.X be stable for Gnome 3.0 ? Should ubuntu ship it? It may be useful to receive feedback. We could have it in the PPA so we can test it, but usually we only put in the PPA version which is going to ship in the next ubuntu version. -> Yes have it in ubuntu

ACTION: (kenvandine) apport hook to send logs in bug report, default set to not send log

CategorySpec

DesktopTeam/Specs/Maverick/MessagingMenuTelepathy (last edited 2010-05-18 19:23:07 by cpe-065-190-158-029)