[Telepathy] QMLizing telepathy-qt4

Tue Oct 26 23:20:37 PDT 2010

 On 10/26/2010 12:46 PM, George Kiagiadakis wrote:
> On Wed, Oct 20, 2010 at 4:57 AM, Mateu Batle
> <mateu.batle at collabora.co.uk> wrote:
>>  Hi folks,
>>
>> Content of this email is just for those interested in telepathy-qt4 and QML.
>>
> [...]
>> After reviewing a bit the API we have detected the following things that
>> could be done, see list below. We think all these stuff is common to any
>> telepathy IM application written in QML.
>>
>> * Account Model. Automatic sync on changes, edit support.
> I think this is a good idea. I have been thinking about having models
> in tp-qt4... I guess nearly everybody who wants to show accounts in a
> list, even without QML, has to implement a model. I've done that in
> KCall and our KDE accounts manager is also doing that. Having an
> upstream implementation that takes care of everything is something
> that many people will appreciate, no matter whether they are using QML
> or not.
>
>> * Contact Model for each account. Automatic sync on changes, edit support.
> A good idea as well, but this is not so much reusable because I guess
> that people will also want metacontacts support, which is something
> that at the moment clients provide with a custom implementation.
> Empathy uses libfolks, Telepathy-KDE uses nepomuk. If you also would
> like metacontacts support in your project, even if you are not going
> to add it right now, I guess that you will need to copy the model in
> your client and modify it. Unless of course you can do that with a
> proxy model, but at least in KDE we cannot do that with the current
> design.
>

Right, I don't know much about metacontacts but I guess they would be
handled by a separate model.
Anyway currently I think metacontacts are out of the scope of tp-qt4.

>> * Conversation Model. Basically a list of messages of the conversation
>> with a contact with texts, timestamps, contact.
> Probably useful for a QML application, not sure about other uses.
>
>> * QML Image provider for contact and account avatar.
> Yeah, we definitely need that. How do you plan to implement this? Does
> QML provide any kind of API to provide icons to it (something like
> KIcon/KIconLoader for example), or...?

Actually it turns out that it might not be needed, since a filename is
already provided by tp-qt4 in AvatarData class through Contact.
QML can use the file directly to show the contact avatar.

I have a doubt about the about the avatar for an account since it
exposes just a QByteArray through Avatar struct, no filename in this
case ...

>> * Tp::Contact, convert more to Qt style, with properties with notify, etc.
>> So important stuff is accessible from QML. Not sure if we can break ABI.
> Maybe... However, I would like to know the answer to what Dario asked
> in a previous mail. How are you going to deal with reference
> counting/shared pointers in QML? I guess that you can't do that, so in
> my opinion it would be better to expose all the contact information
> within the model and not by exposing the contact objects themselves.

You're right. We will not end up using Contact directly, so this is not
needed.
I agree with exposing contact information through the model.

>> * Add "non-user messages" to the conversation model, not sure how they are called in tp world.
>> I mean things like X joined the conversation, Call started at hh:mm,
>> Call ended at hh:mm duration hh:mm, X FIle being transfered, etc.
>> These require also a timestamp, contact, the type of non-user message,
>> and probably extra information depending on the type (duration of calls, filename on file transfers, etc.).
>> All IM applications show this basically, so it makes sense to have this in TP-QT4.
>> It should be possible to filter (model filters) which ones we want to see for example.
>> I think having them in the conversation model makes easier for QML IM apps to use them.
>> These non-user messages would be for any channels related with a contact (/ group conversation),
>> including file transfers, audio and video calls, text chat.
>> The proper string to show for the non-user message is probably application specific.
>> Also probably the IM application want to show with a different UI each of these events,
>> but all in the same log. For example, showing accept / reject on an ongoing file transfer, etc.
> Hmm... you are mixing things up here. It makes some sense, but I'm not sure.
>
> OK, for a text channel, information like who joined and who left is
> easy and straightforward. If your ConversationModel wraps a text
> channel and acts as a handler for it, then there is no problem.
>
> Things like call ended, file being transfered, etc are not part of a
> text channel, though. A call is a completely different type of
> channel, and so is a file transfer. You would need your
> ConversationModel to be a handler for all channel types to be able to
> do that, but the actual handler needs to do other stuff as well.
> Perhaps an observer can do it, but then, since you can't really
> register the observer inside the class (because it needs a d-bus name
> and client file, etc), the client code will need to implement the
> observer and then pass the channels to ConversationModel, so that it
> can log things. It may work, but I think the design is complicated and
> covers a very specific use case, so I don't think that's worth being
> in tp-qt4.

I agree it is complicated :)

Although I still think it would be useful to provide some higher level
abstraction
for typical IM applications. That indeed is the reason of aggregating at
some level
these different types of channels. Although as you said, it is complicated.

> As for accepting/rejecting a file transfer, that's an approver and it
> definitely needs to be in the client code as well. Whatever I said
> above applies here too.
>
>> * Note these messages and conversation model is also related with tp-logger,
>> which still does not have a Qt wrapper AFAIK.
>> Anyway the current Conversation model would be just for current session, at least for now,
>> so no persistence at all included here, that belongs to another layer.
>> Later on we could expose tp logger conversations with same model interface though.
> Logging is yet another thing...  A logger is also an observer, I'm not
> sure what you have in mind here...

Basically what we described in the previous item could be considered a
logger
for current session, so just it makes sense to maintain the model
interface.
Accessing the logger would provide information from multiple sessions,
since the logger is the responsible of persisting the information.

>> * Another type of "non-user messages" could be added too for more ephemeral stuff like
>> "X is typing". "X calling", "X is sending you a message". This kind of messages are short-lived
>> and they will be removed from the log after they finish, or substituted by others
>> depending on user actions like "Call started at hh:mm", "Call rejected at hh:mm".
>> It would be great to support these too well integrated with the rest.
> If you leave aside all that I've said above about this kind of
> messages, I wonder, how useful would it be to have such things. Ok, "X
> is typing" is fine for a text channel and assuming that the model is
> all about a text channel, but "X is calling" ? in the model? why? In
> case somebody is calling you need an approver that will popup
> something or bling or ring or whatever and let the user accept/reject
> it. It has no purpse inside a text chat in my opinion, and it is a
> completely different thing than "X is typing".

Maybe right, I was thinking in the same style as I said before,
provide some higher level abstractions that are easier to use from QML.
Maybe these abstractions are a bit app specific though,
so it is not something to discuss here.

>> * Also related with the last items, there is some kind of summary of the conversation log.
>> It would be useful to give some aggregated information for all the stuff in the Conversation Model.
>> It would be like counters or booleans in some case for things like number of number of messages unread,
>> ongoing audio/video call,  number of ongoing file transfers, number of missed calls, ...
> Makes some sense, but this is more related to the status of a specific
> client rather than information that telepathy provides.
>

Yeah, consider I'm quite new to telepathy, so I might not have the same
vision about
what is inside tp scope or not. Luckily, these discussions help me to
understand a bit better.

>> * Most of the past items were related to data access, but there is also some work on the method side as well.
>> Making sure that text chat / AV calls / file transfer can be accessed from QML. Including the access to the
>> async objects like Tp::PendingOperation, etc. Not have thought much about this yet,
>> but it would be nice if this can be accessed easily from QML as well,
>> and useful for all IM applications built with QML.
> I doubt that this is a good idea. Having pending operations exported
> in javascript would be overkill. The purpose of QML is to define the
> UI in a declarative way, not to implement everything in it. I would
> suggest to use C++ classes that implement the core functionality
> internally and export only the things that the UI needs to know
> through signals and properties.

I agree.

> This is for example what I am doing now in telepathy-kde-call-ui,
> where I have written some classes that are meant to implement all the
> call functionality internally and export only a few things to the QML
> UI that I plan to write. You can have a look here to get an idea:
>
> http://gitweb.kde.org/clones/telepathy-call-ui.git/gkiagia/telepathy-call-ui.git/tree/ba32159471aad23f368a24018dff5d3f19ec2444:/libtelepathy-kde-call
> (this is currently the latest version, not master)
>
> Check callchannelhandler.h (the main class) and callparticipant.h.
> It's not really there yet (needs some more Q_INVOKABLEs, some
> properties, etc), but I hope you get the idea.
>
> (PS: The implementation is crap, do not be tempted to copy it :P I
> will rewrite it in time to work with the Call interface (which is
> finally getting there, yay!) and probably make it qt-only for general
> use... I'll see...)
>
> Best regards,
> George
> _______________________________________________
> telepathy mailing list
> telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy

Great feedback George, thanks a lot !

cheers
  Mat

-- 
Mateu Batle
Software Engineer / Team Leader
Collabora Ltd.