Suggestion about re-usable UI elements

[Martin Klapetek]

On Wed, Mar 28, 2012 at 02:55, Daniele E. Domenichelli <
daniele.domenichelli at gmail.com> wrote:

> On 28/03/12 01:59, David Edmundson wrote:
>
>> 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.
>>
>
> Afaik we can have both... Anyway don't worry, we'll discuss it :D
>
>
>
>  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.
>>
>
> I agree, but imho we cannot expose the filtermodel until we have a stable
> api but I think that we cannot have a stable api until we have the .desktop
> files stuff for tubes services.
>
> If you all agree, I think that as soon as we release 0.4 we should start a
> new repo where we should move public stuff after a serious API review and
> get it ready for 0.5 codenamed "stalls"


Please think twice before creating (yet another) repo. Also I'm not really
convinced we need new library that uses our private library inside. We
should instead turn common-internals into a proper library that our
components use and get rid of the "internal". We basically put the
"is_ktp_internal_component" flag only to drive people off from using it for
the time being, so we should just review the api and make it a proper
stable lib.

As for models - I'm for exposing these too. People want a full lib which
they can build stuff on and models are a crucial part of that (you
basically can't build an UI without models or some other way around).

--
Martin Klapetek | KDE Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20120328/f5e56f8b/attachment.html>