Qt-interest Archive, February 2007
Lazy tree model
Pages: Prev | 1 | 2 | Next
Message 1 in thread
Hi,
I have tried to follow Benjamin Meyer's example of a model populating a
treeview lazily (www.kdedevelopers.org/blog/106) using fetchmore and
canfetchmore.
It works for the root node but for some reason I'm missing to detect, not for
the subnodes.
Could someone have a look and point me to where I'm going wrong, please?
The small example can be found here:
http://home.arcor.de/lazymodel/lazy.zip
Thanks,
Meinhard
--
[ signature omitted ]
Message 2 in thread
On Sunday 04 February 2007 23:14, M. Ritscher wrote:
> Hi,
>
> I have tried to follow Benjamin Meyer's example of a model populating a
> treeview lazily (www.kdedevelopers.org/blog/106) using fetchmore and
> canfetchmore.
>
> It works for the root node but for some reason I'm missing to detect, not
> for the subnodes.
> Could someone have a look and point me to where I'm going wrong, please?
> The small example can be found here:
>
> http://home.arcor.de/lazymodel/lazy.zip
>
> Thanks,
>
> Meinhard
I ran it through my modeltest (props for being the very first model subjected
to it and not asserting with a found error on the first run). The problem is
in your populateChildren(). You add them to the list, but you don't use
beginInsertRows()/endInsertRows() so the QTreeView is never told about the
new rows.
-Benjamin Meyer
--
[ signature omitted ]
Message 3 in thread
On Monday 05 February 2007 14:46, Benjamin Meyer wrote:
> I ran it through my modeltest (props for being the very first model
> subjected to it and not asserting with a found error on the first run).
I vaguely remember having read something somewhere about a modeltest to be
included in some version of Qt. Sounds _very_ promising and definitely will
be very useful. Cool!
> The problem is in your populateChildren(). You add them to the list, but
> you don't use beginInsertRows()/endInsertRows() so the QTreeView is never
> told about the new rows.
Well, I did it but I'm not sure having done it on the right position. Doing it
this way:
http://home.arcor.de/lazymodel/lazy.zip
it works but animation would not work on the first expansion of a node. (Not
that I care much about the animation, it's just that I want to understand
it).
I came up with another idea completely ignoring fetchMore and canFetchMore.
http://home.arcor.de/lazymodel/lazy2.tar.bz2
Running it
>./lazymodel 2>&1 | grep ====
will show it's populated lazily.
Do I missing the point here?
Meinhard
--
[ signature omitted ]
Message 4 in thread
On Monday 05 February 2007 22:02, M. Ritscher wrote:
> On Monday 05 February 2007 14:46, Benjamin Meyer wrote:
> > I ran it through my modeltest (props for being the very first model
> > subjected to it and not asserting with a found error on the first run).
>
> I vaguely remember having read something somewhere about a modeltest to be
> included in some version of Qt. Sounds _very_ promising and definitely will
> be very useful. Cool!
>
> > The problem is in your populateChildren(). You add them to the list,
> > but you don't use beginInsertRows()/endInsertRows() so the QTreeView is
> > never told about the new rows.
>
> Well, I did it but I'm not sure having done it on the right position. Doing
> it this way:
> http://home.arcor.de/lazymodel/lazy.zip
> it works but animation would not work on the first expansion of a node.
> (Not that I care much about the animation, it's just that I want to
> understand it).
You should call beginInsertRows() before actually inserting the rows :)
> I came up with another idea completely ignoring fetchMore and canFetchMore.
> http://home.arcor.de/lazymodel/lazy2.tar.bz2
> Running it
>
> >./lazymodel 2>&1 | grep ====
>
> will show it's populated lazily.
> Do I missing the point here?
Nope, that is another way to do it. This is how QDirModel does it too. I
personally don't like it too much because rowCount() is const so you have to
do static cast(s), but that is just me. Also it has the tendency to populate
a lot more then what was needed from accidental calls to rowCount() that
could have been just a hasChildren().
-Benjamin Meyer
--
[ signature omitted ]
Message 5 in thread
On Tuesday 06 February 2007 10:34, Benjamin Meyer wrote:
> > (Not that I care much about the animation, it's just that I want to
> > understand it).
> You should call beginInsertRows() before actually inserting the rows :)
Well, but for that I need to know the number of rows I want to add, don't I?
I could think of methods, building a list first, query the the number and then
assigning/appending the list to the children member. Or querying and adding
the children one by one which is not always possible.
But somehow this looks to me a bit more complicated than necessary.
> > Do I missing the point here?
>
> Nope, that is another way to do it. This is how QDirModel does it too. I
> personally don't like it too much because rowCount() is const so you have
> to do static cast(s), but that is just me. Also it has the tendency to
> populate a lot more then what was needed from accidental calls to
> rowCount() that could have been just a hasChildren().
Understood! Thanks for explaining.
No it's not just you. I like doing things the clean way if I'm able too ;)
Meinhard
--
[ signature omitted ]
Message 6 in thread
I've got an issue where someone hitting ESC kills my program. I am
handling the closeEvent() which I thought was caused by ESC or closing
the window. Thoughts on what ESC sends? Or how to trap ESC?
--
[ signature omitted ]
Message 7 in thread
Allen, Matthew schrieb:
> I've got an issue where someone hitting ESC kills my program. I am
> handling the closeEvent() which I thought was caused by ESC or closing
> the window. Thoughts on what ESC sends? Or how to trap ESC?
QWidget::keyPressEvent()?
Martin
--
[ signature omitted ]
Message 8 in thread
Your window class inheris QWidget or QDialog?
If you are using QDialog, it will close the window when ESC is hit and you
can't ignore the closeEvent().
> Allen, Matthew schrieb:
> > I've got an issue where someone hitting ESC kills my program. I am
> > handling the closeEvent() which I thought was caused by ESC or closing
> > the window. Thoughts on what ESC sends? Or how to trap ESC?
>
> QWidget::keyPressEvent()?
>
> Martin
--
[ signature omitted ]
Message 9 in thread
Qdialog...
So there isn't a way to get ESC to be ignored? I'm trapping the X button
close event right now.
-----Original Message-----
From: Anderson Medeiros Gomes [mailto:amg1127@xxxxxxxxx]
Sent: Wednesday, February 07, 2007 4:25 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: Re: ESC kills program.
Your window class inheris QWidget or QDialog?
If you are using QDialog, it will close the window when ESC is hit and
you
can't ignore the closeEvent().
> Allen, Matthew schrieb:
> > I've got an issue where someone hitting ESC kills my program. I am
> > handling the closeEvent() which I thought was caused by ESC or
closing
> > the window. Thoughts on what ESC sends? Or how to trap ESC?
>
> QWidget::keyPressEvent()?
>
> Martin
--
[ signature omitted ]
Message 10 in thread
Allen, Matthew wrote:
> Qdialog...
>
> So there isn't a way to get ESC to be ignored? I'm trapping the X button
> close event right now.
As proposed by Martin before, keyPressEvent should work.
Here's how I ignore the ESC key in my dialog:
void MyDialog::keyPressEvent(QKeyEvent* event) {
if (event->key() != Qt::Key_Escape) {
QDialog::keyPressEvent(event);
}
}
hth
M
--
[ signature omitted ]
Message 11 in thread
Ahhhhh... Sweet. So catch it before it gets to the closeEvent bit...
Thanks much.
-----Original Message-----
From: Martin [mailto:martin.umgeher@xxxxxxxxxxx]
Sent: Wednesday, February 07, 2007 9:34 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: Re: ESC kills program.
Allen, Matthew wrote:
> Qdialog...
>
> So there isn't a way to get ESC to be ignored? I'm trapping the X
button
> close event right now.
As proposed by Martin before, keyPressEvent should work.
Here's how I ignore the ESC key in my dialog:
void MyDialog::keyPressEvent(QKeyEvent* event) {
if (event->key() != Qt::Key_Escape) {
QDialog::keyPressEvent(event);
}
}
hth
M
--
[ signature omitted ]
Message 12 in thread
If you filter the ESCAPE key by using QWidget::keyPressEvent(), you
must do it for all windows in your application. So, you will write
unnecessary code.
Use QWidget instead of QDialog in your window classes, unless you are
using some QDialog-exclusive feature.
2007/2/7, Allen, Matthew <allenm@xxxxxxxxxxxxxxxxxxxxxx>:
> Qdialog...
>
> So there isn't a way to get ESC to be ignored? I'm trapping the X button
> close event right now.
>
> -----Original Message-----
> From: Anderson Medeiros Gomes [mailto:amg1127@xxxxxxxxx]
> Sent: Wednesday, February 07, 2007 4:25 AM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: Re: ESC kills program.
>
> Your window class inheris QWidget or QDialog?
>
> If you are using QDialog, it will close the window when ESC is hit and
> you
> can't ignore the closeEvent().
>
> > Allen, Matthew schrieb:
> > > I've got an issue where someone hitting ESC kills my program. I am
> > > handling the closeEvent() which I thought was caused by ESC or
> closing
> > > the window. Thoughts on what ESC sends? Or how to trap ESC?
> >
> > QWidget::keyPressEvent()?
> >
> > Martin
>
>
>
> --
> Anderson Medeiros Gomes
> amg1127@xxxxxxxxx
>
> --
> 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 13 in thread
> If you filter the ESCAPE key by using QWidget::keyPressEvent(), you
> must do it for all windows in your application. So, you will write
> unnecessary code.
He could:
QCoreApplication::instance()->installEventFilter(<some obj>);
bool KeyboardServer::eventFilter(QObject *obj, QEvent *event){
....
}
filter key events globally. Not that this is much nicer.
Guido
--
[ signature omitted ]
Message 14 in thread
"Guido Seifert" <wargand@xxxxxx> wrote in message
news:20070207200538.GC23444@xxxxxxxxxxxxxxxxxxx
>> If you filter the ESCAPE key by using QWidget::keyPressEvent(), you
>> must do it for all windows in your application. So, you will write
>> unnecessary code.
>
> He could:
>
> QCoreApplication::instance()->installEventFilter(<some obj>);
>
> bool KeyboardServer::eventFilter(QObject *obj, QEvent *event){
> ....
> }
>
> filter key events globally. Not that this is much nicer.
Why not just override reject()?
--
[ signature omitted ]
Message 15 in thread
Why not QWidget?
> "Guido Seifert" <wargand@xxxxxx> wrote in message
> news:20070207200538.GC23444@xxxxxxxxxxxxxxxxxxx
>
> >> If you filter the ESCAPE key by using QWidget::keyPressEvent(), you
> >> must do it for all windows in your application. So, you will write
> >> unnecessary code.
> >
> > He could:
> >
> > QCoreApplication::instance()->installEventFilter(<some obj>);
> >
> > bool KeyboardServer::eventFilter(QObject *obj, QEvent *event){
> > ....
> > }
> >
> > filter key events globally. Not that this is much nicer.
>
> Why not just override reject()?
>
>
> --
> 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 ]
Pages: Prev | 1 | 2 | Next
