<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> On 10/20/2010 02:14 PM, Dario Freddi wrote: <blockquote cite="mid:201010202114.38070.drf54321@gmail.com" type="cite"> <pre wrap="">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. </pre> </blockquote> Good point, we are probably ending up exposing some wrapper object which is more QML friendly, or do some stuff through models we are implementing. Any ideas about better approaches ? Thanks Dario, please check other items as well, your feedback is very valuable :) <blockquote cite="mid:201010202114.38070.drf54321@gmail.com" type="cite"> <pre wrap=""> On Wednesday 20 October 2010 03:57:35 Mateu Batle wrote: </pre> <blockquote type="cite"> <pre wrap=""> 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: <a class="moz-txt-link-freetext" href="http://git.collabora.co.uk/?p=user/paolo/telepathy-qt4.git;a=summary">http://git.collabora.co.uk/?p=user/paolo/telepathy-qt4.git;a=summary</a> cheers Mat </pre> </blockquote> <pre wrap=""> </pre> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ telepathy mailing list <a class="moz-txt-link-abbreviated" href="mailto:telepathy@lists.freedesktop.org">telepathy@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/telepathy">http://lists.freedesktop.org/mailman/listinfo/telepathy</a> </pre> </blockquote> <pre class="moz-signature" cols="72">-- Mateu Batle Software Engineer / Team Leader Collabora Ltd.</pre> </body> </html>