Skype codec SILK up its license for the free use
Skype is probably the score of VoIP (Voice over IP) as known
to date. The software has a codec for voice communication
which has evolved version after version. In the 4.0 release recently,
codec is called SILK, and several tests have shown that it possessed
many qualities. The publisher has decided to place her baby in
license for free.
SILK codec can now be used freely by all
third-party developers who wish to do so. Its use is
independent of Skype, or even any protocol
partner). SILK provides a bandwidth of between 6 and 40 Kb / s
depending on the quality of the connection. In the best case,
the sampling rate is 24 KHz, and laboratory tests
Dynablast have shown that the sound quality is often
high, even when the rate of packet loss increases to 10%.
Suddenly, the announcement of Skype is its small end and developers
can now see the details on the codec from this
page of the official site. Using SILK is done through a
SDK application to this address, indicating the information
following:
* Name
* Title
* Company
* Address
* Username Skype
* Email Address
* Phone
* Product Name
* Description of what account do SILK
* The geographical area in which the future product will be distributed
> permuter
2009/6/22, [email protected]
<[email protected]>:
> Send telepathy mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.freedesktop.org/mailman/listinfo/telepathy
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of telepathy digest..."
>
>
> Today's Topics:
>
> 1. Re: empathy busy/away status icons color (Nicol? Chieffo)
> 2. Re: empathy busy/away status icons color (Will Thompson)
> 3. Re: empathy busy/away status icons color (Xavier Claessens)
> 4. Re: discussion about empathy chat window (Matthew Paul Thomas)
> 5. ANNOUNCE: telepathy-mission-control 5.1.1 (Simon McVittie)
> 6. [Bug 16891] Telepathy should support OTR encryption
> ([email protected])
> 7. Re: Contact selector in Python (Olivier Le Thanh Duong)
> 8. Re: MC5 and my GSoC project for Banshee (Neil Loknath)
> 9. Re: MC5 and my GSoC project for Banshee (Will Thompson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 22 Jun 2009 13:32:23 +0200
> From: Nicol? Chieffo <[email protected]>
> Subject: Re: [Telepathy] empathy busy/away status icons color
> To: Alex Launi <[email protected]>
> Cc: [email protected], [email protected]
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> There are new icons for empathy (from gnome-icon-theme git), not yet
> committed to empathy
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 22 Jun 2009 12:36:10 +0100
> From: Will Thompson <[email protected]>
> Subject: Re: [Telepathy] empathy busy/away status icons color
> To: Telepathy <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="utf-8"
>
> Alex Launi wrote:
>> I think we also need a do not
>> disturb status that is neither busy nor away.
>
> NB. Busy and DND are synonymous for most protocols.
> --
> Will
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 260 bytes
> Desc: OpenPGP digital signature
> Url :
> http://lists.freedesktop.org/archives/telepathy/attachments/20090622/afd0f6fd/attachment-0001.pgp
>
> ------------------------------
>
> Message: 3
> Date: Mon, 22 Jun 2009 13:50:23 +0200
> From: Xavier Claessens <[email protected]>
> Subject: Re: [Telepathy] empathy busy/away status icons color
> To: [email protected]
> Cc: [email protected]
> Message-ID: <1245671423.32612.108.ca...@xclaesse-laptop>
> Content-Type: text/plain; charset="UTF-8"
>
> Le lundi 22 juin 2009 ? 12:39 +0200, Fernando a ?crit :
>> Hello.
>> I've started using empathy and I find quite disorienting the colors
>> that are used for the status icons.
>>
>> Every messaging client I know of (Pidgin, Gajim, Gtalk, MSN, Yahoo)
>> uses a red icon for the "busy" status, while the "away" status icon is
>> either yellow or some white/light color. This color scheme is pretty
>> much a de-facto standard in IM clients, imho.
>>
>> I think that empathy should follow this guidelines, as it's intended
>> to give support to these protocols. For me it's quite confusing and I
>> usually tend to think that someone is away when it's busy and busy
>> when it's away.
>>
>> I've attached a recolored version of the icons in this email, in svg.
>> What's your opinion?
>
> The rational here is that you have no chance to get a reply from an away
> contact, while busy contacts could reply but with some delay. So away is
> worst than busy, so away is red and busy orange. That's pretty intuitive
> IMO.
>
> Otoh, status icon should really be moved to the icon theme. That should
> not be empathy's problem. There is already a bug open about that IIRC.
>
> Xavier Claessens.
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 22 Jun 2009 12:26:06 +0100
> From: Matthew Paul Thomas <[email protected]>
> Subject: Re: [Telepathy] discussion about empathy chat window
> To: Telepathy <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nicol? Chieffo wrote on 21/06/09 14:56:
>>
>> How about this as the chat input GtkTextView?
>>...
>
> As others have mentioned, it's an odd mixture of insertion, call, view,
> and send actions.
>
> Separately, though, it has far too many words. It's a chat window, it
> should be small and elegant by default.
>
> Cheers
> - --
> Matthew Paul Thomas
> http://mpt.net.nz/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAko/akoACgkQ6PUxNfU6ecpwgACcDvoDsIomRpS1hfBV3zXGjzGX
> TDEAn2WbKVkiuNsApo8y27xSnVJemEbA
> =sspS
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 22 Jun 2009 14:37:03 +0100
> From: Simon McVittie <[email protected]>
> Subject: [Telepathy] ANNOUNCE: telepathy-mission-control 5.1.1
> To: [email protected]
> Cc: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="us-ascii"
>
> Last week Alberto tagged a MC bugfix release, 5.1.1. I've just uploaded it
> as
> the "Beautiful and Damned" release (now with a NEWS file entry, which wasn't
> included in the tag).
>
> Tarball:
> http://telepathy.freedesktop.org/releases/telepathy-mission-control/telepathy-mission-control-5.1.1.tar.gz
> Signature:
> http://telepathy.freedesktop.org/releases/telepathy-mission-control/telepathy-mission-control-5.1.1.tar.gz.asc
> The latest reviewed code is always available from:
> git://git.collabora.co.uk/git/telepathy-mission-control.git
> http://git.collabora.co.uk/?p=telepathy-mission-control.git (gitweb)
>
> Fixes:
>
> * fd.o #22169: allowed PreferredHandler to be empty when requesting a
> channel (smcv)
>
> * Updated code generation from telepathy-glib and followed the
> recommendations
> of telepathy-glib 0.7.6's NEWS, fixing some possible assertion
> failures (smcv)
>
> * Ensured that AccountValidityChanged will be emitted if an account is added
> in an already-valid state (smcv)
>
> * fd.o #21377: added support for 64-bit integers, doubles and object paths
> as
> CM parameters, did some work towards supporting bytes as CM parameters,
> and fixed serialization of large 32-bit unsigned integers and
> deserialization of integers of large magnitude (smcv)
>
> * fd.o #21299: prevented automatic reconnection after Name_In_Use error
> (smcv)
>
> * fd.o #22201: avoided rewriting accounts.cfg if nothing changed (smcv)
>
> * Ensured that the transport was reset when a Connection disconnected
> (mardy)
>
> Simon
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 155 bytes
> Desc: Digital signature
> Url :
> http://lists.freedesktop.org/archives/telepathy/attachments/20090622/099c458b/attachment-0001.pgp
>
> ------------------------------
>
> Message: 6
> Date: Mon, 22 Jun 2009 09:58:09 -0700 (PDT)
> From: [email protected]
> Subject: [Telepathy] [Bug 16891] Telepathy should support OTR
> encryption
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="UTF-8"
>
> http://bugs.freedesktop.org/show_bug.cgi?id=16891
>
>
> Arie Skliarouk <[email protected]> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |[email protected]
>
>
>
>
> --
> Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 22 Jun 2009 19:18:06 +0200
> From: Olivier Le Thanh Duong <[email protected]>
> Subject: Re: [Telepathy] Contact selector in Python
> To: [email protected]
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Jun 22, 2009 at 11:03 AM, Guillaume
> Desmottes<[email protected]> wrote:
>> Le samedi 20 juin 2009 ? 15:54 +0100, Alban Crequy a ?crit :
>>> ?Should someone do a proper Python module, and reuse
>>> it? Or is there a big picture I missed?
>>
>> I see some options here:
>>
>> A) Integrate it in telepathy-python. Probably not because it doesn't
>> depend on GTK+ and that's probably a sane choice.
> I think telepathy-python don't even depends directly on glib only
> indirectly via d-bus
> for the mainloop but you could theoretically ship it with qt mainloop only.
> So it's probably not a good idea.
>
>>
>> B) Make Empathy's contact chooser bindable and use it from Python. Good
>> from a good reuse pov but depend on libempathy(-gtk) sucks.
> The contact chooser IS binded in Python, the problem is that tp-glib
> isn't, so that
> once we have selected a contact you can't completely retrieve it in python.
>
> See the bug I opened about that
> http://bugzilla.gnome.org/show_bug.cgi?id=581751
>
> I don't know much about the way python bindings works but I'm
> wondering, since these
> are all d-bus objects wouldn't it be possible to recreate tp-python
> objects from the d-bus
> path and return that?
>
>> C) Give born to telepathy-gtk and bind it in Python. Probably the best
>> choice but no one is working on it atm (and that probably means we'll
>> need Python bindings of telepathy-glib as well).
> That sounds good as a long term plan but not really something we could
> use right now.
> Also would that mean we would drop the current telepathy-python?
>
>> D) Create yet another library. Doesn't sound like a good idea to me.
> Yes that look like a lot of extra works for just a class maybe that
> would be justified
> if we had a bunch of other widgets but right now I don't see anything
> really interesting apart from
> the contact selector.
>
> On the other hand if we all have a hard copy of Zhang's contact
> selector in each of our project
> and others projects start doing the same it may get messy. Take for
> example the EggTrayIcon
> which got copied around in a lot of gtk programs and the mess it was
> to get every program
> to update each time there was a bug fix.
>
>
> --
> Olivier L? Thanh Duong <[email protected]>
>
> Phone : +32485608639 Jabber: [email protected]
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 22 Jun 2009 11:41:52 -0600
> From: Neil Loknath <[email protected]>
> Subject: Re: [Telepathy] MC5 and my GSoC project for Banshee
> To: [email protected]
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
>> On Sun, 21 Jun 2009 at 22:14:18 -0600, Neil Loknath wrote:
>> > So, what disadvantages are there to sticking with the Requests and
>> > ContactCapabilities interfaces instead of using the new MC5 things?
>>
>> The problem is that you won't interact correctly with other clients:
>>
>> * SetSelfCapabilities, as you noticed, needs to be handled by one process
>> (MC)
>> ?to work properly
>>
>> * If you don't tell MC 5 that you're willing to handle a certain type of
>> tube,
>> ?it will decide the tube can't be handled, and close it as undispatchable
>>
>
> So, you're saying that if MC5 is not told, the Requests.NewChannels
> signal will not be raised when Requests.CreateChannel is called? If
> that is the case, will the Requests interface be hidden from public
> use?
>
>> * If another client could handle your tube (perhaps Banshee, RB and Amarok
>> will
>> ?eventually all support StreamTubes with service "daap"?) then Banshee
>> will
>> ?try to use an incoming tube that RB has already been given by MC, and
>> they'll
>> ?fight over it
>>
>> The solution to all these is to have some central process dispatch the
>> channels:
>>
>> * The current hack is that Empathy is that central process - have a look
>> at
>> ?Arnaud's work on VNC tubes. The tube handler (Vinagre) registers itself
>> with
>> ?Empathy, Empathy is the channel handler as far as MC 4 is concerned, and
>> ?Empathy passes the tube to Vinagre.
>>
>> * When Empathy is ported to MC 5, initially it will tell MC 5 that it
>> handles
>> ?every channel, then do dispatching internally; in particular, it'll
>> continue
>> ?to provide the current "EmpathyTubeHandler" hack, and Vinagre will work
>> ?identically.
>
> I think the hack is missing one feature that is very important to me:
> advertising that a contact provides a tube service before the tube is
> actually offered. That is why I am using SetSelfCapabilities. It lets
> me filter out contacts that can't participate in my tube service. (ie.
> contact is not running Banshee, Banshee is running but doesn't have my
> Telepathy extension installed, the Telepathy Extension was running,
> but isn't anymore, etc.)
>
> So, unless there is something that I'm missing, registering an object
> with dbus name org.gnome.Empathy.DTubeHandler.myservice does not
> actually advertise to other contacts that the service is there. ie.
> the ContactCapabilitiesChanged signal is not raised and
> GetContactCapabilities does not indicate that the service is there. Is
> there a workaround that would provide that functionality?
>
> Thanks for your help,
> Neil
>
>
> ------------------------------
>
> Message: 9
> Date: Mon, 22 Jun 2009 19:11:51 +0100
> From: Will Thompson <[email protected]>
> Subject: Re: [Telepathy] MC5 and my GSoC project for Banshee
> To: Telepathy <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="utf-8"
>
> Neil Loknath wrote:
>> So, you're saying that if MC5 is not told, the Requests.NewChannels
>> signal will not be raised when Requests.CreateChannel is called?
>
> No, it'll still fire. But MC5 catches NewChannels, and if it can't find
> an application to which to dispatch an incoming channel, it closes it.
>
>> I think the hack is missing one feature that is very important to me:
>> advertising that a contact provides a tube service before the tube is
>> actually offered. That is why I am using SetSelfCapabilities. It lets
>> me filter out contacts that can't participate in my tube service. (ie.
>> contact is not running Banshee, Banshee is running but doesn't have my
>> Telepathy extension installed, the Telepathy Extension was running,
>> but isn't anymore, etc.)
>>
>> So, unless there is something that I'm missing, registering an object
>> with dbus name org.gnome.Empathy.DTubeHandler.myservice does not
>> actually advertise to other contacts that the service is there. ie.
>> the ContactCapabilitiesChanged signal is not raised and
>> GetContactCapabilities does not indicate that the service is there. Is
>> there a workaround that would provide that functionality?
>
> Nope; the "workaround" is that Mission Control 5 will do this for you.
> :-) It will call SetSelfCapabilities() based on the types of channel
> installed/running clients can handle, keeping it up to date as clients
> open and exit if necessary.
>
> --
> Will
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 260 bytes
> Desc: OpenPGP digital signature
> Url :
> http://lists.freedesktop.org/archives/telepathy/attachments/20090622/3a0b7001/attachment-0001.pgp
>
> ------------------------------
>
> _______________________________________________
> telepathy mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/telepathy
>
>
> End of telepathy Digest, Vol 43, Issue 33
> *****************************************
>
_______________________________________________
telepathy mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/telepathy
