After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 629902 - New call UI
New call UI
Status: RESOLVED FIXED
Product: empathy
Classification: Core
Component: VoIP
2.29.x
Other Linux
: Normal enhancement
: 3.4
Assigned To: empathy-maint
: 643801 (view as bug list)
Depends on: 580794 582442 590048 599167 611789 618567 623348 652998 654230 655884 656150 656268
Blocks: 599168 659683 661713
 
 
Reported: 2010-09-17 08:22 UTC by Guillaume Desmottes
Modified: 2012-03-28 15:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
first iteration of some wireframes for emapthy video chat (538.79 KB, application/pdf)
2010-10-20 17:54 UTC, Nick Richards
  Details
second iteration of the wireframes (534.22 KB, application/pdf)
2010-10-23 18:17 UTC, Nick Richards
  Details
third iteration of the wireframes (605.60 KB, application/pdf)
2011-08-22 16:44 UTC, Nick Richards
  Details
always build empathy-call (5.82 KB, patch)
2012-02-21 14:51 UTC, Guillaume Desmottes
accepted-commit_now Details | Review
Stop approve StreamedMedia channels (6.46 KB, patch)
2012-02-21 14:52 UTC, Guillaume Desmottes
none Details | Review
Drop empathy-av (239.99 KB, patch)
2012-02-21 14:52 UTC, Guillaume Desmottes
none Details | Review
Stop requesting StreamedMedia channels (3.69 KB, patch)
2012-02-21 14:53 UTC, Guillaume Desmottes
none Details | Review

Description Guillaume Desmottes 2010-09-17 08:22:01 UTC
For 3.0 we'd like to create a new audio/video UI.

Requierements:
- Keep the same features as the current one
- Use the new Call API: http://telepathy.freedesktop.org/spec/Channel_Type_Call.html
- Muji support (bug #599168) but the first version could be 1-1 only as a first step

Ideally, it would be cool if it allows us to fix some other bugs in the process (maybe not in the first iteration)
- In fullscreen mode, display our preview on top of the remote video (bug #582442)
- Alllow to change audio input (bug #590048)
- Allow to change video input (bug #599167)
- Be able to record calls (bug #593605)
- Support to "hold on" (bug #623348)
Comment 1 Guillaume Desmottes 2010-09-17 08:44:32 UTC
(In reply to comment #0)
> - Use the new Call API:
> http://telepathy.freedesktop.org/spec/Channel_Type_Call.html

I opened bug #629903 regarding Call support so we can use this bug to focus on the UI part.

Also, we don't have to wait that Call is undrafted. As this new UI will be a new channel handler, we can keep the current UI and the right one will be used depending of the type of the channel (StreamedMedia or Call). yeah MC!
Comment 2 Nick Richards 2010-10-20 17:54:47 UTC
Created attachment 172859 [details]
first iteration of some wireframes for emapthy video chat

A first iteration of a design for this sort of thing. Still todo:
* audio only calls. 
* Possibly some more settings integration. 
* The window menu for the video chat window. 
* Switch video and audio sources
* Call recording
Comment 3 Guillaume Desmottes 2010-10-21 15:03:31 UTC
Hi Nick. Thanks a lot, this looks like a really good start.
I have a few questions though:

• You moved the dialpad to the toolbar which is fine, but the current UI has more pages in the sidebar: 
∘ audio input: I guess that's replaced by the microphone in the bottom toolbar?
∘ video input: to tweak the video we send
∘ details:  display debug info
Maybe they could be display using the view menu or something? They are not so important so that's fine if they are less accessible.

• Page 4, 1.0 : Isn't the 'Disable Camera' button redudant with the other camera in the bottom toolbar?
• Swap Camera should probably be "Switch Camera" if there are more than one cam, as it's not guarantee to have exactly 2 cams.
• We should have a way to invite people to a multi party call
Comment 4 Nick Richards 2010-10-21 17:08:39 UTC
Video input and debug stuff will be in the menu if at all. As I mentioned above those menus are still todo. Simple audio input stuff would be with the mic more complicated setup would need a more complicated setup. I certainly want to think a little more on multiple microphones, speakers etc.

Disable camera shouldn't be there on you, correct. This was part of the stuff for managing other people. I'll remove it.

I'll do the swap/switch transition and add information on the rotation there.

Ah, the magic of a multi-party call. I was trying to stay away from the call setup in the short term but there'll certainly be something in the menu. Would we be able to drag a contact onto the window to invite them as well?

I'll update the wireframes with these changes.
Comment 5 Guillaume Desmottes 2010-10-22 13:24:39 UTC
(In reply to comment #4)
> Ah, the magic of a multi-party call. I was trying to stay away from the call
> setup in the short term but there'll certainly be something in the menu. Would
> we be able to drag a contact onto the window to invite them as well?

Yeah that should be doable.
Comment 6 Nick Richards 2010-10-23 18:17:04 UTC
Created attachment 173087 [details]
second iteration of the wireframes

this should address most of the comments above and fixes the majority of the remaining todos. notifications would be good to improve, but not necessary for this to proceed.

I'm on holiday for the next week so responses will be a little slower than normal.
Comment 7 Guillaume Desmottes 2011-03-07 09:04:54 UTC
*** Bug 643801 has been marked as a duplicate of this bug. ***
Comment 8 Emilio Pozuelo Monfort 2011-07-11 10:39:33 UTC
Hey Nick,

I'm working on the Call UI and was wondering how to implement incoming calls (a way to accept/refuse an incoming call from an existing call window). Any chance you can update the mockups with that? Or put your thoughts in a comment if you're too busy :)
Comment 9 Emilio Pozuelo Monfort 2011-07-11 12:12:56 UTC
We also need to think of a way to show detailed connection statuses (see bug #618567). Perhaps "%status: %detailed_status", such as "Disconnected: unauthorized" or "Disconnected: call refused" ? I expect to mostly happen when a call fails (i.e. when disconnected).

Or maybe we can just put whatever string we want in the status bar, as long as it's understandable.
Comment 10 Guillaume Desmottes 2011-07-12 10:03:12 UTC
(In reply to comment #8)
> I'm working on the Call UI and was wondering how to implement incoming calls (a
> way to accept/refuse an incoming call from an existing call window). Any chance
> you can update the mockups with that? Or put your thoughts in a comment if
> you're too busy :)

A modal popup on the call window? They are not so terrible as they use to be in GNOME 2 and it would be clearer than a small icon becoming sensitive.
Comment 11 Nicolas Dufresne (ndufresne) 2011-07-20 17:19:57 UTC
Some additions, in normal and group calls it would be nice to be able to start a private chat with the target. I was thinking of one more item in the right click menu.

Also, there is no mention of main video background for space not covered by video. Currently, the background behind the video window is grey which is not that nice looking, I think it could be changed to black, like in totem.
Comment 12 Olivier Crête 2011-07-20 19:03:32 UTC
Some notes about the mockup:

The pause symbol for Hold is not clear to me, I would use the word "Hold".

It's impossible to not support DTMF, farsight will send DTMF as audio if DTMF events are not supported.

Why are the audio input and output volumes in separate places ?

Also, in the assets to draw, we'll need a "hold" image that can be sent to the other side if we stop sending video to a protocol that doesn't support that natively. This way, we can make sure that a call can always be held and allow multiple calls at the same time.

Also, we may want something in the desktop shell to indicate to the user that he is currently in an active call (as a privacy thing).
Comment 13 Olivier Crête 2011-07-20 21:10:18 UTC
Another missing thing is that we may want to integrate text chat with the video chat in the same UI. Many protocols actually allow video and text chat using the same group.
Comment 14 Emilio Pozuelo Monfort 2011-07-21 08:13:49 UTC
(In reply to comment #12)
> It's impossible to not support DTMF, farsight will send DTMF as audio if DTMF
> events are not supported.

A CM may not implement the Hold interface though. Empathy only makes the dialpad in the call window sensitive if the given CM implements it.
Comment 15 Emilio Pozuelo Monfort 2011-07-21 15:50:16 UTC
Nick, I see the remote video (not the local preview) also has an "i" button. What options should that button contain?
Comment 16 Emilio Pozuelo Monfort 2011-07-26 09:31:24 UTC
(In reply to comment #3)
> • You moved the dialpad to the toolbar which is fine, but the current UI has
> more pages in the sidebar: 
> ∘ audio input: I guess that's replaced by the microphone in the bottom toolbar?
> ∘ video input: to tweak the video we send

These two should go to a new tab in the preferences as per page 14 of the wireframes, right? We can change the contrast/brightness/gamma at the moment from "Video input", maybe we should add that to the preferences somehow?

> ∘ details:  display debug info
> Maybe they could be display using the view menu or something? They are not so
> important so that's fine if they are less accessible.

We need to think of a way to show this, if we want to show it at all.
Comment 17 Emilio Pozuelo Monfort 2011-08-01 16:56:16 UTC
There is the bottom toolbar with some buttons, and there's also a statusbar with "Calling...", "Foo is not answering", "Call refused". I wonder what should we do with the toolbar while the statusbar is shown. Should we ever show both at the same time? Or should we hide the toolbar while the statusbar is shown?
Comment 18 Nick Richards 2011-08-02 15:49:14 UTC
Currently one replaces the other. They can't be shown at the same time.
Comment 19 Emilio Pozuelo Monfort 2011-08-03 09:12:55 UTC
The main Empathy window has Help->Debug. We should probably do the same in the call window, instead of Help->Call log, which can be confused with History.

Also, any reason for Fullscreen to be in Call and not in View? Other than 'View would only have one item' :-)
Comment 20 Nick Richards 2011-08-03 17:22:50 UTC
Partly because it would lead to a single item menu which is super bad, but partly because it really is a call related option.

As for the string, I think Help -> Debug call would be better than either of the above, would that be OK?
Comment 21 Emilio Pozuelo Monfort 2011-08-04 07:53:28 UTC
(In reply to comment #20)
> As for the string, I think Help -> Debug call would be better than either of
> the above, would that be OK?

Help->Debug is what I said above, and yes, it would be OK :-)
I'll use that.
Comment 22 Guillaume Desmottes 2011-08-19 09:41:49 UTC
(In reply to comment #20)
> Partly because it would lead to a single item menu which is super bad, but
> partly because it really is a call related option.

Atm that's the only item in the 'Call' menu.
Comment 23 Nick Richards 2011-08-22 16:43:51 UTC
Updated wireframes:

http://nickr.org/linux/wireframes/empathy-video-chat-wireframes.pdf

These cover a number of other bugs as well now, but they're still broadly call focused. I am minded to move the full screen toggle onto the toolbar full time, since in real life there's plenty of space on all screens and it has to be there for full screen anyway. This means we can lose the call menu. If others agree I'll do an update of the wireframes to show that but I wanted to get something out quickly.
Comment 24 Nick Richards 2011-08-22 16:44:22 UTC
Created attachment 194388 [details]
third iteration of the wireframes
Comment 25 Guillaume Desmottes 2011-08-23 08:40:57 UTC
(In reply to comment #23)
> I am minded to move the full screen toggle onto the toolbar full time,
> since in real life there's plenty of space on all screens and it has to be
> there for full screen anyway. This means we can lose the call menu. If others
> agree I'll do an update of the wireframes to show that but I wanted to get
> something out quickly.

Sounds like a good idea to me. I don't really like it in the call menu atm.
Comment 26 Olivier Crête 2011-08-26 14:05:07 UTC
Any reason you don't hold the current call when answering a second call? And I still think we should investigate integrating the chat and call uis into a single window.
Comment 27 Nick Richards 2011-08-26 15:00:28 UTC
(In reply to comment #26)
> Any reason you don't hold the current call when answering a second call? And I
> still think we should investigate integrating the chat and call uis into a
> single window.

Current technical limitations. My initial design was for an integrated call and chat window but I was asked to keep it separate for now. However the design can easily be integrated into a future new chat window, from a design perspective it's pretty componentised. 

As for call holding, there's a partly technical, partly design reason. I don't want to hold the call without the users permission. However I would very much like to be able to put a call on hold whilst answering another - however we can currently only have one concurrent call so when that's fixed we can add that.
Comment 28 Olivier Crête 2011-08-26 15:07:00 UTC
The technical bit about holding calls is relatively easy, that's what we've been doing in Maemo 5 and 6. But I agree that we should have a single active call. Maybe there shuold be a "hold active call and answer" button or something instead of "end active call and answer new one". But then the UI probably needs to reflect the held call so the user can end it. That's how cell phones seem to work.
Comment 29 Nick Richards 2011-08-26 15:22:12 UTC
Having worked on a couple of GSM call UIs I can say that they are annoying to design ;-)

"Hold call and answer" is certainly Sjoerd's favoured option. I'll have a think and see where we could fit a held call into the UI, especially in some of the worst case multi party calls.
Comment 30 Emilio Pozuelo Monfort 2011-09-01 12:05:50 UTC
We've implemented a floating toolbar, the wireframes should show that :-)

It's possible in some protocols to have a call fail because you don't have enough credit. We should have a place to show such an error with an optional link/button to buy some credit.
Comment 31 Guillaume Desmottes 2011-09-01 12:51:57 UTC
(In reply to comment #30)
> It's possible in some protocols to have a call fail because you don't have
> enough credit. We should have a place to show such an error with an optional
> link/button to buy some credit.

I think that's bug #618567 we should do a better job at error reporting.
Comment 32 Guillaume Desmottes 2012-02-21 13:41:04 UTC
Removing bug #618567 bug #623348 and bug #652998 as dependencies. We can fix that later. The Call1 branch has been merged to master so all we still have to do is to make empathy-call the new default. :)
Comment 33 Guillaume Desmottes 2012-02-21 14:51:46 UTC
Created attachment 208127 [details] [review]
always build empathy-call
Comment 34 Guillaume Desmottes 2012-02-21 14:52:38 UTC
Created attachment 208128 [details] [review]
Stop approve StreamedMedia channels
Comment 35 Guillaume Desmottes 2012-02-21 14:52:51 UTC
Created attachment 208129 [details] [review]
Drop empathy-av

So long and thanks for all the calling...
Comment 36 Guillaume Desmottes 2012-02-21 14:53:26 UTC
Created attachment 208130 [details] [review]
Stop requesting StreamedMedia channels
Comment 37 Will Thompson 2012-02-21 14:55:23 UTC
Review of attachment 208127 [details] [review]:

++
Comment 38 Guillaume Desmottes 2012-02-21 15:36:57 UTC
Merged to master.  Congratulations to everyone involved in this huge work!
Comment 39 kxra 2012-03-28 15:52:37 UTC
Did this meet the original goals? 

These are be done (fuck yeah!): 

- In fullscreen mode, display our preview on top of the remote video (bug
#582442)
- Alllow to change audio input (bug #590048)
- Allow to change video input (bug #599167)
- Use the new Call API:
http://telepathy.freedesktop.org/spec/Channel_Type_Call.html
- Keep the same features as the current one

But these remain open: 
- Muji support (bug #599168) but the first version could be 1-1 only as a first
step
- Be able to record calls (bug #593605)
- Support to "hold on" (bug #623348)