Summary: | Call needs to be able to indicate to the UI that starting to stream has failed for some reason | ||
---|---|---|---|
Product: | Telepathy | Reporter: | Sjoerd Simons <sjoerd> |
Component: | tp-spec | Assignee: | Telepathy bugs list <telepathy-bugs> |
Status: | RESOLVED DUPLICATE | QA Contact: | Telepathy bugs list <telepathy-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | olivier.crete |
Version: | unspecified | Keywords: | patch |
Hardware: | Other | ||
OS: | All | ||
URL: | http://git.collabora.co.uk/?p=user/jonny/telepathy-spec.git;a=shortlog;h=refs/heads/stream-send-failed | ||
Whiteboard: | Call | ||
i915 platform: | i915 features: |
Description
Sjoerd Simons
2010-06-23 06:34:36 UTC
e.g. Content.Remove( Content_Removal_Reason_Error, "ofdT.Error.DeviceBusy", "The 'Logitech, Inc. QuickCam Pro 9000' webcam is busy so could not be started") This is fine, no? (In reply to comment #1) > This is fine, no? It's not, I misread. Here is a branch to fix this: http://git.collabora.co.uk/?p=user/jonny/telepathy-spec.git;a=shortlog;h=refs/heads/stream-send-failed Adding a DeviceBusy error is probably fine too (I guess most CMs will not care why they can't send). Also, I must admit that using the same method indicate the user's desire to start/stop sending and the streaming implementation's ability to do it seems wrong to me. Using the SetStreaming both as an indication that the user wants to send and for the streaming layer to fail seems wrong and racy. Seems more sensible to have a seperate option on the Media interface for the stream layer to indicat e its state See further comments in bug #28707 I agree this should be split from SetSending .. the pending modes for SetSending don'T make so much sense imho.. all solved on bug #28693 *** This bug has been marked as a duplicate of bug 28707 *** |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.