Suggestion about re-usable UI elements

[David Edmundson]

On Wed, Mar 28, 2012 at 12:37 AM, Daniele E. Domenichelli
<daniele.domenichelli at gmail.com> wrote:
> On 27/03/12 22:25, George Kiagiadakis wrote:
>>
>> 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).
>
>
>
> If I understand this correctly, the only way to implement this is to run
> telepathy on a private dbus... But why do you want to do that if the user
> has an account already configured on his desktop?
>
>
>
>> 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.
>
>
>
> I think this is definitely the plan in the long way... I was thinking about
> making the text widget a KPart and move it in a _public_ library before 0.4,
> but time run out very quickly (and that's all fault of our evil release
> manager)

I want to discuss this KPart business first (poke me on jabber). What
I don't want is to have an app, (the collaborative editor for example)
which only wants a cheeky little text chat widget in the corner
suddenly to have a billion things littering the toolbars and menubars
many some which won't really make a lot of sense and possibly even
duplicate with the containing app. Though the current Text UI does
need its public interface sorting out a bit.

Right now, no-one has tried putting the Text UI in another app so
no-one can say it's broken and needs changing, but we can't say it
works great either.

Anyway, that's off topic.

>
> Anyway for 0.5 I would like to have a "high level" public widget library
> that uses ktp-common-internals internally, but exposing only "stable" stuff
> and hiding all the models and contacts/metacontacts stuff. Basically the
> stuff in the "KTp/Widgets" directory of ktp-common-internals (that depends
> on the KTp and KTp/Models directories) should be public. For example the
> grid widget can be modified so that the interface exposed won't change if we
> change the model inside; What do you think?
>
Widgets are fine, and we are working towards that I think. Grid model
is exposed and I have an open bug that a treeview needs go in there
too.
Less convinced on completely hiding the models (especially the filter
model) to me isn't the right way. We'd have to expose every method in
there to every UI view.. which is a lot of maintenance.


> And unfortunately no, this won't be ready for GSoC but we are (I am?) really
> interested in knowing which parts do you actually need, so if you feel
> brave, consider starting using the common-internals library, telling us what
> you actually need and what you miss so that we can try to make that part
> "stable" before next release
>

+1. We have stuff. Try it, if you need anything else tell us what you
need on a more specific basis and we'll sort it out.
Plasma stuff is being exposed as QML declarative plugins.

>
> Cheers,
>  Daniele
>
>
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy