[Telepathy] telepathy Digest, Vol 43, Issue 33
Mouahed Nahali
mouhabuntu at gmail.com
Mon Jun 22 18:40:37 PDT 2009
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, telepathy-request at lists.freedesktop.org
<telepathy-request at lists.freedesktop.org>:
> Send telepathy mailing list submissions to
> telepathy at lists.freedesktop.org
>
> 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
> telepathy-request at lists.freedesktop.org
>
> You can reach the person managing the list at
> telepathy-owner at lists.freedesktop.org
>
> 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
> (bugzilla-daemon at freedesktop.org)
> 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 <nicolo.chieffo at gmail.com>
> Subject: Re: [Telepathy] empathy busy/away status icons color
> To: Alex Launi <alex.launi at gmail.com>
> Cc: ferkiwi+a at gmail.com, telepathy at lists.freedesktop.org
> Message-ID:
> <98391a7b0906220432v5d672e85s7e938e63a115029e at mail.gmail.com>
> 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 <will.thompson at collabora.co.uk>
> Subject: Re: [Telepathy] empathy busy/away status icons color
> To: Telepathy <telepathy at lists.freedesktop.org>
> Message-ID: <4A3F6CAA.8090600 at collabora.co.uk>
> 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 <xclaesse at gmail.com>
> Subject: Re: [Telepathy] empathy busy/away status icons color
> To: ferkiwi+a at gmail.com
> Cc: telepathy at lists.freedesktop.org
> Message-ID: <1245671423.32612.108.camel at 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 <mpt at canonical.com>
> Subject: Re: [Telepathy] discussion about empathy chat window
> To: Telepathy <telepathy at lists.freedesktop.org>
> Message-ID: <4A3F6A4E.1080606 at canonical.com>
> 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 <simon.mcvittie at collabora.co.uk>
> Subject: [Telepathy] ANNOUNCE: telepathy-mission-control 5.1.1
> To: telepathy at lists.freedesktop.org
> Cc: ftp-release at lists.freedesktop.org
> Message-ID: <20090622133703.GA31409 at carbon.pseudorandom.co.uk>
> 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: bugzilla-daemon at freedesktop.org
> Subject: [Telepathy] [Bug 16891] Telepathy should support OTR
> encryption
> To: telepathy at lists.freedesktop.org
> Message-ID: <20090622165809.2CCBA130016 at annarchy.freedesktop.org>
> Content-Type: text/plain; charset="UTF-8"
>
> http://bugs.freedesktop.org/show_bug.cgi?id=16891
>
>
> Arie Skliarouk <skliarie at gmail.com> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |skliarie at gmail.com
>
>
>
>
> --
> 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 <olivier at lethanh.be>
> Subject: Re: [Telepathy] Contact selector in Python
> To: telepathy at lists.freedesktop.org
> Message-ID:
> <9f171cf00906221018qbc35e77v847bc9ee9d95ec62 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Jun 22, 2009 at 11:03 AM, Guillaume
> Desmottes<guillaume.desmottes at collabora.co.uk> 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 <olivier at lethanh.be>
>
> Phone : +32485608639 Jabber: olethanh at gmail.com
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 22 Jun 2009 11:41:52 -0600
> From: Neil Loknath <neil.loknath at gmail.com>
> Subject: Re: [Telepathy] MC5 and my GSoC project for Banshee
> To: telepathy at lists.freedesktop.org
> Message-ID:
> <6176720c0906221041l4756a79mb85df3f48b850912 at mail.gmail.com>
> 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 <will.thompson at collabora.co.uk>
> Subject: Re: [Telepathy] MC5 and my GSoC project for Banshee
> To: Telepathy <telepathy at lists.freedesktop.org>
> Message-ID: <4A3FC967.4020805 at collabora.co.uk>
> 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
> telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
>
>
> End of telepathy Digest, Vol 43, Issue 33
> *****************************************
>
More information about the telepathy
mailing list