[Telepathy] QMLizing telepathy-qt4
kiagiadakis.george at gmail.com
Tue Oct 26 10:46:29 PDT 2010
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
> * 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
> * 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...?
> * 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.
> * 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
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...
> * 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".
> * 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.
> * 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
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.
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:
(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...)
More information about the telepathy