2006/8/6, Goffart <ogoffart (AT) kde (DOT) org>:
Hello.

So we are going soon or later to drop the Q3ListView stuff for the
contactlist.

I have made an experimental contactlist using QAbstractItemModel.

I have to say i'm still not convinced by the supposed advantage of
QAbstractItemModel.
We could as well use QTreeWidget, and have subclass of QTreeWidgetItem for
MetaContactLVI and GroupLVI like we have now.
Could you explain me how having his own model is better ? thanks.

This model is better in the seens that you divide the data, from it's rendering.
This way you can have multiple view using the same model that are
affected when you affect one off the view.
If you look at one of the Qt model/view explanation, you'll see 2 file
list widgets.
When you select one item in the treeview, the selection also affect
the list view.

So do we have a real interest in such features, I would say yes,
because you can also add some filter model layers. And this is
interesting by example for the chat lists. So we have one model for
the contact list, but we may make the view more precise for the chats,
making a *who is in this chat* filter, and then a sort by name filter.
Another thing, if we have a tree view model, we also can use it as a
list view model (limited to one column, and only thee first ?)

And to conclude, the when the wiget interact with model, it knows when
to add/remove it's child Item, and we remove some memory management
problems ;) even if we have 10 views, the views will handle them for
us ;)

--
Anyway, i think that Kopete::ContactList (KCL) and ContactListModel (CLM)
must be two separate class.

I agree, due to the selection model (and maybe other), we must be able
to have multiple KCLM, refering to the KCL singleton.

KCL, in libkopete, is the central storage class (in memory) which make the
interface between protocols, plugins, and the contact list ui

CLM is part of the contact list ui. There is no reason to have it in
libkopete, and let plugins see that.

I would say that plugins have to see it. Like the main application.
Some plugins allow to refine their activity base on plugins account.
And it would be stupid that the plugins have to rewrite code to handle
such lists when we could reuse the libkopete ones

I'm not talking about the storage backend in this mail.
--
Is my attached draft the way to go ? am I completely wrong ?
I'm still discovering the inter view stuff.

For me what you wrote is the way to go. one final comment. Make
an intermediate , and use this
intermediate in all the views.
So that we could provide the real and direct
Kopete::ContactTreeViewModel and maybe somewhere else the
Kopete::DBusContactTreeView model (to finally allow remote view, for
cheap, and maybe even with the selection model updated every where)

I don't want to start a troll for that again, but it would be great to
separate the ui code from the main code again. thougth it will
requires us some effforts. And maybe we should also go for the kcm way
in the protocols also. In fact protocols don't really need to know
about how it's data will be represented. (icon status should be left
to application decision and for the buddy pictures it can be handled
as raw data in the protocols)

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

>

So do we have a real interest in such features, I would say yes,
because you can also add some filter model layers. And this is
interesting by example for the chat lists.

That's an interesting point.
Could we share the main contactlist model with the chatwindow member list
model.

Indeed: there are similarities:
- It would be nice if the item would look the same
- they probably should have a similar context menu

But on the other hand:
- It's not the same contact: We will not add all IRC or Jabber MUC contact on
the contactlist[1]
- They are not stored by groups.
- We don't want to share the selection.
- They probably should not look exactly the same

This is a sorting and presentation problem it can be done by adding
some filter models.
And we can have multiple contact list. A contact list is a list after
all. We have THE VERY contact list with persistance, and the chat
contact lists. Anyway this can be seen as a huge list containing all
the contacts, and we filter it depending on some criteria, since THE
VERY contact can be filtered by a boolean or somthing to rebuild it.
And then THE VERY contact list be a view of the all contact list.

So we have one model for
the contact list, but we may make the view more precise for the chats,
making a *who is in this chat* filter, and then a sort by name filter.
Another thing, if we have a tree view model, we also can use it as a
list view model (limited to one column, and only thee first ?)

We can do sorting even of a QTreeWidget

And to conclude, the when the wiget interact with model, it knows when
to add/remove it's child Item, and we remove some memory management
problems ;) even if we have 10 views, the views will handle them for
us ;)

What do you mean ?
We don't have memory management model in our current contactlist

I know, but the view will handle the items creations no need to know
when it's necessary to create and delete the pointers, the view will
call do that for us.

KCL, in libkopete, is the central storage class (in memory) which make
the interface between protocols, plugins, and the contact list ui

CLM is part of the contact list ui. There is no reason to have it in
libkopete, and let plugins see that.

I would say that plugins have to see it. Like the main application.
Some plugins allow to refine their activity base on plugins account.
And it would be stupid that the plugins have to rewrite code to handle
such lists when we could reuse the libkopete ones

Can you give me one example of such list ?

Maybe I mixed something here, but it can be can be interesting to
allow some plugins to not be global. So such plugin should be able to
select contact where to apply the plugin (some kind of tree of check
boxes)
example would be Javascript :D where you could allow some contacts
to use it remotely, and some not. a spell cheking based on the
nationality of your peers

Plugins only interact with the main contactlist.
The only thing they need to know is the selection, for
1- enabling/disabling actions according the selections
2- do the action on the selected contact.

But we have that in libkopete with

The contact list don't have to know wich elements are selected, the
selection of elements belongs to the model. ContactList is simply a
list after all, the model know how to interact with the list, and know
how to call actions to the selecteds contacts.

--
For me what you wrote is the way to go. one final comment. Make
an intermediate , and use this
intermediate in all the views.
So that we could provide the real and direct
Kopete::ContactTreeViewModel and maybe somewhere else the
Kopete::DBusContactTreeView model (to finally allow remote view, for
cheap, and maybe even with the selection model updated every where)

For DBus, we don't need a Model, but a DBusInterface.
Model are really tight to the UI

The DBusInterface would be with the Kopete::ContactTreeViewModel and
the DBusContactTreeView would know how to interact with this one (act
like a proxy).

So with the main application we have
KCL <=KCTVM <=KCTVWidget
And on a remote case
KCL <=KCTVM <=dbus=KDBusCTVM <=KCTVWidget

So we can reuse the same code for kparts ;) and that way all the
widgets looks the same.

And the selection model can't (AFAIK) be shared between applications as it
(And why want we share the selection ?)

So that all the view behave the same way. You have one view on the
main app and one on the desktop, if you click to prepare one action
and have to hide it, you would like to see the one on the desktop
allready clicked.

Maybe it also requires some QItemSelectionModel work with dbus and can
be done in a second step, with the same proxying trick.

I don't want to start a troll for that again, but it would be great to
separate the ui code from the main code again. thougth it will
requires us some effforts.

Please see my other mail :-)

And maybe we should also go for the kcm way
in the protocols also.

What is the kcm way ?

the way the plugins are splitted in to libs, the main plugin, and the
kcm part to control it via the gui.

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

Le dimanche 6 2006 12:00, Michel Hermier a *:

This is a sorting and presentation problem it can be done by adding
some filter models.

doing two completely different models
( using QTreeWidget without model)
I can assure you there will be not duplicated code.

[]

I'm not saying that we should not use the Model/View stuff.
But I still doesn't see the need of it.

No need to rush on that technology because it's new fashion in Qt.

We could simply use a QTreeWidget with LVI like this is done.
It seems it covers all our need, and is much simpler.

I don't want to start a troll for that again, but it would be great to
separate the ui code from the main code again. thougth it will
requires us some effforts.

Please see my other mail :-)

And maybe we should also go for the kcm way
in the protocols also.

What is the kcm way ?

the way the plugins are splitted in to libs, the main plugin, and the
kcm part to control it via the gui.

I see no reason to do that.

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

PGP SIGNATURE
Version: GnuPG v1.4.4 (GNU/Linux)

vmDR7swYjGhc/wQh8SsrQlM=
=eaNA
PGP SIGNATURE

Le dimanche 6 2006 17:07, M Larouche a *:
Le August 6, 2006 07:54, Goffart a *:
I'm not saying that we should not use the Model/View stuff.
But I still doesn't see the need of it.

No need to rush on that technology because it's new fashion in Qt.

We could simply use a QTreeWidget with LVI like this is done.
It seems it covers all our need, and is much simpler.

Yes I agree that Interview is a big beast and the learning curve is high.
I still didn't catch the whole concept of this new framework.

thing for sure, it will save us maintainability in lorg term and will
give us more power and flexibility.

For sure ?

It seems more complex.
And more complex = harder to maintain.

From the Qt documentation: (QTreeWidget)

|The QTreeWidget class provides a tree view that uses a predefined tree model.
|The QTreeWidget class is a convenience class that provides a standard tree
|widget with a classic item-based interface similar to that used by the
|QListView class in Qt 3. []
|Developers who do not need the flexibility of the Model/View framework can
|use this class to create simple hierarchical lists very easily. A more
|flexible approach involves combining a QTreeView with a standard item model.
|This allows the storage of data to be separated from its representation.

What is this flexibility that we need ?

Note that our storage data is already separated from it's representation in
the Kopete::ContactList

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)

53GkIso2w4V9DQNYE=
=PQaM
PGP SIGNATURE

For me what you wrote is the way to go. one final comment. Make
an intermediate , and use this
intermediate in all the views.
So that we could provide the real and direct
Kopete::ContactTreeViewModel and maybe somewhere else the
Kopete::DBusContactTreeView model (to finally allow remote view, for
cheap, and maybe even with the selection model updated every where)

You are a bit wrong, D-BUS should in a model (or in a storage) not in a view.

But yes, it should be nice to save differents types of view (list, tree) that
use common drawing code.

I meant , the view code would be
the same using the same Kopete::ContactTreeView.

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

Aaron J. Seigo wrote:
Sunday 06 August 2006 10:30, Goffart wrote:

>Le dimanche 6 2006 17:07, M Larouche a :
>
thing for sure, it will save us maintainability in lorg term and will
give us more power and flexibility.

>For sure ?
>>
>It seems more complex.
>And more complex = harder to maintain.
>
>
actually, once you write a model it's pretty near zero maintenance for the
model and you can switch view methods much, much easier since they data is
not tied to the view at all.

by keeping the data coupled to the view, you will never be able to experiment
too wildly with views and uses of that data because the effort of doing so
will be too high.

this approach also introduces complexity in the form of having to manage both
data and view in one place. the complexity of the MV approach is party a
perception thing due to being new (meaning we have to learn things) and only
partly due to actually being more complex.


>What is this flexibility that we need ?
>>
>Note that our storage data is already separated from it's representation in
>the Kopete::ContactList
>
>
and the contactlist data structure ought to be able to feed directly into
views.

one of the use cases kopete will run into is being able to bridge the contact
data to lists that appear on the desktop or in other applications. identity
is moving more and more towards sharing and coordinating this data between
multiple apps. having a model that is simultaneously what feeds the views and
is what is coordinated with these external sources will almost certainly keep
things simpler over the long haul.

of course, this isn't my app i'm not designing it, writing it, etc. so
yeah. i'm just an annoying bystander who very occasionally submits patches ;)

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

WILL YU PLEASE STP SENDING ME EMAILS?IV'E HAVE ASKED YU NICELY AND
YU TAKE N NTICE.THATS WHY I'M SHUTING!

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

Hi Aaron, thanks for your reply.

Le dimanche 6 t 2006 21:47, Aaron J. Seigo a *:
Sunday 06 August 2006 10:30, Goffart wrote:

by keeping the data coupled to the view, you will never be able to
experiment too wildly with views and uses of that data because the effort
of doing so will be too high.

this approach also introduces complexity in the form of having to manage
both data and view in one place. the complexity of the MV approach is party
a perception thing due to being new (meaning we have to learn things) and
only partly due to actually being more complex.

I think understand this. But I think this is already the case in Kopete,
without the need of a QAbstactItemModel stuff and all theses QModelIndex.

what's the difference ? (I'm asking to Matt, Michel and Ml)

Note that our storage data is already separated from it's representation
in the Kopete::ContactList

and the contactlist data structure ought to be able to feed directly into
views.

What do you mean ?

one of the use cases kopete will run into is being able to bridge the
contact data to lists that appear on the desktop or in other applications.
identity is moving more and more towards sharing and coordinating this data
between multiple apps.

And that's one important topics.

But I fail to see how QAbstractItemModel helps.

What we need here is a defined dbus interface.

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)

hEMwcIeTo1ZZKakXUdi5L3Q=
=T4Hz
PGP SIGNATURE

Monday 07 August 2006 01:12, Michel Hermier wrote:
2006/8/7, Matt Rogers <mattr (AT) kde (DOT) org>:
Sunday 06 August 2006 02:09, Michel Hermier wrote:
2006/8/6, Goffart <ogoffart (AT) kde (DOT) org>:
Hello.

So we are going soon or later to drop the Q3ListView stuff for the
contactlist.

I have made an experimental contactlist using QAbstractItemModel.

I have to say i'm still not convinced by the supposed advantage of
QAbstractItemModel.
We could as well use QTreeWidget, and have subclass of
QTreeWidgetItem for MetaContactLVI and GroupLVI like we have now.
Could you explain me how having his own model is better ? thanks.

This model is better in the seens that you divide the data, from it's
rendering. This way you can have multiple view using the same model
that are
affected when you affect one off the view.
If you look at one of the Qt model/view explanation, you'll see 2 file
list widgets.
When you select one item in the treeview, the selection also affect
the list view.

So do we have a real interest in such features, I would say yes,
because you can also add some filter model layers. And this is
interesting by example for the chat lists. So we have one model for
the contact list, but we may make the view more precise for the chats,
making a *who is in this chat* filter, and then a sort by name filter.
Another thing, if we have a tree view model, we also can use it as a
list view model (limited to one column, and only thee first ?)

And to conclude, the when the wiget interact with model, it knows when
to add/remove it's child Item, and we remove some memory management
problems ;) even if we have 10 views, the views will handle them for
us ;)

Anyway, i think that Kopete::ContactList (KCL) and ContactListModel
(CLM) must be two separate class.

I agree, due to the selection model (and maybe other), we must be able
to have multiple KCLM, refering to the KCL singleton.

The views handle the selection. What are you talking about here?

I speak about usability when you have multiple view of the contact
list model. may have the contact list view in Kopete and in
another program (Kontact, plasmoid ) When clicking on one of the
view the selections of other view should be affected I think.

I disagree. Let's say that we have a plasmoid that gives us easy access to the
kopete contact list running and we also have kopete running as well. They are
two seperate entities. If I change the selection in the main application, as
a user, I do not expect the selection to change in the plasmoid. IMH, your
idea above is actually worse for usability, but we should ask the usability
people to know for sure. :)

KCL, in libkopete, is the central storage class (in memory) which
make the interface between protocols, plugins, and the contact list
ui

CLM is part of the contact list ui. There is no reason to have it in
libkopete, and let plugins see that.

I would say that plugins have to see it. Like the main application.
Some plugins allow to refine their activity base on plugins account.
And it would be stupid that the plugins have to rewrite code to handle
such lists when we could reuse the libkopete ones

I'm not talking about the storage backend in this mail.
--
Is my attached draft the way to go ? am I completely wrong ?
I'm still discovering the inter view stuff.

For me what you wrote is the way to go. one final comment. Make
an intermediate , and use this
intermediate in all the views.
So that we could provide the real and direct
Kopete::ContactTreeViewModel and maybe somewhere else the
Kopete::DBusContactTreeView model (to finally allow remote view, for
cheap, and maybe even with the selection model updated every where)

I don't want to start a troll for that again, but it would be great to
separate the ui code from the main code again. thougth it will
requires us some effforts. And maybe we should also go for the kcm way
in the protocols also. In fact protocols don't really need to know
about how it's data will be represented. (icon status should be left
to application decision and for the buddy pictures it can be handled
as raw data in the protocols)

I'm sure a split between core/gui will happen eventually. Just be
patient. --
Matt

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

2006/8/7, Matt Rogers <mattr (AT) kde (DOT) org>:
Monday 07 August 2006 01:12, Michel Hermier wrote:
2006/8/7, Matt Rogers <mattr (AT) kde (DOT) org>:
Sunday 06 August 2006 02:09, Michel Hermier wrote:
2006/8/6, Goffart <ogoffart (AT) kde (DOT) org>:
Hello.

So we are going soon or later to drop the Q3ListView stuff for the
contactlist.

I have made an experimental contactlist using QAbstractItemModel.

I have to say i'm still not convinced by the supposed advantage of
QAbstractItemModel.
We could as well use QTreeWidget, and have subclass of
QTreeWidgetItem for MetaContactLVI and GroupLVI like we have now.
Could you explain me how having his own model is better ? thanks.

This model is better in the seens that you divide the data, from it's
rendering. This way you can have multiple view using the same model
that are
affected when you affect one off the view.
If you look at one of the Qt model/view explanation, you'll see 2 file
list widgets.
When you select one item in the treeview, the selection also affect
the list view.

So do we have a real interest in such features, I would say yes,
because you can also add some filter model layers. And this is
interesting by example for the chat lists. So we have one model for
the contact list, but we may make the view more precise for the chats,
making a *who is in this chat* filter, and then a sort by name filter.
Another thing, if we have a tree view model, we also can use it as a
list view model (limited to one column, and only thee first ?)

And to conclude, the when the wiget interact with model, it knows when
to add/remove it's child Item, and we remove some memory management
problems ;) even if we have 10 views, the views will handle them for
us ;)

Anyway, i think that Kopete::ContactList (KCL) and ContactListModel
(CLM) must be two separate class.

I agree, due to the selection model (and maybe other), we must be able
to have multiple KCLM, refering to the KCL singleton.

The views handle the selection. What are you talking about here?

I speak about usability when you have multiple view of the contact
list model. may have the contact list view in Kopete and in
another program (Kontact, plasmoid ) When clicking on one of the
view the selections of other view should be affected I think.

I disagree. Let's say that we have a plasmoid that gives us easy access to the
kopete contact list running and we also have kopete running as well. They are
two seperate entities. If I change the selection in the main application, as
a user, I do not expect the selection to change in the plasmoid. IMH, your
idea above is actually worse for usability, but we should ask the usability
people to know for sure. :)

Now that I think again I would say it's bad, anyway it doesn't have to
deal with model.
I first thougth the model was also handling the selection and I was wrong.

KCL, in libkopete, is the central storage class (in memory) which
make the interface between protocols, plugins, and the contact list
ui

CLM is part of the contact list ui. There is no reason to have it in
libkopete, and let plugins see that.

I would say that plugins have to see it. Like the main application.
Some plugins allow to refine their activity base on plugins account.
And it would be stupid that the plugins have to rewrite code to handle
such lists when we could reuse the libkopete ones

I'm not talking about the storage backend in this mail.
--
Is my attached draft the way to go ? am I completely wrong ?
I'm still discovering the inter view stuff.

For me what you wrote is the way to go. one final comment. Make
an intermediate , and use this
intermediate in all the views.
So that we could provide the real and direct
Kopete::ContactTreeViewModel and maybe somewhere else the
Kopete::DBusContactTreeView model (to finally allow remote view, for
cheap, and maybe even with the selection model updated every where)

I don't want to start a troll for that again, but it would be great to
separate the ui code from the main code again. thougth it will
requires us some effforts. And maybe we should also go for the kcm way
in the protocols also. In fact protocols don't really need to know
about how it's data will be represented. (icon status should be left
to application decision and for the buddy pictures it can be handled
as raw data in the protocols)

I'm sure a split between core/gui will happen eventually. Just be
patient. --
Matt

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

Aaron J. Seigo wrote:
Sunday 06 August 2006 15:52, Goffart wrote:

and the contactlist data structure ought to be able to feed directly into
views.

>What do you mean ?
>
>
having a data structure for contacts, a view and then a bridge between those
two that needs to maintained is not necessary these days.

we have the ability to provide a data model and tell a view "show this model"
and with 0 work to show that model in the view have it shown.

this means when you modify the data structures the views (which may not be
visual, btw) are updated as there is no sync issue to do with data<->view
bridges.

one of the use cases kopete will run into is being able to bridge the
contact data to lists that appear on the desktop or in other
applications. identity is moving more and more towards sharing and
coordinating this data between multiple apps.

>And that's one important topics.
>>
>But I fail to see how QAbstractItemModel helps.
>>
>What we need here is a defined dbus interface.
>
>
the dbus interface would interface to the data structure. if someone removes a
contact via dbus and the data structure is a QAM then the visual views will
update automatically.

no manually synchronizing changes from out of the GUI with the GUI. no
manually synchronizing changes in 2 views with the data structures and each
other. etc

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

I'VE BEEN NICE AND YU STILL SEND ME EMAILS.WILL YU STP R D I HAVE
T KICK YUR HEAD IN?WILL YU STP?GET THE MESSAGE.

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org