Suggestion about re-usable UI elements

George Kiagiadakis at
Tue Mar 27 20:25:20 UTC 2012

On Tue, Mar 27, 2012 at 10:17 PM, David Edmundson
<david at> wrote:
> On Tue, Mar 27, 2012 at 7:41 PM, Laszlo Papp <lpapp at> wrote:
>> It would be nice to consider the set of UI elements as a separate
>> reusable components in the future. Perhaps for frameworks ?
> Yes, we're doing this. We have common widgets and dialogs, even the
> entire text chat area is (in theory) re-usable.
> The modular nature of approver makes embedding chat into your game
> easy peasy and it should work alongside all the other chat stuff
> running.
> The "internalness" is simply because everything is changing so much.
> If anyone used it, you'd probably get rather annoyed at us changing it
> all the time. Simply add the flag to CMake and you can use it.
> We'll make it public when it stops changing all the time.

I've been chatting a lot with Laszlo about this, answering to his
questions, and from my understanding, the goal for them is *not* to
have a game that integrates with the IM accounts of the underlying
desktop. The goal is rather to have a totally standalone client inside
the game that is managed within the game and does not interfere at all
with the desktop. In this regard, telepathy only serves as an xmpp
library and nothing more than that. I still consider it a valid use
case of telepathy, since it has advantages over using an xmpp library
directly. It is more abstract, easy to use and feature-complete
(killer feature is audio calls, which are useful in a game, but are
really hard to implement without the awesomness of tp-farstream).

So, with that in mind, what would be useful for them is having some
widgets and helper classes to do things easily without reimplementing
them. The contact list widget (without metacontacts, when these are
integrated), libktpchat and libktpcall are valid candidates. Of
course, in the current state it is not easy for them to use them, for
obvious reasons (why on earth should someone install ktp-call-ui to
build gluon?). So, what I think we should do is sit and review all the
stuff that we have, then start moving things in a common public
library, with proper compatibility promises. This can take a while and
I really don't think we can have that before GSoC, but in the long
term we need to consider it and it's probably not too early to start.

More information about the KDE-Telepathy mailing list