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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
