Qt-interest Archive, August 2006
[Qt4.1] Model/View Design and Use (QTree)
Message 1 in thread
First, let me say I *really* like the Qt4 Model/View architecture,
and find it extremely flexible and very well designed. IMHO, it's yet
another example of world-class architecture found in Qt, superior
to existing alternatives, that justifies our purchase of commercial
Qt licenses (and we'll be buying more).
I have some issues, possibly related to my lack of understanding:
* I don't see any way to trigger a node "refresh" when the user
attempts to "expand" in a QTreeView. You can intercept
QTreeView::mousePressEvent(), but you can't determine if
the event was on the "+" decoration to see if it's an attempt
to expand/collapse (and that seems like a funny place anyway).
What I'd like is a *virtual* QTreeView::expand(), or a signal
QTreeView::aboutToExpand() (since the existing signal
QTreeView::expanded() is too late). This issue was raised
in the archives with no sufficient solution, IMHO:
<http://lists.trolltech.com/qt-interest/2006-08/thread00282-0.html>
Suggestions?
* I find it a little strange that the "QAbstractItemModel::hasChildren()"
is *sometimes* used to determine if there are children, but
after some on-demand caching, it appears the actual "count" of
reported children is later used (and you can't "lie" about this number
in MyModel::rowCount(), or Bad Things Happen). This means that I
lose my "+" decoration on the node, when in fact I want it to remain
because a user "expand node" operation should trigger a "refresh"
(to possibly add children under the node on-demand).
* I'm trying to implement a behavior where user "double-clicking"
on a node will expand/collapse that node by default or do
some other operation (like "launch" an application), but have
a "delayed-second-click" cause the node to be renamed (the
exact behavior found in WindowsExplorer). I'm assuming there's
a simple way to do this, but that I don't understand how to
customize MyQItemDelegate to create the editor widget under
this specific scenario (and to trigger an expand/collapse
operation under the double-click scenario). I'll keep looking at
that, but am open to suggestions. ;-))
QUESTION: I like the model/view architecture, and don't need
(nor want) significant interface changes. Is this design considered
"stable and final", or are little changes under consideration, or
what other design considerations are in the wind? It's sufficiently
big and new and unique (from Qt3 to Qt4) that I could understand
any of the above (I'm just trying to understand its context so I can
best leverage it).
Thanks!
--charley
--
[ signature omitted ]
Message 2 in thread
On 19.08.06 15:40:19, Charley Bay wrote:
> Is this design considered "stable and final", or are little changes
> under consideration, or what other design considerations are in the
> wind? It's sufficiently big and new and unique (from Qt3 to Qt4) that
> I could understand any of the above (I'm just trying to understand its
> context so I can best leverage it).
I can't answer any of the other question (didn't work with customized
tree models yet), but this one's rather easy: Have a look at Qt4.2 TP or
snapshots. TT will change quite some stuff for 4.2, due to the needs of
KDE4 and I think there are some changes in the model/view architecture
too. I'm not sure though how deep these changes go, I don't think that
the overall design of the related classes will change, but I think
TT added couple of methods to ease the use of the classes and make them
more flexible, without the need to subclass...
Andreas
--
[ signature omitted ]
Message 3 in thread
On Sunday 20 August 2006 01:33, Andreas Pakulat wrote:
> On 19.08.06 15:40:19, Charley Bay wrote:
> > Is this design considered "stable and final", or are little changes
> > under consideration, or what other design considerations are in the
> > wind? It's sufficiently big and new and unique (from Qt3 to Qt4) that
> > I could understand any of the above (I'm just trying to understand its
> > context so I can best leverage it).
>
> I can't answer any of the other question (didn't work with customized
> tree models yet), but this one's rather easy: Have a look at Qt4.2 TP or
> snapshots. TT will change quite some stuff for 4.2, due to the needs of
> KDE4 and I think there are some changes in the model/view architecture
> too. I'm not sure though how deep these changes go, I don't think that
> the overall design of the related classes will change, but I think
> TT added couple of methods to ease the use of the classes and make them
> more flexible, without the need to subclass...
>
> Andreas
In particular one nice thing to check out is the new API for
QStandardItemModel, it includes a full item based API now. So if you want to
use QSortFilterProxyModel, but you were using QTreeWidget it shouldn't be too
much trouble to convert.
-Benjamin Meyer
--
[ signature omitted ]
Message 4 in thread
On Sunday 20 August 2006 00:40, Charley Bay wrote:
> First, let me say I *really* like the Qt4 Model/View architecture,
> and find it extremely flexible and very well designed. IMHO, it's yet
> another example of world-class architecture found in Qt, superior
> to existing alternatives, that justifies our purchase of commercial
> Qt licenses (and we'll be buying more).
>
> I have some issues, possibly related to my lack of understanding:
>
> * I don't see any way to trigger a node "refresh" when the user
> attempts to "expand" in a QTreeView. You can intercept
> QTreeView::mousePressEvent(), but you can't determine if
> the event was on the "+" decoration to see if it's an attempt
> to expand/collapse (and that seems like a funny place anyway).
> What I'd like is a *virtual* QTreeView::expand(), or a signal
> QTreeView::aboutToExpand() (since the existing signal
> QTreeView::expanded() is too late). This issue was raised
> in the archives with no sufficient solution, IMHO:
> <http://lists.trolltech.com/qt-interest/2006-08/thread00282-0.html>
> Suggestions?
In 4.2 right before a node is expanded fetchMore() will be called on the
index. You can use this to populate your data then.
> * I find it a little strange that the "QAbstractItemModel::hasChildren()"
> is *sometimes* used to determine if there are children, but
> after some on-demand caching, it appears the actual "count" of
> reported children is later used (and you can't "lie" about this number
> in MyModel::rowCount(), or Bad Things Happen). This means that I
> lose my "+" decoration on the node, when in fact I want it to remain
> because a user "expand node" operation should trigger a "refresh"
> (to possibly add children under the node on-demand).
The tree view should always initially only use hasChildren() to determine if
the decoration should be displayed. If a user clicks on it, rowCount() will
be called and if that returns 0 ... well it has no children :)
[snip]
> QUESTION: I like the model/view architecture, and don't need
> (nor want) significant interface changes. Is this design considered
> "stable and final", or are little changes under consideration, or
> what other design considerations are in the wind? It's sufficiently
> big and new and unique (from Qt3 to Qt4) that I could understand
> any of the above (I'm just trying to understand its context so I can
> best leverage it).
None of the interfaces will be changing, there will probably be some new
functionality in the future, but everything that is in 4.2 will continue to
work as it should in the future.
-Benjamin Meyer
--
[ signature omitted ]
Message 5 in thread
> > <snip, wanted "node refresh" when user attempts
> > to "expand" in a QTreeView>,
> > What I'd like is a *virtual* QTreeView::expand(),
> > or a signal QTreeView::aboutToExpand() (since the
> > existing signal QTreeView::expanded() is too
> > late). <snip>
Benjamin Meyer respondeth:
> In 4.2 right before a node is expanded fetchMore()
> will be called on the index. You can use this to
> populate your data then.
Excellent! I moved to Qt4.2, and fetchMore() works.
My current status: The program is doing exactly
what I wanted (I'm happy!), but I ended up not using
fetchMore() (I'd like comments on my solution because
it makes me scratch my head a little).
Here are my notes, feel free to correct me because
some are guesses from trial-and-error:
* MyModel::hasChildren() is called a *lot* from the
Qt architecture, even after rowCount() is called
(not a problem, mine is a fast implementation, as
I'm sure it will be for most designs.)
* In the bowels of Qt, the order appears to be:
<node expand operation>
...for each subnode:
MyModel::hasChildren() ...returns "true"
MyModel::rowCount() ...must be >0 to proceed
MyModel::canFetchMore() ...returns "true"
MyModel::fetchMore()
* In the case above, if rowCount() returns "0"
when the subnode is first displayed/populated
through the model, no "+" decoration is displayed,
and no call to "canFetchMore()/fetchMore()" is ever
attempted.
* You'd better not "lie" in MyModel::rowCount()
(e.g., return "1" all the time) because it's
architecturally confusing (i.e., there are real
cases where it *should* be zero), and because Bad
Things Happen in your views (the view allocates
real estate for the fictitious item).
* Because of the order, I find it necessary to
populate my node inside "rowCount()", and not use
"canFetchMore/fetchMore" at all.
It works, and seems fast, and it appears rowCount()
is efficiently called (not all the time like
hasChildren()). I don't understand the intended
use for fetchMore(), though: I would have intended
to populate the node from fetchMore() before any
call to rowCount() (so my implementation order would
be):
<NOT-CURRENT-BEHAVIOR>
<node expand operation>
...for each subnode:
MyModel::hasChildren() ...returns "true"
MyModel::canFetchMore() ...returns "true"
MyModel::fetchMore()
MyModel::rowCount()
Based on the current order, what's the intended
use for fetchMore()? It's name appears truly apt:
Since the rowCount() must already be established
before fetchMore() is called, it could only get
incremental additional state for something of which
it was already aware. In my case, I wanted to
populate *all* children (with no previous children
context), so I guess I didn't want to really
"fetchMore()" -- I'm doing my own
"fetchAllChildren()" inside "rowCount()".
I'm quite happy at present with my current solution,
although I welcome comments so I can best understand
how to implement using the architecture (I'm working
with very large models, and want to very efficiently
leverage the model/view design).
Thanks!
--charley
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
[ signature omitted ]
Message 6 in thread
On Saturday 26 August 2006 12:58, Charley Bay wrote:
> > > <snip, wanted "node refresh" when user attempts
> > > to "expand" in a QTreeView>,
> > > What I'd like is a *virtual* QTreeView::expand(),
> > > or a signal QTreeView::aboutToExpand() (since the
> > > existing signal QTreeView::expanded() is too
> > > late). <snip>
>
> Benjamin Meyer respondeth:
> > In 4.2 right before a node is expanded fetchMore()
> > will be called on the index. You can use this to
> > populate your data then.
>
> Excellent! I moved to Qt4.2, and fetchMore() works.
>
> My current status: The program is doing exactly
> what I wanted (I'm happy!), but I ended up not using
> fetchMore() (I'd like comments on my solution because
> it makes me scratch my head a little).
>
> Here are my notes, feel free to correct me because
> some are guesses from trial-and-error:
>
> * MyModel::hasChildren() is called a *lot* from the
> Qt architecture, even after rowCount() is called
> (not a problem, mine is a fast implementation, as
> I'm sure it will be for most designs.)
>
> * In the bowels of Qt, the order appears to be:
> <node expand operation>
> ...for each subnode:
> MyModel::hasChildren() ...returns "true"
> MyModel::rowCount() ...must be >0 to proceed
> MyModel::canFetchMore() ...returns "true"
> MyModel::fetchMore()
Hmm that would be a bug that has slipped in then (at least when opening a
node) QTreeView should never call rowCount() until a node is opened. and
before a node is opened fetchMore should be called on it :) Please report it
so the task can be tracked.
> * In the case above, if rowCount() returns "0"
> when the subnode is first displayed/populated
> through the model, no "+" decoration is displayed,
> and no call to "canFetchMore()/fetchMore()" is ever
> attempted.
>
> * You'd better not "lie" in MyModel::rowCount()
> (e.g., return "1" all the time) because it's
> architecturally confusing (i.e., there are real
> cases where it *should* be zero), and because Bad
> Things Happen in your views (the view allocates
> real estate for the fictitious item).
yup :)
> * Because of the order, I find it necessary to
> populate my node inside "rowCount()", and not use
> "canFetchMore/fetchMore" at all.
yah, that is a bit ugly sense rowCount() is const, but works on 4.1
[snip]
> I'm quite happy at present with my current solution,
> although I welcome comments so I can best understand
> how to implement using the architecture (I'm working
> with very large models, and want to very efficiently
> leverage the model/view design).
>
> Thanks!
Some other tips:
- implement data() using a switch with Qt::EditRole as the first case with no
break falling to Qt::DisplayRole as the second case.
- try to only *ever* use createIndex inside ::index(), call index() to
retrieve index's. I have seen a lot of mistakes from createIndex mistakes
that were not inside index()
- when using QListView check out setUniformItemSizes() to see if it applies to
you for a nice speed boost.
- when using QTableView or QTreeView check out uniformRowHeights() which can
be a very nice speed boost
- If you have a lot of rows or columns (not 50, but thousands+) using Qt 4.2
will give you a nice memory reduction with the new QHeaderView which
implements spanning.
- When sorting in your model don't forget to update the persistant model
indexes.
- Rather then iterating over a tree expanding items use expandAll(), new in
4.2
- Try to compress operations. In a model when removing 10 rows if you can
don't beginRemoveRows(), endRemoveRows() 10 times, but only do it once with
the correct arguments. Same goes for dataChanged().
- And of course profile before optimizing :)
Feel free to reply and share your own tips.
-Benjamin Meyer
--
[ signature omitted ]
Message 7 in thread
> > Charley Bay wrote:
> > * In the bowels of Qt4.2, the order appears to be:
> > <node expand operation>
> > ...for each subnode:
> > MyModel::hasChildren() ...returns "true"
> > MyModel::rowCount() ...must be >0 to proceed
> > MyModel::canFetchMore() ...returns "true"
> > MyModel::fetchMore()
Benjamin Meyer responded:
> Hmm that would be a bug that has slipped in then (at
> least when opening a node) QTreeView should never
> call rowCount() until a node is opened. and
> before a node is opened fetchMore should be called
> on it :) Please report it so the task can be
> tracked.
Ok, I just reported it and it's issue/task #127748.
If they fix the order (fetchMore() before rowCount())
then I'll put my "populate the node" back into
fetchMore() (and remove it from rowCount()).
That makes more sense to me.
> > [snip]
> > I'm quite happy at present with my current
> > solution, although I welcome comments so I can
> > best understand how to implement using the
> > architecture (I'm working with very large models,
> > and want to very efficiently leverage the
> > model/view design).
> Some other tips:
>
> - implement data() using a switch with Qt::EditRole
> as the first case with no break falling to
> Qt::DisplayRole as the second case.
> - try to only *ever* use createIndex inside
> ::index(), call index() to retrieve index's. I have
> seen a lot of mistakes from createIndex mistakes
> that were not inside index()
> - when using QListView check out
> setUniformItemSizes() to see if it applies to you
> for a nice speed boost.
> - when using QTableView or QTreeView check out
> uniformRowHeights() which can be a very nice speed
> boost
> - If you have a lot of rows or columns (not 50, but
> thousands+) using Qt 4.2 will give you a nice memory
> reduction with the new QHeaderView which
> implements spanning.
> - When sorting in your model don't forget to update
> the persistant model indexes.
> - Rather then iterating over a tree expanding items
> use expandAll(), new in 4.2
> - Try to compress operations. In a model when
> removing 10 rows if you can don't beginRemoveRows(),
> endRemoveRows() 10 times, but only do it once with
> the correct arguments. Same goes for dataChanged().
> - And of course profile before optimizing :)
>
> Feel free to reply and share your own tips.
This is EXCELLENT! Exactly the info I'm looking for.
(Things I need to do on BIG models to keep it most
efficient.)
I tried to add Benjamin's tips to the public QtCentre
Wiki, but the page is locked (not sure why):
<http://wiki.qtcentre.org/index.php?title=QAbstractItemModel>
I'm *very* interested in more of these tips, which
will probably have to come from implementors, and
not experimentors.
Another point of interest that I painfully figured
out (not specific to big models) is to be CERTAIN
that your QModelIndex::internalPointer() is
universally unique (within the model). At one point,
I would createIndex() with the "parent" as the
QModelIndex::internalPointer(), assuming that I could
use the QModelIndex::row() to identify the child,
and Bad Things Happened as the model apparently
got confused between nodes with common parents.
(Yes, after-the-fact I found a small statement in the
QModelIndex docs to suggest this, but I think a bigger
statement in the Model/View docs could be useful to
others.)
Thanks VERY MUCH Benjamin -- quite helpful.
--charley
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
[ signature omitted ]
Message 8 in thread
On Tuesday 29 August 2006 15:14, Charley Bay wrote:
> > > Charley Bay wrote:
> > > * In the bowels of Qt4.2, the order appears to be:
> > > <node expand operation>
> > > ...for each subnode:
> > > MyModel::hasChildren() ...returns "true"
> > > MyModel::rowCount() ...must be >0 to proceed
> > > MyModel::canFetchMore() ...returns "true"
> > > MyModel::fetchMore()
>
> Benjamin Meyer responded:
> > Hmm that would be a bug that has slipped in then (at
> > least when opening a node) QTreeView should never
> > call rowCount() until a node is opened. and
> > before a node is opened fetchMore should be called
> > on it :) Please report it so the task can be
> > tracked.
>
> Ok, I just reported it and it's issue/task #127748.
>
> If they fix the order (fetchMore() before rowCount())
> then I'll put my "populate the node" back into
> fetchMore() (and remove it from rowCount()).
>
> That makes more sense to me.
>
> > > [snip]
> > > I'm quite happy at present with my current
> > > solution, although I welcome comments so I can
> > > best understand how to implement using the
> > > architecture (I'm working with very large models,
> > > and want to very efficiently leverage the
> > > model/view design).
> >
> > Some other tips:
> >
> > - implement data() using a switch with Qt::EditRole
> > as the first case with no break falling to
> > Qt::DisplayRole as the second case.
> > - try to only *ever* use createIndex inside
> >
> > ::index(), call index() to retrieve index's. I have
> >
> > seen a lot of mistakes from createIndex mistakes
> > that were not inside index()
> > - when using QListView check out
> > setUniformItemSizes() to see if it applies to you
> > for a nice speed boost.
> > - when using QTableView or QTreeView check out
> > uniformRowHeights() which can be a very nice speed
> > boost
> > - If you have a lot of rows or columns (not 50, but
> > thousands+) using Qt 4.2 will give you a nice memory
> > reduction with the new QHeaderView which
> > implements spanning.
> > - When sorting in your model don't forget to update
> > the persistant model indexes.
> > - Rather then iterating over a tree expanding items
> > use expandAll(), new in 4.2
> > - Try to compress operations. In a model when
> > removing 10 rows if you can don't beginRemoveRows(),
> > endRemoveRows() 10 times, but only do it once with
> > the correct arguments. Same goes for dataChanged().
> > - And of course profile before optimizing :)
> >
> > Feel free to reply and share your own tips.
>
> This is EXCELLENT! Exactly the info I'm looking for.
> (Things I need to do on BIG models to keep it most
> efficient.)
>
> I tried to add Benjamin's tips to the public QtCentre
> Wiki, but the page is locked (not sure why):
> <http://wiki.qtcentre.org/index.php?title=QAbstractItemModel>
>
> I'm *very* interested in more of these tips, which
> will probably have to come from implementors, and
> not experimentors.
>
> Another point of interest that I painfully figured
> out (not specific to big models) is to be CERTAIN
> that your QModelIndex::internalPointer() is
> universally unique (within the model). At one point,
> I would createIndex() with the "parent" as the
> QModelIndex::internalPointer(), assuming that I could
> use the QModelIndex::row() to identify the child,
> and Bad Things Happened as the model apparently
> got confused between nodes with common parents.
> (Yes, after-the-fact I found a small statement in the
> QModelIndex docs to suggest this, but I think a bigger
> statement in the Model/View docs could be useful to
> others.)
Yup, in fact I added an assert that checks that very thing in
qabstractitemview's setModel(). That and incorrect invalid parent were two
common errors so I put them in to help devs catch them immediately rather
then puzzle for half an hour pulling their hair out.
// These asserts do basic sanity checking of the model
Q_ASSERT_X(d->model->index(0,0) == d->model->index(0,0),
"QAbstractItemView::setModel",
"A model should return the exact same index "
"(including its internal id/pointer) when asked for it twice in
a row.");
Q_ASSERT_X(d->model->index(0,0).parent() == QModelIndex(),
"QAbstractItemView::setModel",
"The parent of a top level index should be invalid");
> Thanks VERY MUCH Benjamin -- quite helpful.
>
> --charley
I have started a wiki page on KDE's wiki, feel free to add to it.
http://wiki.kde.org/tiki-index.php?page=ItemView+Tips
-Benjamin Meyer
--
[ signature omitted ]
Message 9 in thread
> I have started a wiki page on KDE's wiki, feel free to add to it.
> http://wiki.kde.org/tiki-index.php?page=ItemView+Tips
Excellent idea. Bookmarked.
Martin
--
[ signature omitted ]
Message 10 in thread
Hi all,
thx Benjamin for all these tips.
A remark.
According to your KDE WIki page
http://wiki.kde.org/tiki-index.php?page=ItemView+Tips
> The internal pointer for a QModelIndex must *not* change over time and
> must be universally unique.
I would not agree with this.
In my tree model, all the QModelIndex that are children of the same parent
do share the same QModelIndex::internalPointer !
You may remember a discussion we had on my model in June : I encountered
problems (still unsolved ;)) when removing multiple rows before callinf
endRemoveRow.
My model refers to an oriented graph with containers and leaves.
Indeed, for performance reasons, the QModelIndex internal pointer's point to
the parent tree node, not to the actual tree node.
Accessing to the actual tree node that corresponds to a QModelIndex requires
derefencing the parent tree node, and computing its child ar row
QModelIndex::row().
Anyhow, my design do not match your requirement :
"The internal pointer for a QModelIndex must *not* change over time and
must be universally unique."
Does that mean my model is wrong ?
Best-
Nicolas
Benjamin Meyer wrote:
> On Saturday 26 August 2006 12:58, Charley Bay wrote:
>> > > <snip, wanted "node refresh" when user attempts
>> > > to "expand" in a QTreeView>,
>> > > What I'd like is a *virtual* QTreeView::expand(),
>> > > or a signal QTreeView::aboutToExpand() (since the
>> > > existing signal QTreeView::expanded() is too
>> > > late). <snip>
>>
>> Benjamin Meyer respondeth:
>> > In 4.2 right before a node is expanded fetchMore()
>> > will be called on the index. You can use this to
>> > populate your data then.
>>
>> Excellent! I moved to Qt4.2, and fetchMore() works.
>>
>> My current status: The program is doing exactly
>> what I wanted (I'm happy!), but I ended up not using
>> fetchMore() (I'd like comments on my solution because
>> it makes me scratch my head a little).
>>
>> Here are my notes, feel free to correct me because
>> some are guesses from trial-and-error:
>>
>> * MyModel::hasChildren() is called a *lot* from the
>> Qt architecture, even after rowCount() is called
>> (not a problem, mine is a fast implementation, as
>> I'm sure it will be for most designs.)
>>
>> * In the bowels of Qt, the order appears to be:
>> <node expand operation>
>> ...for each subnode:
>> MyModel::hasChildren() ...returns "true"
>> MyModel::rowCount() ...must be >0 to proceed
>> MyModel::canFetchMore() ...returns "true"
>> MyModel::fetchMore()
>
> Hmm that would be a bug that has slipped in then (at least when opening a
> node) QTreeView should never call rowCount() until a node is opened. and
> before a node is opened fetchMore should be called on it :) Please report
> it so the task can be tracked.
>
>> * In the case above, if rowCount() returns "0"
>> when the subnode is first displayed/populated
>> through the model, no "+" decoration is displayed,
>> and no call to "canFetchMore()/fetchMore()" is ever
>> attempted.
>>
>> * You'd better not "lie" in MyModel::rowCount()
>> (e.g., return "1" all the time) because it's
>> architecturally confusing (i.e., there are real
>> cases where it *should* be zero), and because Bad
>> Things Happen in your views (the view allocates
>> real estate for the fictitious item).
>
> yup :)
>
>> * Because of the order, I find it necessary to
>> populate my node inside "rowCount()", and not use
>> "canFetchMore/fetchMore" at all.
>
> yah, that is a bit ugly sense rowCount() is const, but works on 4.1
>
> [snip]
>
>> I'm quite happy at present with my current solution,
>> although I welcome comments so I can best understand
>> how to implement using the architecture (I'm working
>> with very large models, and want to very efficiently
>> leverage the model/view design).
>>
>> Thanks!
>
> Some other tips:
>
> - implement data() using a switch with Qt::EditRole as the first case with
> no break falling to Qt::DisplayRole as the second case.
> - try to only *ever* use createIndex inside ::index(), call index() to
> retrieve index's. I have seen a lot of mistakes from createIndex mistakes
> that were not inside index()
> - when using QListView check out setUniformItemSizes() to see if it
> applies to you for a nice speed boost.
> - when using QTableView or QTreeView check out uniformRowHeights() which
> can be a very nice speed boost
> - If you have a lot of rows or columns (not 50, but thousands+) using Qt
> 4.2 will give you a nice memory reduction with the new QHeaderView which
> implements spanning.
> - When sorting in your model don't forget to update the persistant model
> indexes.
> - Rather then iterating over a tree expanding items use expandAll(), new
> in 4.2
> - Try to compress operations. In a model when removing 10 rows if you can
> don't beginRemoveRows(), endRemoveRows() 10 times, but only do it once
> with
> the correct arguments. Same goes for dataChanged().
> - And of course profile before optimizing :)
>
> Feel free to reply and share your own tips.
>
> -Benjamin Meyer
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 11 in thread
On Wednesday 30 August 2006 15:57, Nicolas Castagne wrote:
> Hi all,
>
> thx Benjamin for all these tips.
>
> A remark.
>
> According to your KDE WIki page
> http://wiki.kde.org/tiki-index.php?page=ItemView+Tips
>
> > The internal pointer for a QModelIndex must *not* change over time and
> > must be universally unique.
>
> I would not agree with this.
>
> In my tree model, all the QModelIndex that are children of the same parent
> do share the same QModelIndex::internalPointer !
Yah the way that is worded is wrong. What is should say is that the returned
index must be universally unique. So the internal pointer can point to the
parent in which case the row and column give it the uniqueness.
-Benjamin Meyer
--
[ signature omitted ]
