Shipping KCall on our first release

[David Edmundson]

On Thu, May 5, 2011 at 1:56 PM, George Kiagiadakis
<kiagiadakis.george at gmail.com> wrote:
> On Thu, May 5, 2011 at 1:30 AM, David Edmundson
> <david at davidedmundson.co.uk> wrote:
>> Just seen a patch for Contact List adding start Audio/Video chat support.
>>
>> What is the opinion on shipping KCall on our first release (in 2-3
>> weeks)? We need to have a solid line of "this is part of the first
>> release" or "this is one of the experimental components that you
>> shouldn't package". I don't really want to send out other confusing
>> messages.
>>
>> It didn't come up at last weeks meeting, because I'm a massive idiot
>> and forgot to add it to the agenda. Right now it's NOT in my "Getting
>> Started"  wiki page, and it's also not in George G's "Guide for
>> packagers"
>>
>> Do the audio/video handlers work well enough to ship? I've not
>> tested/tried them in ages.
>>
>> In my opinion, I don't care if they're ugly or even if they crash as
>> long as they load. It's showing off all the stuff we (George K) has
>> done and it might help generate more interest in doing whatever else
>> is needed.
>>
>> Opinions? (Especially from George K)
>
> Well, let's start from the status. The current master of the call-ui
> is an ugly handler for StreamedMedia channels which works for audio
> calls (most of the time, given that you have the right gstreamer
> plugins installed) and crashes for video calls (unless you are calling
> the echo bot). All of the testing was done with gabble, so I don't
> know if it works or not with other protocols, but theoretically it
> should.
>
> Let's go to the future plans. First of all, StreamedMedia channels and
> the telepathy-farsight api for handling them are both awful. I've
> spent too much time in trying to understand how they work and writing
> code based on assumptions that were never correct. It turns out that
> doing calls is far more complicated than what one would expect by
> looking at the api and I am tired of trying to reinvent the wheel
> every time based on different assumptions. So, I don't have any plans
> on continuing to work with StreamedMedia and tp-farsight and I have
> already started porting to the Call.DRAFT interface and tp-farstream
> (which are way better). This means that nearly all of the code that is
> currently in the call-ui master branch is going to be replaced sooner
> or later.
>
> I appologize that my work on the call-ui has stopped since February.
> The main reason for that is that I am still confused about certain
> parts, especially on the UI part (how should it look and behave - it's
> not that simple, even if we have mockups -, whether it should use QML
> or not, etc...), and I know that Call.DRAFT and farstream are still
> going under changes, which may cause me to do extra work for no reason
> (I've heard that upstream people are working on some magic gstreamer
> elements that will do most of the work for me, for example). As a
> result, I am quite demotivated, to be honest.

No need to apologise, this thread wasn't meant to sound like I was
telling you off just working out where we are.
>
> Back to the topic, I am not against shipping the current call-ui if
> you people think it would be nice. However, I am not going to accept
> bug reports about it, given that this code is already deprecated. I
> can think of a hack that would probably solve the video crashes, so we
> might also be able to have some preview of video calls, but that's all
> I can do about it.
>
A ten minute quick hack or several painful hours?

What's (pleasantly) surprising is that I've heard from two people now
that it 'sort of works'.