[Telepathy] QMLizing telepathy-qt4

[Dario Freddi]

Hi,

Not really commenting on each point as I have to analyze them in more depth - 
I'll write a longer mail later (probably tomorrow). However, how are you going 
to handle the shared pointer model when exposing data to QML? Tp-Qt4 is not 
really based on QObject at all from this point of view, and I think this is 
probably the most tricky bit - as we never expose QObjects directly to the 
outer world.

On Wednesday 20 October 2010 03:57:35 Mateu Batle wrote:
>  Hi folks,
> 
> Content of this email is just for those interested in telepathy-qt4 and
> QML.
> 
> I wanted to start some discussion and join efforts on the development of
> some common code that would be needed to build telepathy applications
> with QML. We have started to do some work on this, aiming for this to be
> integrated in upstream tp-qt4, it would be an optional lib that can be
> used if required. Also since it seems there will be a some ABI break in
> future version, it might be a good moment to introduce some things that
> make work easier.
> 
> First a bit of justification, but I assume you know already some QML.
> Basically QML paradigm is more optional and geared to work with data (Qt
> properties and Qt models) than calling getting info through calling
> methods. Thanks to Qt object model some things in tp-qt4 are already
> available from QML, but that is not enough. There are few more things
> that need to be done. The following list is just general list of things
> to do when QMLizing an API:
> 
> * Information is not obtained from a property, normally we are
> interested in getting stuff from properties so we can bind QML to those
> data items. And everything is updated automatically on changes.
> 
> * Same things for methods to set values, these should be properties.
> 
> * Implement NOTIFY signal support for properties in order to allow
> binding to work.
> 
> * Expose some item containers like QAbstractItemModel. They must support
> automatic sync through the standard signals mechanisms in Qt models.
> Edit data must be also supported.
> 
> * Some needed stuff exposed as non-QObjects are not accesible from QML
> like Tp::SimplePresence. So this info has to be exposed somehow.
> 
> * Sometimes information is a bit scattered through different places, it
> might be better to do a bit more of aggregation around important objects
> like Account, Contact, ...
> 
> * Access to methods from QML. Q_INVOKABLE or slots are needed for this
> to work.
> 
> Note that some of them are already done that way in some tp-qt4 classes,
> but not in others.
> 
> 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.
> 
> * Contact Model for each account. Automatic sync on changes, edit support.
> 
> * Conversation Model. Basically a list of messages of the conversation
> with a contact with texts, timestamps, contact.
> 
> * QML Image provider for contact and account avatar.
> 
> * 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.
> 
> * 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.
> 
> * 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.
> 
> * 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.
> 
> * 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, ...
> 
> * 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.
> 
> Some of this stuff has already been started and we are progressing quickly.
> So, it is important to give feedback ASAP.
> You can check what has been done already by Paolo and Alvaro in:
> 
> http://git.collabora.co.uk/?p=user/paolo/telepathy-qt4.git;a=summary
> 
> cheers
>   Mat

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20101020/c0e11798/attachment.pgp>