Thoughts and planning about KCall's future

[George Goldberg]

On 31 May 2010 20:13, George Kiagiadakis <kiagiadakis.george at gmail.com> wrote:
> Hello list,

Hi George,

Good to see you back again. I can't wait to see what awesomeness is in
store for KCall this summer.

Unfortunately I'm in the middle of my exams at the moment (2 weeks and
1 day to go, I'm not counting, honest ;)) so I can't give you a
detailed response, but here's just a quick reaction.

>
> Summer has come and I finally have again some time and willingness to
> do some more work on kde-telepathy. I am probably going to work on
> kcall again, but the problem is that I have no good plan of how things
> should be in kde-telepathy and what direction I should follow on my
> design. So, I am starting this thread to dump my thoughts and discuss
> some things that still trouble me.
>
> What we have now:
> KCall currently consists of 3 applications. A contact list, an
> approver for the incoming calls and a call handler application (which
> shows the window with the video, controls, etc). The handler uses the
> StreamedMedia channel interface for handling calls,
> telepathy-farsight, farsight2 and gstreamer for the actual streaming.
> It's user interface is quite ugly and unusable for end users imho, so
> that needs some significant work.
>
> Thoughts for the future:
> First of all, the handler should eventually be changed to support the
> new Call.DRAFT interface. I am not really interested in maintaining
> the StreamedMedia interface, since it's broken by design and makes
> things very difficult to code. Gabble already supports Call.DRAFT, and
> I think that's enough for now; other CMs will follow as soon as it's
> stable.

Agreed

> Second, farsight2 and gstreamer will remain (they are the best
> solution available for this purpose), but I am thinking to provide my
> own implementation of telepathy-farsight, since telepathy-farsight has
> many things I don't like (ugly api that doesn't behave nicely, no
> Call.DRAFT support yet, extra build-time and runtime dependency on
> telepathy-glib for no good reason).

Sounds cool. Talk to Tester in #telepathy before you code any of this
though, as I remember him talking about the possibility of doing this
a few months ago.

> Third, for better integration with
> the rest of kde, it should be made working flawlessly with pulseaudio,
> as we agreed on the multimedia meeting in Randa last week. This is not
> much work, given that it can already work with pulseaudio, thanks to
> gstreamer, if "Autodetect" is chosen in the device settings, but I am
> thinking of reworking a bit the device configuration dialog so that it
> doesn't confuse the users too much.

Sounds cool - I know nothing about this stuff :p

>
> Regarding the user interface, I think the contact list is useless,
> since we are going to have a global contact list for kde (right?) and

Yup, the KCall contact list might be handy for testing, since it
doesn't abstract away telepathy contacts too much, but the user-facing
future is in a shared contact widget coming from the ui dario is
working on atm.

> a question remains about what to do with the approver (i.e. should we
> have a separate approver application for calls? should we have some
> daemon approving all kinds of channels? something else? we had
> discussed that last year with grundleborg and we both agreed to leave
> that for later).

I'm in favour of continuing to leave this to later, just for  a couple
of weeks :p
This has been discussed a lot in the Gnome camp, and I really think we
should find out their experiences and ideas before diving in to this.

>
> The most basic question though is what to do with the user interface
> of the call handler. The problem is that telepathy supports many
> different use cases for audio/video conference through the same
> interface, but on the GUI side they are significantly different and I
> think they cannot be handled in the same way.
>
> * One simple use case is the typical case of a text chat between two
> persons that can be promoted to have audio and/or video (like in msn
> messenger), or the opposite case of an audio/video call between two
> persons that can be promoted to have a text chat as well (like skype).
> Many people like the idea of having audio/video widgets inside the
> text chat UI for this purpose. I had received many comments about this
> last year on my blog and on irc, where people asked me if it would be
> possible to integrate kcall with the kopete chat and have them in one
> window.
>
> * Another use case is the case of an audio/video conference between
> many people (i.e. more than 2). Although this is not yet technically
> possible, afaik there is an ongoing effort to support this on the
> jabber protocol and the new telepathy Call interface has been designed
> to make this easier to implement (because with the old StreamedMedia
> interface it was almost - if not completely - impossible). In this
> case, we need an interface that will take much space, with multiple
> video widgets arranged somehow (ideas for that?), and I don't think
> this fits in the chat UI.
>
> * The Call interface theoretically can have more contents than just
> audio and video, so some CM in the future may support even more
> workflows. For example, one could have audio, video and slideshow
> contents, for making a presentation live over the internet.
>
> All scenarios have their own design problems. The first scenario is
> easier to implement on the UI, but it is not so easy to have the same
> application handle both channels (but it's not impossible). The second
> scenario is a nightmare to implement on the UI, because you can't know
> the exact number of video widgets at design time, but it's easier to
> handle the new channel in a separate call-oriented application. The
> third use case is hypothetical, but I think if we ever have something
> like this, we need yet another UI for it... Obviously, one could say
> that the best solution is to have 2 - 3 separate UI applications, one
> for each use case. However, when the channel is created, there is no
> way to know which one of them to use to handle the channel. Maybe it
> could work if we have all of them on the chat UI and let it
> dynamically change layout when new participants and contents enter or
> leave, but I am not sure how it should look or behave.

Argh, can't really comment on this because it's too complicated to
think about the night before an exam :)
Seriously though, I think this is going to need extensive discussion,
and input from KDE's usability experts and designers. Until that takes
place, I think the best approach is to focus on making the various
channel-type components as modular as possible so we can easily plug
them together in whatever way the designers/usability people see fit
(and possibly in different ways in some special purpose app, e.g.
videoconferencing).

>
> So, I would appreciate some feedback on all of this, especially on the
> call UI problem, so that I have some general direction on how to
> proceed. Obviously the call UI is not something that will be
> implemented so soon, as the chat UI is not even written yet, and also
> we may want to have a stable kde-telepathy release without audio/video
> first, before adding new features, but it would be nice to have a plan
> from now. Currently I am mostly interested in converting existing code
> to work with the Call.DRAFT interface, before it becomes stable, so
> that I have a chance to find possible problems in its design and make
> sure that it will rock when it becomes stable! :)

Sounds awesome. Keep up the good work :)

George