Re: [Telepathy] Telepathy Release process?

[Alexandr Akulich]

Hi Diane,

I think that it makes sense to ship the release through
freedesktop.org and copy it to the github.com project.
The first reason is that we do not release that frequently to ask
distributions to look at github.
The second reason is that freedesktop.org is still a preferred
platform in terms of freedom. "Github is a proprietary platform, so
someone can buy and close it."

My suggestion is to release all project presented at freedesktop.org
via freedesktop.org at the first place and via github.com as the
second place. I can help with both, but I develop only Qt side of
things. Maybe there is something like "maintainer-upload-release"
target in telepathy-idle? We have such one in telepathy-qt.

On Sat, Nov 4, 2017 at 12:31 AM, Diane Trout  wrote:
> On Fri, 2017-11-03 at 17:18 -0400, Olivier Crête wrote:
>> Hi,
>>
>> I believe the most active maintenance of Telepathy is now at
>>
>> https://github.com/TelepathyIM
>>
>> Olivier
>
>
> I believe so too...
>
> Should we have new releases go through freedesktop.org? or just make
> github releases, and convince distributions to start looking at the
> github repositories?
>
> Diane
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy 1.0 and moving to Github

[Alexandr Akulich]

Hello George,

On Mon, Oct 31, 2016 at 11:18 PM, George Barrett  wrote:

> On Sun, Oct 30, 2016 at 06:59:07PM +0200, George Kiagiadakis wrote:
> > 1) Where should we keep tickets? Right now they are also split between
> > bugzilla and github. No decision has been made yet. Our options seem
> > to be bugzilla, github and phabricator.freedesktop.org.
> >
> > -> github: most user friendly, very limited
> > -> bugzilla: less user friendly, more options, some basic ones are not
> > available though (they require admin access...); currently cluttered
> > with old & dead stuff
> > -> phabricator: even less user friendly (imho), but the most powerful
> > one
>
> My vote would be for keeping that stuff on the FD.O Bugzilla. I would
> argue that Bugzilla has an edge over GitHub in that the BZ workflow
> promotes patch nit-picking and a clean commit history:
>
>  * Individual patches are submitted instead of pull requests for
>branches.
>
I can not agree. You can fit a trivial change into an individual patch, but
it would be more clear and easier to review a branch with an implementation
of a new feature, rather than a single patch for that.
It is better when you *can* propose a commits series, than when you're
limited by a patch. (I would like to say "hello" to reviewboard here).
There is no problem to comment any line of code in any commit of a branch.
There is no problem to rebase your own branch and clear it before merging.
We didn't said any word about pull request.


>  * BZ has a great system for patch review
>
Oh, indeed? Let's start with any random feature. Can BZ expand a diff to
show you a ten more lines of code before the change?


>  * Bug discussions and patches share the same thread
>
 * There's no big "MERGE NOW" button to be tempted by mid-review (I'm
>guilty of this)
>
It is not a problem of github. You should be able to resist from clicking
on buttons. :)

 * Poor commit messages are understood as valid grounds to reject a
>patch

It is equally a valid point to reject a commit.

> * editing a patch is easier than rewriting branch history
No. Rewriting a branch is easier, if you use a proper tool (git rebase
--interactive; git add --patch at the very least).

>  * There's no argument over git merge vs git rebase, over a commit log
>full of merge commits or rewriting history
>

In Telepathy we have a very reasonable merge/rebase convension for years.

You're actually comparing a really bad github workflow vs an ideal BZ
workflow.
In fact, you can


> Particularly with a project with as many components as Telepathy, I feel
> like GitHub issues would be a definite step backward.
>
> I'd also recommend BZ over Phabricator, but admittedly this opinion is
> not particularly well informed. My previous impressions of it has been
> that it's in desperate need of a man page, not a good quality in a
> website. I wouldn't be the only one who is more comfortable with BZ.
> That said, I have no idea what additional features it provides; it may
> well be worth it for Killer Feature X.
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy 1.0 and moving to Github

[Alexandr Akulich]

Hi Daniel,

Our manpower is very limited, but IMO we need to polish the specification
and carefully test everything to make Tp 1.0 to be the best release, rather
than rush, declare release earlier and make the situation even worse.
Yet another point is Empathy. It was holding the 1.0 release back and now
it seems to be close to removed/abandoned. I don't think that Empathy with
Tp 1.0 support will be released in time for Debian.

On Mon, Oct 31, 2016 at 1:23 PM, Daniel Pocock  wrote:

>
>
> On 30/10/16 17:59, George Kiagiadakis wrote:
>
> > Therefore, the point is valid, so the new plan now is to finish
> > Telepathy 1.0 as soon as possible and then carry on with a clean spec
> > and codebase.
> >
>
> Has any target date been set for this?
>
> Is it intended to be part of the next Debian release?  If so, the freeze
> is coming soon, potentially 5 January 2017:
>
> https://wiki.debian.org/DebianStretch
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy 1.0 and moving to Github

[Alexandr Akulich]

Hello Gergely.

On Mon, Oct 31, 2016 at 11:46 AM, Gergely Polonkai <gerg...@polonkai.eu>
wrote:

> You can upload custom files as releases, and you can even do it from CI
> systems like Travis. Yet, I think releases should stay at fdo (although the
> CI could generate that one, too).
>
Indeed. Thanks!

>
> On Sun, Oct 30, 2016, 23:31 George Kiagiadakis <gkia...@tolabaki.gr>
> wrote:
>
>> On 10/31/2016 12:15 AM, Alexandr Akulich wrote:
>> > Hi George,
>> >
>> > thank you for the summarize. I have no time for a verbose answer, but
>> > would like to make some note.
>> >
>> > We can not use "Github releases" feature, because:
>> > 1) We need to prepare release in some special way. Namely, we generate
>> > documentation for release tarballs. Github archives contains only the
>> > tree snapshot from a tagged commit.
>> > 2) The archive directory name is project name + tag name. For
>> > TelepathyQt we have archive "telepathy-qt-0.9.7.tar.gz" with directory
>> > "telepathy-qt-telepathy-qt-0.9.7".
>> >
>> > I think we should use https://telepathy.freedesktop.org/releases/ , but
>> > I didn't checked yet if we can place sources of new components
>> > (TpQt-based CMs) there (probably we can do it without help from admins).
>> >
>>
>> Yes, releases should and will happen like before. There is no need for
>> admin access, we all have write permissions there.
>> ___
>> telepathy mailing list
>> telepathy@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/telepathy
>>
>
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy 1.0 and moving to Github

[Alexandr Akulich]

Hi George,

thank you for the summarize. I have no time for a verbose answer, but would
like to make some note.

We can not use "Github releases" feature, because:
1) We need to prepare release in some special way. Namely, we generate
documentation for release tarballs. Github archives contains only the tree
snapshot from a tagged commit.
2) The archive directory name is project name + tag name. For TelepathyQt
we have archive "telepathy-qt-0.9.7.tar.gz" with directory
"telepathy-qt-telepathy-qt-0.9.7".

I think we should use https://telepathy.freedesktop.org/releases/ , but I
didn't checked yet if we can place sources of new components (TpQt-based
CMs) there (probably we can do it without help from admins).
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] requestHandles method behaviour

[Alexandr Akulich]

On Tue, Sep 20, 2016 at 2:57 AM, Mateus Bellomo  wrote:
>> The identifier <-> handle map is not the "contact list". Under
>> "contact list" I mean contacts, which e.g. would be returned by
>> Connection.Interface.ContactList GetContactListAttributes().
>
> So in this case you could hold entries like (1,mateus2) and
> (2,mate...@test.sip5060.net) in the map that shouldn't be a problem, right?

Yes. Just a few extra bytes in memory.

> And if so, then you would have another way of getting the 'official' contact
> list (like [1] and [2]), right?
>
> [1]
> https://github.com/TelepathyQt/telepathy-nonsense/blob/master/connection.cc#L499
> [2]
> https://github.com/TelepathyQt/telepathy-morse/blob/master/connection.cpp#L661
>
You're right, there should be an "official" list and nonsense do it
right, but in Morse there are some Telegram-specific tricks and the
list is not filtered properly.
In Telegram in order to add someone to your contact list you need to
know their phone number. On the other side, you don't have to add
everyone "interesting" to you contacts, because you can access them
via Dialogs — a list of recent conversation.
Telepathy does not support conception of "Dialogs", so in Morse I have
to include such known contacts into Contact List, because it will be
very inconvenient to use the client otherwise.
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] requestHandles method behaviour

[Alexandr Akulich]

Morse and Nonsense both returns a handle list.

In case of Nonsense: type of the list is UniqueHandleMap with
operators and the used operator [] will return a new handle for each
new identifier.

https://github.com/TelepathyQt/telepathy-nonsense/blob/master/uniquehandlemap.cc#L32

The identifier <-> handle map is not the "contact list". Under
"contact list" I mean contacts, which e.g. would be returned by
Connection.Interface.ContactList GetContactListAttributes().

On Tue, Sep 20, 2016 at 2:28 AM, Mateus Bellomo  wrote:
> Thanks for the reply guys and sorry for the duplicated post =)
>
>> The thing is that ensureHandle() does (or at least should) NOT add the
>> identifier to the contact list.
>
> When you say list do you also refer to the map that I hold contacts
> identifiers and handles, or you refer just the actual list of contacts?
>
>> The RequestHandles method do exactly
>> one  thing: returns valid handle for identifier. Error "Invalid
>> Handle" should be returned if the given identifier does not identify a
>> valid entity of the given type.
>
> Looking at telepathy-nonsense [1] it returns the mapped handle for a
> existing contact identifier and I think it will return an empty List if the
> contact didn't exist.
> But in telepathy-morse [2] it adds the contact to the map if it didn't exist
> and then return the List.
>
> So in this case I should do like telepathy-nonsense?
>
>> I'm going to suggest it again: ask Empathy developers.
>
> Is there a specific list for that? I thought this was the correct list.
>
> [1]
> https://github.com/TelepathyQt/telepathy-nonsense/blob/master/connection.cc#L728
> [2]
> https://github.com/TelepathyQt/telepathy-morse/blob/master/connection.cpp#L635
>
> 2016-09-19 17:36 GMT-03:00 George Kiagiadakis :
>>
>> On 09/19/2016 08:59 PM, Mateus Bellomo wrote:
>> > Hello,
>> >
>> > I have implemented the requestSubscription() and requestHandles()
>> > methods at telepathy-resiprocate [1]. I'm using Empathy as a client and
>> > testing it I noticed that when I try to add a contact in the contact
>> > list, in the window that opens, the method requestHandle() is being
>> > called several times while the user is typing the contact to add. So
>> > several 'partial' contacts are being added to my map that holds my
>> > contact identifiers [2] [3] like this:
>> >
>> > mateus
>> > mateus2@
>> > mateus2@test.s
>> > mateus2@test.sip5060
>> > mate...@test.sip5060.net 
>> >
>> > I'm wondering if this behaviour should be expected from telepathy or
>> > it's just a bug.
>>
>> It doesn't seem to violate the spec, so I would say it's pretty fine for
>> a client to do that. It just needs a way to check if an identifier is a
>> valid contact or not and this is the best way to do it. Of course, it
>> may generate a lot of d-bus traffic, but I don't think that's causing
>> any serious problems.
>
>
>
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] requestHandles method behaviour

[Alexandr Akulich]

Hi Mateus,

The question is sounds similar to [1].

I replied personally to you, instead of to the list, so I will quote myself:

On Sun, Jun 5, 2016 at 1:42 AM, Alexandr Akulich
<akulichalexan...@gmail.com> wrote:
> Hi Mateus.
>
> I know about this behaviour. Empathy wants to get know if the typed
> contact is valid and exists. Telepathy have no such API, so Empathy
> has to workaround it via trying to get info about the contact by typed
> identifier, which (usually) triggers handle assignment, or results in
> "InvalidHandle" error.
>
> The thing is that ensureHandle() does (or at least should) NOT add the
> identifier to the contact list. The RequestHandles method do exactly
> one  thing: returns valid handle for identifier. Error "Invalid
> Handle" should be returned if the given identifier does not identify a
> valid entity of the given type.

On Sun, Jun 5, 2016 at 2:18 AM, Mateus Bellomo <mateusbell...@gmail.com> wrote:
> The problem is while I'm typing the identifier of a contact to add, the
> function requestHandles() is being called several times:
>
> Let's say I wan to add a contact mate...@ws.sip5060.net. While I'm typing,
> the function requestHandles() is being called at least 2 times before I hit
> enter so the contacts actually added would be (possibly):
>
> mateus2@w
> mate...@ws.sip5060.net
>
> In this case I have a wrong list after I hit enter because there could be a
> lot of contacts that don't even are a real contact.
>

On Sun, Jun 5, 2016 at 2:32 AM, Alexandr Akulich
<akulichalexan...@gmail.com> wrote:
> Empathy shows list of all known contacts. While you typing the
> identifier, empathy asks the CM: "is this contact valid?" CM answers:
> "yes, it's valid" and then Empathy adds the contact to the list. It's
> not the user-controllable "contact list", but something like list of
> contacts, referenced in current session.
>
> I would suggest to ask Empathy devs on this regard.
>
> IIRC KDE Telepathy works differently — it just doesn't check
> identifier while user typing.

I'm going to suggest it again: ask Empathy developers.

[1] https://lists.freedesktop.org/archives/telepathy/2016-June/006919.html

On Mon, Sep 19, 2016 at 10:59 PM, Mateus Bellomo
<mateusbell...@gmail.com> wrote:
> Hello,
>
> I have implemented the requestSubscription() and requestHandles() methods at
> telepathy-resiprocate [1]. I'm using Empathy as a client and testing it I
> noticed that when I try to add a contact in the contact list, in the window
> that opens, the method requestHandle() is being called several times while
> the user is typing the contact to add. So several 'partial' contacts are
> being added to my map that holds my contact identifiers [2] [3] like this:
>
> mateus
> mateus2@
> mateus2@test.s
> mateus2@test.sip5060
> mate...@test.sip5060.net
>
> I'm wondering if this behaviour should be expected from telepathy or it's
> just a bug.
>
> Any help would be greatly appreciated.
>
> Thanks!
>
>
> [1] https://github.com/resiprocate/resiprocate/tree/master/apps/telepathy
> [2]
> https://github.com/resiprocate/resiprocate/blob/master/apps/telepathy/Connection.hxx#L104
> [3]
> https://github.com/resiprocate/resiprocate/blob/master/apps/telepathy/Connection.hxx#L105
>
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] receiving text messages

[Alexandr Akulich]

Hi Mateus,

For message *receiving* you don't have to implement a method in
interface (because method is something to be called by a telepathy
client application). Instead, client listens for messageReceived
signal [1], which you should emit for every incoming message.

[1] 
https://telepathy.freedesktop.org/spec/Channel_Interface_Messages.html#Signal:MessageReceived

On Sat, Jun 25, 2016 at 6:59 PM, Mateus Bellomo  wrote:
> Hello,
>
> I'm looking to implement receiving text messages functionality at
> resiprocate and I would like to know what methos should I implement. I'm
> looking at [1] and the only method is SendMessage(). At [2] the only method
> is AcknowledgePendingMessages() and I think this is the one to implement but
> at [3] and [4] there another methods (whenMessageReceived() and
> processReceivedMessage(), respectively) to receive a message and I didn't
> saw an implementation for AcknowledgePendingMessages().
>
> Thanks in advance.
>
>
>
> [1] https://telepathy.freedesktop.org/spec/Channel_Interface_Messages.html
> [2] https://telepathy.freedesktop.org/spec/Channel_Type_Text.html
> [3]
> https://github.com/TelepathyQt/telepathy-morse/blob/master/textchannel.cpp
> [4]
> https://github.com/TelepathyQt/telepathy-nonsense/blob/master/textchannel.cc
>
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] wiki update

[Alexandr Akulich]

TelepathyQt documentation [1] updated automatically in the process of release.
There is "maintainer-upload-release" make target, which triggers
"maintainer-upload-release-docs" target [2]. There is also a target
"upload-branch-docs", but I didn't run it yet. Thank you, I just
noticed that there is outdated link to Qt docs
(http://doc.qt.nokia.com/latest/). I'll investigate how it used and
fix it sometime soon.

Probably glib and spec docs can be updated via rsync too.

[1] https://telepathy.freedesktop.org/doc/telepathy-qt/
[2] 
https://cgit.freedesktop.org/telepathy/telepathy-qt/tree/tools/CMakeLists.txt#n37

On Wed, Jun 22, 2016 at 1:38 AM, Diane Trout  wrote:
> On Mon, 2016-06-20 at 12:33 +0300, George Kiagiadakis wrote:
>> Hi,
>>
>> I've taken the liberty of reviving a large portion of the old
>> telepathy
>> wiki and polishing some pages so that it's usable and more current.
>>
>> Take a look [1] and let me know what you think. Feel free to edit it
>> further of course.
>>
>
> Thank you! I had no idea how to update the wiki.
>
> Though that leads me to another idea...
>
> How should we update the documentation?
>
> There's the telepathy book, the telepathy spec and the glib & qt api
> docs.
>
> I've sometimes wished the book was updated and included information
> from the glib and qt API docs.
>
> Diane
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

[Telepathy] [Announce] Telepathy Qt 0.9.7

[Alexandr Akulich]

Tarball: 
http://telepathy.freedesktop.org/releases/telepathy-qt/telepathy-qt-0.9.7.tar.gz

Signature: 
http://telepathy.freedesktop.org/releases/telepathy-qt/telepathy-qt-0.9.7.tar.gz.asc

The "Back on track" release.

There is almost no client-side changes, just build fixes and a lot of
new things on service side.
Service library is a shared library now.

Dependencies:
 * CMake minimum version bumped to 2.8.12.

Enhancements:
 * Various documentation fixes and improvements.
 * Service library is now a shared library with own ABI versioning.
 * Implemented BaseConnectionContactsInterface::getContactByID().
 * Reimplemented BaseChannelGroupInterface class
   - Has new future-proof API.
   - Has documentation for all methods.
   - Flags Properties and MembersChangedDetailed now always ON.
 * Added service-side Debug Interface implementation.
 * Added service-side Connection ClientTypes interface.
 * Added service-side Connection ContactCapabilities interface.
 * Implemented service-side FileTransfer Interface:
   - Well documented and covered with tests!
   - Supports IPv4 and IPv6 socket types with localhost access control.
   - Supports custom sockets and access control.
 * Added IODevice class, which is interesting for all CMs that have backend,
   that accepts a QIODevice for file transfers.
 * Other improvements.

API changes:
 * Service-side of ChannelGroup Interface redone with different API.

Fixes:
 * Fixed build with glibc-2.20+
 * Fixed build with GStreamer-1.5.1+
 * Added missing link to QtTest in tests.
 * Added missing link to glib2 in Farstream.
 * Fixed hash calculation of QList for Qt-5.6.
 * fd.o #91659: CMake now search for Python 2, rather than Python 3.
 * fd.o #95376: Removed usage of deprecated QDBusArgument stream operators
   (fixes build with Qt-5.7 beta and (probably) Qt-5.8+).
 * fd.o #65981: Fixed build with Ninja (cmake).
 * Fixed memory leak in DBusError.
 * Fixed BaseConnection::createChannel() ".Requested" property processing.
 * Fixed BaseChannelGroupInterface::removeMembers().
 * Fixed BaseChannelGroupInterface::groupFlagsChanged() signal emission.
 * Fixed CreationTimestamp property in BaseChannelRoomInterface.
 * Fixed device management in IncomingFileTransferChannel.
 * Fixed device management in OutgoingFileTransferChannel.
 * BaseConnection now properly closes channels on disconnect.
 * BaseConnection and BaseChannel debug output now respects Tp::enableDebug().
 * Other small fixes.
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Project revival?

[Alexandr Akulich]

On Fri, Jun 10, 2016 at 9:43 PM, Alexandr Akulich
<akulichalexan...@gmail.com> wrote:
> Hi George,
>
> Can you review commits [3], [4], please?
>
> [3] 
> https://github.com/TelepathyQt/telepathy-qt/commit/8864249479ea2adbb5c88378aa082fa18d55f6b0
> [4] 
> https://github.com/TelepathyQt/telepathy-qt/commit/d9354dfe8cca364e4a8c3a44c302ceb714c53911
>

I'm writing NEWS for the 0.9.7 release and thus checking bugzilla for
TpQt related bugs and just found exists bugreport [1] for my fix [2].

Can someone confirm that my fix isn't worse than the patch, attached
to the bugreport?

[1] https://bugs.freedesktop.org/show_bug.cgi?id=65981
[2] 
https://github.com/TelepathyQt/telepathy-qt/commit/d9354dfe8cca364e4a8c3a44c302ceb714c53911

Do anyone have an idea for codename for the release?
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Project revival?

[Alexandr Akulich]

Hi George,

I'm using github [1] as a platform for TelepathyQt-related projects
development and we have some kind of "dev" branch of tp-qt here too
[2].

For sure, fd.o is the only official TpQt host, while github repo is an
"experimental fork" with untested and WIP features, which is open for
pull requests and direct commits from some more devs. I review changes
and push them to fd.o. Actually, only Niels Ole Salscheider used this
opportunity so far.

That said, I just pushed changes to github. Can you review commits
[3], [4], please?

I think we can release 0.9.7 this weekend. I'll check (again)
distributives for possible patches, fulfil changelog entry, check Qt4
/ Qt5 build and make release.

[1] https://github.com/TelepathyQt
[2] https://github.com/TelepathyQt/telepathy-qt
[3] 
https://github.com/TelepathyQt/telepathy-qt/commit/8864249479ea2adbb5c88378aa082fa18d55f6b0
[4] 
https://github.com/TelepathyQt/telepathy-qt/commit/d9354dfe8cca364e4a8c3a44c302ceb714c53911

On Fri, Jun 10, 2016 at 10:00 AM, George Kiagiadakis
<gkia...@tolabaki.gr> wrote:
> Hi Alexandr,
>
> On 09.06.2016 22:58, Alexandr Akulich wrote:
>>
>> Hi George,
>>
>> It's great to hear about more devs get work on Telepathy.
>>
>> I'm TelepathyQt maintainer for a year now and I'm planning to release
>> 0.9.7 as soon as I'll made a future-proof commit with fix of
>> https://bugs.freedesktop.org/show_bug.cgi?id=95376 for Qt-5.8.
>>
>> It would be helpful if someone would acknowledge or review my changes.
>
>
> I'm definitely up for that. :)
>
>
>> Since commit [1] there is no QDBusArgument operators overload for
>> QList. I reported the problem [2] and it seems that the "bad" commit
>> will be reverted for 5.7, but our current approach is deprecated since
>> [3].
>>
>> I'm going to change tools/qt-types-gen.py script to generate such
>> operators in types-body.hpp:
>>
>> TP_QT_EXPORT QDBusArgument <<(QDBusArgument , const UIntList
>> )
>> {
>> int id = qMetaTypeId();
>> arg.beginArray(id);
>> for (int i = 0; i < list.count(); ++i) {
>> arg << list.at(i);
>> }
>> arg.endArray();
>> return arg;
>> }
>>
>> TP_QT_EXPORT const QDBusArgument >>(const QDBusArgument ,
>> UIntList )
>> {
>> arg.beginArray();
>> list.clear();
>> while (!arg.atEnd()) {
>> uint item;
>> arg >> item;
>> list.append(item);
>> }
>> arg.endArray();
>> return arg;
>> }
>>
>> As far as I see, this would be a full equivalent to the current
>> behaviour, but I didn't fully tested it yet.
>>
>> Would you acknowledge such approach or I'm missing something
>> important? Comment in types.h says that we "needed to have a discrete
>> type in the Qt type system" and we actually do qDBusRegisterMetaType
>> in types-body.hpp, but at the same time we're relying on QList stream
>> operators overload, which ignores any T parts except the base and has
>> no references to the original list object metatype.
>
>
> As far as I understand, the argument "ignores any T parts except the base"
> does not apply to our type here because T is int and int is a native type
> that doesn't need further operator overloads. But I can see how for the
> generic case it's true.
>
> In any case, I think your approach is sane. Please go ahead and ping me for
> a review if you wish.
>
> Regards,
> George
>
>
>>
>> [1]
>>
>> http://code.qt.io/cgit/qt/qtbase.git/commit/?id=5f542f3cca13f2da58b82aee2efbaffefeee00a7
>> [2] https://bugreports.qt.io/browse/QTBUG-53376
>> [3]
>>
>> http://code.qt.io/cgit/qt/qtbase.git/commit/?id=c7d4858c921c7602dc90d56cdd903cd2cbc6
>>
>> On Thu, Jun 9, 2016 at 8:02 PM, George Kiagiadakis <gkia...@tolabaki.gr>
>> wrote:
>>>
>>> Hello all,
>>>
>>> For those of you that don't know me, I'm an old kde-telepathy &
>>> telepathy-qt developer who's been inactive in telepathy for a couple of
>>> years. Recently I've been looking again into what is going on in this
>>> project and it looks like it's dead, which is a pity. However, I can see
>>> there is some limited activity around telepathy-qt, with some people
>>> writing new Qt-based CMs (cool!). This little activity makes me hope
>>> that maybe it's possible to revive the rest of the project?
>>>
>>> I'm basically writing this email to declare my interest in attempting a
>>> revival. I think free communication

Re: [Telepathy] Project revival?

[Alexandr Akulich]

Hi George,

It's great to hear about more devs get work on Telepathy.

I'm TelepathyQt maintainer for a year now and I'm planning to release
0.9.7 as soon as I'll made a future-proof commit with fix of
https://bugs.freedesktop.org/show_bug.cgi?id=95376 for Qt-5.8.

It would be helpful if someone would acknowledge or review my changes.

Since commit [1] there is no QDBusArgument operators overload for
QList. I reported the problem [2] and it seems that the "bad" commit
will be reverted for 5.7, but our current approach is deprecated since [3].

I'm going to change tools/qt-types-gen.py script to generate such
operators in types-body.hpp:

TP_QT_EXPORT QDBusArgument <<(QDBusArgument , const UIntList )
{
int id = qMetaTypeId();
arg.beginArray(id);
for (int i = 0; i < list.count(); ++i) {
arg << list.at(i);
}
arg.endArray();
return arg;
}

TP_QT_EXPORT const QDBusArgument >>(const QDBusArgument ,
UIntList )
{
arg.beginArray();
list.clear();
while (!arg.atEnd()) {
uint item;
arg >> item;
list.append(item);
}
arg.endArray();
return arg;
}

As far as I see, this would be a full equivalent to the current
behaviour, but I didn't fully tested it yet.

Would you acknowledge such approach or I'm missing something
important? Comment in types.h says that we "needed to have a discrete
type in the Qt type system" and we actually do qDBusRegisterMetaType
in types-body.hpp, but at the same time we're relying on QList stream
operators overload, which ignores any T parts except the base and has
no references to the original list object metatype.

[1] 
http://code.qt.io/cgit/qt/qtbase.git/commit/?id=5f542f3cca13f2da58b82aee2efbaffefeee00a7
[2] https://bugreports.qt.io/browse/QTBUG-53376
[3] 
http://code.qt.io/cgit/qt/qtbase.git/commit/?id=c7d4858c921c7602dc90d56cdd903cd2cbc6

On Thu, Jun 9, 2016 at 8:02 PM, George Kiagiadakis  wrote:
> Hello all,
>
> For those of you that don't know me, I'm an old kde-telepathy &
> telepathy-qt developer who's been inactive in telepathy for a couple of
> years. Recently I've been looking again into what is going on in this
> project and it looks like it's dead, which is a pity. However, I can see
> there is some limited activity around telepathy-qt, with some people
> writing new Qt-based CMs (cool!). This little activity makes me hope
> that maybe it's possible to revive the rest of the project?
>
> I'm basically writing this email to declare my interest in attempting a
> revival. I think free communication is quite important and it's being
> neglected a lot recently in the FOSS world, which motivates me enough to
> spend some time again in this project.
>
> As a start, I would like to get in touch with all of you who are still
> working on something related to telepathy. It would be nice to start a
> conversation about project needs and future plans. So, if you are
> interested, please get in touch. I am 'gkiagia' on irc and various other
> places on the internet.
>
> Regards,
> George
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] send local user status

[Alexandr Akulich]

Hi Mateus,

On Mon, Jun 6, 2016 at 1:45 AM, Mateus Bellomo  wrote:
> I've implemented both setPresence() and getPresences() methods, but
> I didn't see there any methods so the user could send his status info to his 
> contacts.

setPresence() accepts string:Status and string:StatusMessage and
designed to send the passed info to contacts.

See [1] and [2]. Local user set presence in the UI (Empathy,
KDE-Telepathy, ...). The UI calls setPresence(). The CM setPresence()
implementation (probably via a special library) sends network packages
to inform remotes about the new presence. Morse calls
CTelegramCore::setOnlineStatus() of the TelegramQt backend library;
Nonsense calls QXmppClient::setClientPresence() of the QXmpp backend
library.

[1] 
https://github.com/TelepathyQt/telepathy-nonsense/blob/master/connection.cc#L347
[2] 
https://github.com/TelepathyQt/telepathy-morse/blob/master/connection.cpp#L655
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] buddy list methods

[Alexandr Akulich]

QtWidgets/QAction is a Qt5 header file.

Despite of "USE_QT4=true", CMake somewhy invoked Qt5 uic (User
Interface Compiler) to generate ui_MainWindow.h from MainWindow.ui.

if you have to manually pass such cpp flags as Qt4 includes, then
there is something wrong with your Qt4/CMake setup.

I don't have Qt4 on my pc, but I'll check Qt4 build sometime soon.

At the same time, you have Qt5 uic, so you have installed Qt5. Why do
you use five years old Qt4 instead? Would you mind to check if default
Qt version (without USE_QT4 argument it would be Qt5) would work for
you?

On Wed, May 25, 2016 at 4:51 AM, Mateus Bellomo <mateusbell...@gmail.com> wrote:
> Ok...now I got this:
>
> mateus@mateus:~/simpleCm$ cmake CPPFLAGS='-I/usr/include/qt4
> -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork
> -I/usr/include/qt4/QtDBus' -DENABLE_EXAMPLE=true -DUSE_QT4=true
> CMakeLists.txt
> -- Found Qt4: /usr/bin/qmake (found suitable version "4.8.6", minimum
> required is "4.6.0")
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/mateus/simpleCm
>
> mateus@mateus:~/simpleCm$ make -j5
> Scanning dependencies of target simple-connection-manager-qt4_automoc
> [ 16%] [ 16%] Automatic moc for target simple-connection-manager-qt4
> Automatic moc for target simplecm-qt4
> Generating moc_CComboBoxDelegate.cpp
> [ 16%] Built target simplecm-qt4_automoc
> [ 50%] Built target simplecm-qt4
> Generating moc_CContactsModel.cpp
> Generating moc_MainWindow.cpp
> [ 50%] Built target simple-connection-manager-qt4_automoc
> Scanning dependencies of target simple-connection-manager-qt4
> [ 58%] [ 75%] [ 75%] [ 83%] [ 91%] Building CXX object
> example/CMakeFiles/simple-connection-manager-qt4.dir/CComboBoxDelegate.cpp.o
> Building CXX object
> example/CMakeFiles/simple-connection-manager-qt4.dir/main.cpp.o
> Building CXX object
> example/CMakeFiles/simple-connection-manager-qt4.dir/MainWindow.cpp.o
> Building CXX object
> example/CMakeFiles/simple-connection-manager-qt4.dir/CContactsModel.cpp.o
> Building CXX object
> example/CMakeFiles/simple-connection-manager-qt4.dir/simple-connection-manager-qt4_automoc.cpp.o
> In file included from /home/mateus/simpleCm/example/MainWindow.cpp:2:0:
> /home/mateus/simpleCm/example/ui_MainWindow.h:13:29: fatal error:
> QtWidgets/QAction: No such file or directory
>  #include 
>  ^
> compilation terminated.
> example/CMakeFiles/simple-connection-manager-qt4.dir/build.make:82: recipe
> for target
> 'example/CMakeFiles/simple-connection-manager-qt4.dir/MainWindow.cpp.o'
> failed
> make[2]: ***
> [example/CMakeFiles/simple-connection-manager-qt4.dir/MainWindow.cpp.o]
> Error 1
> make[2]: *** Waiting for unfinished jobs
> CMakeFiles/Makefile2:143: recipe for target
> 'example/CMakeFiles/simple-connection-manager-qt4.dir/all' failed
> make[1]: *** [example/CMakeFiles/simple-connection-manager-qt4.dir/all]
> Error 2
> Makefile:117: recipe for target 'all' failed
> make: *** [all] Error 2
>
> Which extra library I should include (I already included all libraries used
> in resiprocate)?
>
>
> 2016-05-24 16:24 GMT-03:00 Alexandr Akulich <akulichalexan...@gmail.com>:
>>
>> >But I'm not finding any executable.
>> -DENABLE_EXAMPLE=true
>
>
>
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] buddy list methods

[Alexandr Akulich]

>But I'm not finding any executable.
-DENABLE_EXAMPLE=true
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] buddy list methods

[Alexandr Akulich]

He Mateus,

You might be interested in SimpleCM. It doesn't need any backend; you
don't have to install anything.
Just build the example application, start CM and register an account
(e.g. via mc-tool).

[1] https://github.com/Kaffeine/simpleCm

On Tue, May 24, 2016 at 6:58 PM, Mateus Bellomo  wrote:
>> Have you tried running that and adding a couple of contacts to the buddy
>> list to test it?
>
> No I didn't. I will try to do that.
>
> 2016-05-24 10:52 GMT-03:00 Daniel Pocock :
>>
>>
>>
>> On 24/05/16 15:47, Mateus Bellomo wrote:
>> >> Can you compare with the one of the other components based on
>> >> TelepathyQt?
>> >
>> > Are you referring from some component at resiprocate?
>> >
>>
>>
>> No, I was thinking about telepathy-morse perhaps.  Have you tried
>> running that and adding a couple of contacts to the buddy list to test it?
>> ___
>> telepathy mailing list
>> telepathy@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
>
>
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] kill telepathy process

[Alexandr Akulich]

Hi Mateus,

I would suggest to *not* install the CM executable, but run it from an IDE.
During development you'll want to debug the application (set
breakpoints and so on) so you'll need to either run from IDE or attach
debugger.

Even better, I would suggest you to make  a "bundle" with TelepathyQt,
CM and resiprocate library in a single project. This way you'll be
able to debug any of TelepathyQt <-> CM <-> Resiprocate at same time.

I made a script [1] to setup such "bundle" for TpQt + Morse/TelegramQt
+ Nonsense/QXmpp. You can base on it, if you want.

Take a note that once you'll have things work in your IDE, you'll
still have to test everything via proper installation.

[1] 
https://github.com/TelepathyQt/telepathy-qt/wiki/Project-with-CMs-as-examples

On Sun, May 22, 2016 at 2:04 AM, Daniel Pocock  wrote:
>
>
> On 21/05/16 20:54, Mateus Bellomo wrote:
>> Hello,
>>
>> I'm using telepathy-resiprocate and I want to keep killing and
>> restarting the process because I'm doing some changes in the code.
>>
>> I noticed that when I kill the telepathy-resiprocate process it starts
>> again by itself (without me executing the telepathy-resiprocate
>> executable). So I wonder if there is a way to kill the process in a way
>> that only I could start it again later.
>>
>
>
> That is probably because you used this script:
>
> https://github.com/resiprocate/resiprocate/blob/master/apps/telepathy/deploy-properties
>
> If you remove the files it installed and restart mission-control again
> then it won't keep trying to start telepathy-resiprocate for you.
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] run telepathy with empathy at ubuntu

[Alexandr Akulich]

Hi Mateus,

Are you talking about *account registration* (e.g. on remote server)
or about local account setup?

I'm not familiar with Empathy, but usually we have to write account
setup code for each CM. Alternatively, you can use mc-tool to setup
account from command line.
Account registration usually performed via "register" connection
parameter [1]. If there is no such option in the UI, then you can
"fallback" to mc-tool (again) to set arbitrary connection parameter.

[1] 
https://telepathy.freedesktop.org/spec/Connection_Manager.html#Simple-Type:Connection_Parameter_Name


On Tue, May 17, 2016 at 8:57 PM, Mateus Bellomo  wrote:
> Hello,
>
> I'm developing some methods for resiprocate-telepathy [1] and I want to test
> it.
>
> Now I'm initiating telepathy with this:
>
> $ libtool --mode=execute gdb ./telepathy-resiprocate
>
> and I see telepathy-resiprocate running :
>
> tp-qt 0.9.6.1 DEBUG: Building ProtocolParameter with flags not containing
> ConnMgrParamFlagHasDefault and a default value, updating flags to contain
> ConnMgrParamFlagHasDefault
> tp-qt 0.9.6.1 DEBUG: Interface
> "org.freedesktop.Telepathy.Protocol.Interface.Addressing" plugged
> tp-qt 0.9.6.1 DEBUG: Protocol "sip" added to CM
> tp-qt 0.9.6.1 DEBUG: Registering protocol "sip" at path
> "/org/freedesktop/Telepathy/ConnectionManager/resiprocate/sip" for CM
> "/org/freedesktop/Telepathy/ConnectionManager/resiprocate" at bus name
> "org.freedesktop.Telepathy.ConnectionManager.resiprocate"
> tp-qt 0.9.6.1 DEBUG: Registered object
> "/org/freedesktop/Telepathy/ConnectionManager/resiprocate/sip" at bus name
> "org.freedesktop.Telepathy.ConnectionManager.resiprocate"
> tp-qt 0.9.6.1 DEBUG: Registering CM
> "/org/freedesktop/Telepathy/ConnectionManager/resiprocate" at bus name
> "org.freedesktop.Telepathy.ConnectionManager.resiprocate"
> tp-qt 0.9.6.1 DEBUG: Registered object
> "/org/freedesktop/Telepathy/ConnectionManager/resiprocate" at bus name
> "org.freedesktop.Telepathy.ConnectionManager.resiprocate"
>
> But when I start empathy, I cannot see a SIP account option for
> registration. Am I missing something?
>
> PS: I also execute the script at [2] before start telepathy-resiprocate
>
>
> thanks in advance
>
> [1] https://github.com/resiprocate/resiprocate/tree/master/apps/telepathy
> [2]
> https://github.com/resiprocate/resiprocate/blob/master/apps/telepathy/deploy-properties
>
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Which ContactList interface methods are essential?

[Alexandr Akulich]

Hi.

On 10/05/16 20:34, Mateus Bellomo wrote:
> I would like to know what are the ... methods that I should implement.
Read the doc and implement methods which do what you need.

Most telepathy clients will not show contact list without info about
contact attributes, so you definitely have to implement
GetContactListAttributes(). All other methods needed to do what they
said to do.
Do you need to be able to remove a contact from the list? Implement
RemoveContacts().
Want to add a contact? The method name is not too obvious, but it's
easy to figure it out from the specification - RequestSubscription().
And so on.

On Sat, May 14, 2016 at 12:26 PM, Daniel Pocock  wrote:
>
> In all the other methods, you could include a log message to indicate
> that an unimplemented method has been called, beware of doing this if it
> overrides an implementation in a superclass though.
TelepathyQt uses conception of callback instead of virtual method.
This let us to implement an object (such as protocol, connection or
channel) interfaces right in the object class, instead of subclassing
tens of interfaces with just a few methods.

TelepathyQt interfaces automatically log unimplemented method calls.
E.g. if you run test-base-cm, you'll see follow line in the log:
QDEBUG : TestBaseCM::testProtocols() tp-qt 0.9.7 DEBUG:
CreateConnection failed:
"org.freedesktop.Telepathy.Error.NotImplemented": "Not implemented"

https://cgit.freedesktop.org/telepathy/telepathy-qt/tree/TelepathyQt/base-protocol.cpp#n548
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] status of empathy and XMPP in telepathy

[Alexandr Akulich]

Hi Michael,

I'm one of the TelepathyQt-based XMPP Connection Manager developer.
Because of distributed nature of Telepathy, there is no technical problem,
but indeed, may be GNOME Project would try to avoid it.

Telepathy-Nonsense (the CM) is at an early stage of development, literally
yesterday I committed initial group chat support, implemented incoming and
outgoing invitation and turned on ClientType interface. There are many
things which needs to be implemented before 0.1 release.

On the other side, telepathy-gabble seems to have implemented everything
mentioned in the Telepathy specification and I don't see any "low hanging
fruit" here.
Instead, in order to add a feature, you'll need to 1) design its draft
specification (which should be "necessary and sufficient" for a number of
protocols), 2) implement it in a connection manager, 3) implement it in a
client, 4) get reviews, 5) polish everything.

IMO the first step is the hardest and most important one and of course we
can work on it together. For a half of features it would just about 15
lines of code for #2 (a connection manager) and something similar for #3 (a
client) so it's not a big deal to duplicate efforts here.

On Fri, Apr 29, 2016 at 2:32 PM, Michael Vetter 
wrote:

> On Tue, 26 Apr 2016 17:52:06 +0200
> Daniel Pocock  wrote:
> > telepathy-gabble appears to be based on the telepathy-glib bindings
> >
> > A lot of the newer work appears to be using TelepathyQt instead of
> > telepathy-glib.  My first suggestion would be to look for any attempts
> > to do XMPP with TelepathyQt or possible start such an implementation.
> > Look at how I started the telepathy-resiprocate project for an
> > example.
>
> Is this a good idea if I want to help improve Empathy? I am not sure if
> a GNOME project will use Qt.
>
> > Secondly, telepathy-gabble has a focus on the Google Talk version of
> > XMPP, especially for voice and video.
> > - the NAT traversal parameters are hard-coded to use Google servers,
> > making it useless if neither user is a Google account
> > - this Google emphasis is irrelevant now anyway, since Google is not
> > supporting XMPP properly at all any more.
> > Bottom line: don't be afraid to lose the Google support, go for
> > standard ICE and TURN.
>
> That should definitely changed.
> However I am still uncertain on how to proceed here.
> Someone showing me the way into the project would be good.
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] future of Telepathy?

[Alexandr Akulich]

On Tue, Apr 26, 2016 at 1:26 PM, Dominik George  wrote:
> Am Dienstag, 26. April 2016, 13:20:55 schrieben Sie:
>> On Tue, Apr 26, 2016 at 1:10 PM, Dominik George  wrote:
>> >go and move WhatsApp users to Conversations - they will not miss anything.
>>
>> Oh, really? My contacts used to send images to offline contacts. How
>> would you imagine to implement this for XMPP?
>
> No need for imagination - it simply works:
>
>   http://xmpp.org/extensions/xep-0363.html
>
> Implemented in Conversations on Android and in Gajim, works for sending any
> file to contacts, no matter if they are online or offline, and even to MUCs
> („groups“).
>
> On a side note, it is technically the same thing that WhatsApp does -
> leveraging HTTP for storage.
>
> Servers providing the extension keep popping up.
Thank you, I didn't found that.

>> What's about "I'm here"
>> or "let's meet there" geo messages?
>
> https://www.androidpit.com/app/eu.siacs.conversations.sharelocation
>
This doesn't look like a XEP.

> As I said - Conversations did all of it. Follow along if you are a client
> developer!
Sure. As soon, as it will be a standard.
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] future of Telepathy?

[Alexandr Akulich]

Hi.

I'm slowly "coming" with Qt-based Telegram Connection Manager and work
(with a lower priority) on (qxmpp-based) XMPP Connection Manager.

Almost nobody needs telegram (whatsapp, whatever) client without
multimedia messages, and, as there is no any (reference) CM
implementation, it is not implemented in clients.
Telepathy specs have some words about media messages and I can quickly
add initial implementation in in the CM, but it doesn't make sense
without a client. I work on KTp and so far I implemented only Geo
messages receiving in KTp Text UI. Images and Video messages don't fit
in current ktp internal implementation and KTp needs to be
significantly refactored to support non-text messages. The changes
would be complex and it would take a long time to mainstream them
without regressions. I'm going to release Telepathy-Morse (Telegram
CM) with experimental geo and image messages receiving support
sometime soon and may be after the release someone will step up and
implement media messages in Empathy.

I'm sorry, I have just a little time to work on this and despite that
I said that I'll make the release months ago, it doesn't come out yet.
I'll not stop the work and just three days ago I fixed the biggest
showstopper issue.

On Mon, Apr 25, 2016 at 6:28 PM, Debarshi Ray  wrote:
> Hey Paul,
>
> On Sat, Apr 23, 2016 at 03:19:15PM +0800, Paul Wise wrote:
>> I note that there isn't much recent activity in the repos:
>>
>> https://cgit.freedesktop.org/telepathy
>
> You are right.
>
> With my GNOME hat on, we are not spending much effort on our instant
> messaging features. For a free software desktop, XMPP was by far the
> most useful and mature part of Telepathy. Google, Facebook and
> Microsoft has either moved away from XMPP or deprecated it, while
> Telegram and Whatsapp use something different.
>
> None of the XMPP-based free VoIP options ever worked reliably. They
> were spotty at best. So, even if Maemo used Telepathy for making GSM
> calls, it didn't offer much to GNOME.
>
> Some fringe and/or enterprisey protocols are supported via libpurple /
> telepathy-haze, but the quality tends to vary. Even if they do work,
> they are, by their very nature, not so appealing for the majority of
> users.
>
> That leaves IRC. The new GNOME IRC client, Polari, uses Telepathy, but
> one can argue that it would be better off without it. IRC was always a
> square peg trying to fit into a round hole, and Polari is not using
> many of the features offered by Telepathy (eg., multiple
> special-purpose clients).
>
> Add to this the fact that all the original Telepathy maintainers have
> left. (I am not part of the original crew, and was only involved in
> certain parts of the stack.)  Sometimes I look at a bug-fix or spin a
> tarball, mostly because I am involved with Telepathy maintenance in
> Fedora and RHEL, but its very rare.
>
> Given how hard it is to support any of the popular instant messaging
> networks, a free software IM stack looks increasingly pointless. Maybe
> someone will come up with a mature Telegram implementation ...
>
> Cheers,
> Rishi
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] TelepathyQt in GSoC 2016, ABI issues

[Alexandr Akulich]

Hi Daniel,

On Sat, Apr 23, 2016 at 1:16 PM, Daniel Pocock  wrote:
> - if the ABI is changing on each release, should TelepathyQt libs use an
> SONAME such as libtelepathy-qt4-0.9.6.so.0 ?  Currently it is
> libtelepathy-qt4.so.2 - that was used for both 0.9.4 and 0.9.6 but I'm
> not sure if they are ABI compatible?
They're compatible, because there is no any client-side API changes
for a long time.

> - the libtelepathy-qt?-service.so needs to be in the packages as a
> shared object.  The concerns about the stability of this API/ABI can
> probably be addressed by the SONAME proposal above.
I agreed and made the change months ago and just pushed it to the fd.o
repo. See [1] and [2].

[1] https://cgit.freedesktop.org/telepathy/telepathy-qt/commit/?id=5eedded
[2] https://cgit.freedesktop.org/telepathy/telepathy-qt/commit/?id=2ff93cd
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy Help

[Alexandr Akulich]

Hi Pranav,

On Fri, Apr 8, 2016 at 8:49 AM, Pranav Jain  wrote:
> I did try to go through the Github codes and the official document. I am 
> still unable to find the 'Dial Command' specifications.
I think it doesn't exists.

> The only link which explains it in some way is 
> http://www.ousob.com/ng/telepath/ng22b8c.php
I think this is just a coincide and the linked project is not related
to the telepathy framework.

> Can you please help me more in understanding this command.
Are you sure that you need such command specification? It sounds like
a general concept, but not like a strictly formalized spec.

Probably the "Dial" command is just an ordinary channel request. The
client would just make a request to your connection manager, something
like:
"hey, ! Please, create a channel with a
contact with identifier +123456789."

The second case is if you're telling about DTMF (dual-tone
multifrequency signalling). It is described in the Telepathy
specification and implemented in the telepathy-ofono.
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] incoming call not notified

[Alexandr Akulich]

I would suggest to use Bustle (dbus viewer) to see if connection
manager emits Connection.Interface.Requests NewChannels() signal and
(if so) how the signal processed by MissionControl.

On Sat, Oct 17, 2015 at 3:55 AM, Diane Trout  wrote:
>> Is there a TelepathyQt API call to trigger the approver?
>>
>> This is the code I have right now:
>>
>> https://github.com/resiprocate/resiprocate/blob/master/apps/telepathy/SipCal
>> lChannel.cxx#L37
>>
>> Is there something obviously missing?
>
> I don't know the guts of telepathy to answer that definitively.
>
> http://telepathy.freedesktop.org/spec/Channel_Type_Call.html has some
> documentation on the what dbus signals are supposed to be exchanged when
> setting up a call.
>
> I'm not sure if the TpQt code ends emitting the right dbus signal, but it also
> seems like the set of parameters you're providing isn't as long as what rakia
> was setting up for its call.
>
> As far as I could tell this is the chunk of rakia that creates a new incoming
> call. (unfortunately against the telepathy-glib binding)
>
> http://sources.debian.net/src/telepathy-rakia/0.8.0-3/rakia/media-manager.c/#L400
>
> which then sets up a callback to
>
> http://sources.debian.net/src/telepathy-rakia/0.8.0-3/rakia/media-manager.c/#L262
>
> and the constructor in rakia seems more detailed than your code.
>
> Diane
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] telepathy-python

[Alexandr Akulich]

On Fri, Aug 21, 2015 at 11:41 AM, Diane Trout di...@ghic.org wrote:
 On Thursday, August 20, 2015 17:39:12 Nicolas Dufresne wrote:
 Le mardi 18 août 2015 à 16:59 -0700, Diane Trout a écrit :
  My current progress is at:
 
  https://github.com/detrout/telepathy-python

 Hmm, but telepathy-glib is fully instrospectable, you don't need
 manually written bindings. To start using it, simply do:

  from gi.repository import TelepathyGLib

 Nicolas

 I knew there was a gi.repostory implementation, but I wasn't sure how complete
 it was. In my experience many other C apis that are ported to python end up
 with some glue python code added on top of the C api in order to make the API
 look more like python. I wasn't sure how well worked out the class wrappers
 would be in gi.repository.

 The existence of the gi.repository bindings is also why I was thinking of
 adapting this version to more closely resemble the TelepathyQt bindings as the
 glib people can just use gi.repository.

 Also, although gi.repository is a really neat technology, there's no way to
 avoid the fact that the APIs implemented in gi.repository are still glib APIs.

 (As an aside is there any documentation about how to create a typelib?)

 Also, there's very little documentation available about the gi.repository
 bindings themselves. Not to mention the glib bindings themselves lack any sort
 of user guide, though API docs for the glib bindings appear to be decent.

 However I'm used to well written sphinx docs. E.g. compare the following:

 http://telepathy.freedesktop.org/doc/telepathy-glib/index.html
 or
 http://telepathy.freedesktop.org/doc/telepathy-qt/index.html
 to
 http://scikit-learn.org/stable/documentation.html

 And as an example drilling down to a particular api call:

 we have glib:
 http://telepathy.freedesktop.org/doc/telepathy-glib/telepathy-glib-connection-aliasing.html
 Qt:
 http://telepathy.freedesktop.org/doc/telepathy-qt/a00270.html

You pointed to the Adaptor class, which is a generated class, not
intended to be used by a developer. I'm wonder, why we export it.

Correct link to the Connection Aliasing interface Qt/C++ API is:
http://telepathy.freedesktop.org/doc/telepathy-qt/a00117.html

That said, the documentation is even worse, than you think.

As TpQt developer, I think it's more important to implement all
features, than write documentation, because you always can use the
spec as documentation.
http://telepathy.freedesktop.org/spec/Connection_Interface_Aliasing.html
TpQt API is mostly a mirror of specification. The mentioned Aliasing
interface is fully (for 100%) generated from the XML by
https://github.com/TelepathyQt/telepathy-qt-generator.
It is possible to improve the generator to copy the documentation from
spec, but it doesn't worth it yet.

We have a special case with FileTransfer API, which is different from
the spec, thus we added a documentation for it:
https://github.com/TelepathyQt/telepathy-qt/blob/master/TelepathyQt/base-channel.cpp#L952
 Sphinx:
 http://scikit-learn.org/stable/modules/generated/sklearn.cluster.DBSCAN.html#sklearn.cluster.DBSCAN

 Sphinx has cross references, individual calls have paragraph anchor markers,
 there are links to the source

 I had been contemplating if it was possible to take the old Telepathy
 Developer's Manual and convert it into a sphinx tree and generate a more up-
 to-date user guide + api docs. (I wasn't sure how free the documentation
 license was)

 Also in trying to use the gi.repository bindings I tried the following:

 In [1]: from gi.repository import TelepathyGLib as tp

 In [2]: tp.ConnectionManager()

 (process:22488): tp-glib-CRITICAL **: tp_proxy_constructor: assertion 'self-
dbus_connection != NULL' failed
 Segmentation fault

 The pure python telepathy bindings have never ever segfaulted on me. I used
 them to repeatedly crash plasmashell, but no matter how poorly I understood
 the telepathy dbus bindings python never crashed.

 Further introspecting on the ConnectionManager object:

 ConnectionManager(**properties)
 new(dbus:TelepathyGLib.DBusDaemon, name:str, manager_filename:str=None) -
 TelepathyGLib.ConnectionManager

 suggests it might want a dbus and str parameter, however:

 In [6]: tp.ConnectionManager(bus, 'foo')
 ---
 TypeError Traceback (most recent call last)
 ipython-input-6-b863bc8f3613 in module()
  1 tp.ConnectionManager(bus, 'foo')

 TypeError: GObject.__init__() takes exactly 0 arguments (2 given)

 It's kind of baffling how you might use that class.

 If that's a bug and not user error I'm on Debian using:
 Package: gir1.2-telepathyglib-0.12
 Version: 0.24.1-1

 Diane
 ___
 telepathy mailing list
 telepathy@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/telepathy
___
telepathy mailing list
telepathy@lists.freedesktop.org

Re: [Telepathy] telepathy-reSIProcate connection manager

[Alexandr Akulich]

On Sun, Aug 16, 2015 at 9:42 AM, Debarshi Ray rishi...@lostca.se wrote:
 On Wed, Aug 12, 2015 at 04:30:00PM +0600, Alexandr Akulich wrote:
 There is many differences between qt and glib bindings.
 The first one is mature and stable, while the last one is still in
 development and can introduce some small API changes.

 Eh?
Please, clarify your question. :)

 Cheers,
 Debarshi
I'm not familiar with gtk/glib, but telepathy-glib based connection
managers exists for a long time. It is the main protocol
implementation, so it have all of the features. TpGlib also have a
stable branch, I don't know about warranties though.
At the same time, (in TpQt) we still have to polish the API. Most
noticeable changes are BaseConnection::createChannel()/ensureChannel()
[1] and BaseChannel::create() signature changes. My reasons is that
the library was been useless for any big-enough CM, so we had a chance
to improve it, until it's carved in stone. I try to reduce the issues
because of the changes. I added the TP_QT_VERSION and
TP_QT_VERSION_CHECK macros, which made it possible to maintain
backward-compatible code in CM and I'm in contact with probably all
other Qt-based CM developers and help them in porting.
IMO, 0.9.6 is the first really applicable release, but again, I have
an API change for 0.9.7 [3]. Probably, there would be group-related
changes as well.

Depend on available time, I'm planning to finally consolidate the API
at 0.9.7 and made the release with shared library instead of static.
After all, we'll have yet another chance to fix the API with 1.0
release in some distant future. To be said, there is at least eight
telepathy-glib release with API breaks on the long road to final
Telepathy-1.0 implementation.

Everything said is about Telepathy services, *not* a client side library.

[1] 
https://github.com/TelepathyQt/telepathy-qt/commit/2263a6459de9c50269da4630a563e4e4bff0fc82
[2] 
https://github.com/TelepathyQt/telepathy-qt/commit/00f2d5a0533743b01be6af069349942097bb91a3
[3] 
https://github.com/TelepathyQt/telepathy-qt/commit/4542429f839ad328a800e2d69917efbb2f63a6ad
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] telepathy-reSIProcate connection manager

[Alexandr Akulich]

Oh! :D

 I'm lol.

Martin, thank you for pointing. :-D

On Sun, Aug 16, 2015 at 11:40 PM, Martin Klapetek mklape...@kde.org wrote:
 On Sun, Aug 16, 2015 at 2:19 PM, Alexandr Akulich
 akulichalexan...@gmail.com wrote:

 On Sun, Aug 16, 2015 at 9:42 AM, Debarshi Ray rishi...@lostca.se wrote:
  On Wed, Aug 12, 2015 at 04:30:00PM +0600, Alexandr Akulich wrote:
  There is many differences between qt and glib bindings.
  The first one is mature and stable, while the last one is still in
  development and can introduce some small API changes.
 
  Eh?
 Please, clarify your question. :)


 You wrote that tp-qt is mature and stable while the tp-glib is still
 in development with upcoming API changes.

 In other words, it was meant to be the other way around, obviously :)

 Cheers
 --
 Martin Klapetek | KDE Developer

 ___
 telepathy mailing list
 telepathy@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/telepathy

___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] telepathy-reSIProcate connection manager

[Alexandr Akulich]

Hi Daniel,

I would like to suggest you to base your project on TelepathyQt.

Most of TelepathyQt connection managers implemented like you said:
it's wrapping C++ libraries.

Telepathy-Ofono wraps oFono library.
https://launchpad.net/telepathy-ofono

Telepathy-Nonsense wraps QXmpp library.
https://github.com/TelepathyQt/telepathy-nonsense

Telepathy-Hanging wraps libhangish.
https://github.com/tiagosh/telepathy-hanging

As author of Telepathy-Morse, I developed TelegramQt library and used
it as a backend.
https://github.com/TelepathyQt/telepathy-morse

There is many differences between qt and glib bindings.
The first one is mature and stable, while the last one is still in
development and can introduce some small API changes.
Personally, I found Qt one much more convenient and perspective, than
stalled(?) glib one.

Visit freedesktop.org to compare Telepathy bindings development activity:
http://cgit.freedesktop.org/telepathy/telepathy-qt/log/
http://cgit.freedesktop.org/telepathy/telepathy-glib/log/

Note, that Qt and Glib bindings implements the same specification and
have similar platforms set.
Both bindings do not require GUI libraries (Qt is not GUI framework,
as someone might think).
On Wed, Aug 12, 2015 at 12:35 AM, Daniel Pocock dan...@pocock.pro wrote:


 I started documenting a Telepathy connection manager for reSIProcate:

 https://www.resiprocate.org/Telepathy_Connection_Manager

 https://www.resiprocate.org/bugzilla/show_bug.cgi?id=92

 that I would like to implement.

 reSIProcate has a wider range of SIP capabilities than Sofia SIP.
 Licensing appears compatible for the whole stack.

 Can anybody comment on this?

 In particular, can anybody suggest examples of other connection managers
 for wrapping C++ libraries?

 ___
 telepathy mailing list
 telepathy@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/telepathy

On Wed, Aug 12, 2015 at 1:35 AM, Daniel Pocock dan...@pocock.pro wrote:


 I started documenting a Telepathy connection manager for reSIProcate:

 https://www.resiprocate.org/Telepathy_Connection_Manager

 https://www.resiprocate.org/bugzilla/show_bug.cgi?id=92

 that I would like to implement.

 reSIProcate has a wider range of SIP capabilities than Sofia SIP.
 Licensing appears compatible for the whole stack.

 Can anybody comment on this?

 In particular, can anybody suggest examples of other connection managers
 for wrapping C++ libraries?

 ___
 telepathy mailing list
 telepathy@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/telepathy
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] implementation of new XEP's

[Alexandr Akulich]

On Mon, Jun 8, 2015 at 8:58 PM, Martin Klapetek
martin.klape...@gmail.com wrote:
 TelepathyQt is a library that makes it easy to actually use the spec in 
 Clients.
Especially since the last release, TelepathyQt is more, than just a
library for clients, but it is a convenient thing to implement
Connection Managers as well.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] implementation of new XEP's

[Alexandr Akulich]

I'm sorry, I didn't CC telepathy list, so I have to re-send my message,
to make it visible for all.

Hello.

I can't say for Telepathy-glib, but I'm actively work on TelepathyQt.
Currently I focus on service bindings, but I'm planning to improve
client-side bindings and specifications as well.

Are you speaking about Telepathy specification or about Telepathy
jabber connection manager? I'm very new to the xmpp protocol, but as I
just read, we can mostly (without section 9) enable XEP-0280 support
without changes in the telepathy specs.
XEP-0313 requires something new in our specs. I have to do it for my
Telegram connection manager, but currently it is a long-term goal.

Recently we started development of TelepathyQt-based connection
manager for xmpp protocol. We're based on QXmpp library, which have a
fork which declare XEP-0280/XEP-0313 as implemented. I can't say when
the CM would be done, as there is a number of other insistent
projects.

I organized some of TelepathyQt projects on
https://github.com/TelepathyQt
, so you can watch them if you want.


On Sun, Jun 7, 2015 at 8:25 PM, Steven Roose stevenro...@gmail.com wrote:
 Hi everyone


 I'd like to know if Telepathy is still maintained. There are some new XEP's
 published the last two years and Telepathy didn't implement any of them.

 Especially Message Carbons (XERP-0280) and Message Archive Management
 (XEP-0313). This XEPs make Jabber a lot more usable in a multi-device
 situation. With the advent and popularity of mobile devices, it is quite a
 must to have.

 Since several Jabber clients are implemented using Telepathy, their
 developers are waiting for Telepathy to implement the standards in order to
 be able to support this features in their own products.

 Hopefully this triggers someone to take a look at the new standard documents
 and take some time to implement them. They really take the quality of using
 Jabber to a higher level!
 Myself, I'm not familiar with the Telepathy code, but I'd be happy to help
 by pointing to some existing implementations of the new standards.


 Thanks in advance

 Steven Roose

 ___
 telepathy mailing list
 telepathy@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/telepathy

___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

[Telepathy] [Announce] Telepathy Qt 0.9.6

[Alexandr Akulich]

Tarball:
http://telepathy.freedesktop.org/releases/telepathy-qt/telepathy-qt-0.9.6.tar.gz

Signature:
http://telepathy.freedesktop.org/releases/telepathy-qt/telepathy-qt-0.9.6.tar.gz.asc

The New blood release.

Enhancements:
 * Added TP_QT_VERSION and TP_QT_VERSION_CHECK macros
   - Can be used like #if (TP_QT_VERSION == TP_QT_VERSION_CHECK(0, 9, 6))
   - Absence of the TP_QT_VERSION macros indicates previous versions
 (might be useful for service bindings compatibility)
 * Added client side support for conference calls
 * Implemented numerous interfaces for service bindings

API changes:
 * Refactored service-side bindings API
   - BaseConnection createChannel() and ensureChannel() methods
 now accept request map instead of several extracted values.
   - BaseChannel::create() arguments reordered in natural way.

Fixes:
 * Fixed CallContent interfaces exposing (required for DTMF)
 * fd.0 #86312: Fixed condition in adaptor methods generation
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy