Bug 316873

> The Frame stack in the debugger displays 20 frames. There is no button to fetch more frames.
> You can scroll down with the mousewheel to fetch more, but this is like... urgh, how would
> you find out about that? I didn't.
interesting, I thought that would be intuitive. This pattern gets more and more used, prominent example facebook.
What could be improved is status diaply: eg. by an additional item at the end that shows "Loading..." while it's loading. Would that have helped you?

> What is this "don't fetch all frames" even for?
The work that has to be done by gdb to get thousands of stack items is the bottleneck here. If you try that in gdb you'll notice

Hi Niko,

first of all, I want to apologize for my tone which was a bit rough in the report -- I was a bit annoyed by trying to fix this and discovering my solution didn't work ;)

The "just scroll down" pattern is intuitive if you don't see the end of the page and you can just keep scrolling. But, currently it looks like this in kdevelop:
http://i.imgur.com/y7EaLYQ.png
The list just ends. There is no indication that there is more items, nor is there a scrollbar or anything that could point me to using my mouse wheel to scroll down further to load more frames (also, what if I don't have a mouse wheel?). I very much doubt that using the mouse wheel to load more frames is an intuitive thing to do here for most users.

Cheers,
Sven

Ah, you have the tool view on the right - now I understand. That's annoying :D

I see four possible solutions:
- load more by default, like 60 or so (this is non-optimal as it also depends on your screen resolution how high the tool view could get)
- detect dynamically the widget height and calculate how many items fit in there
- add a button like you tried to do
- add an additional list item ("Load more...") that you can (double?) click and more will be loaded

Heh, yeah, it's on the right for me -- after all that's the default (isn't it?), so I guess most users will have it there.

I already tried the additional list item, this is what didn't work. Adding a button would be easy, but i guess it would be a bit ugly (where would the button go?).

I like the idea of just continuing to load items until the widget gets a scrollbar best. Should I implement that?

Greetings,
Sven

Well, what should happen is that we should keep fetching elements until the view is full. This can be easily done with canFetchMore and fetchMore.

Another possibly interesting thing I did in the History toolview is to fetch number of elements exponentially, by doubling every time. We can easily assume the user wants to go far away if he has requested more data repeatedly.

I'd suggest to try not to add more UI there, we could bloat quite easily...

> I like the idea of just continuing to load items until the widget
> gets a scrollbar best. Should I implement that?
Sounds good!

As Aleix said, no additional UI should be required.

Alright, I'll go do that then. ;)

Git commit edbc931ee49555556ba4cda606524bbe58f23d5a by Sven Brauch.
Committed on 19/03/2013 at 00:57.
Pushed by brauch into branch 'master'.

Debugger framestack: Fetch frames until the widget is full

For discussion, see

M  +9    -2    debugger/framestack/framestackwidget.cpp

http://commits.kde.org/kdevplatform/edbc931ee49555556ba4cda606524bbe58f23d5a

Git commit 5adc263e95d4d02396ecaca5dfb74427a9fbe05a by Sven Brauch.
Committed on 19/03/2013 at 01:06.
Pushed by brauch into branch 'master'.

Increase the number of frames fetched with each chunk when scrolling

This makes scrolling in large framestacks far less tedious, because
you don't have to stop after each 20 frames and wait for the debugger
to fetch more after a few scrolling steps.

M  +10   -3    debugger/framestack/framestackmodel.cpp
M  +4    -0    debugger/framestack/framestackmodel.h

http://commits.kde.org/kdevplatform/5adc263e95d4d02396ecaca5dfb74427a9fbe05a

One last thing which would be nice would be to have the scrollbar not jump, by resizing it with our knowledge of the total number of frames (do we have that?). That's not too important, tough.

Nice!

> One last thing which would be nice would be to have the scrollbar not jump, by resizing
> it with our knowledge of the total number of frames (do we have that?).
No, we don't know the total number.

Ok, then I think we can just leave it as it is.

Wow, it just doesn't work any more. I have no idea... it used to work nicely when I pushed it, but now it's just broken and I can't get it to work again. I noticed that the signal is being connected in the wrong place (should be in sessionChanged, otherwise it might cause warning messages on startup), and I wanted to change it -- it didn't work. So I reverted my changes, and it still didn't work. Apparently, although the connection of dataChanged of the framestackmodel to checkFetchMoreFrames succeeds, the slot is never invoked (apparently the dataChanged signal isn't emitted?)

Does anyone know anything about this?

Why don't you use the standard
QAbstractItemMode::canFetchMore and ::fetchMore?

This way it's the view itself requesting the additional frames... the current implementation looks a bit odd...

Additionally:
QObject::connect: Cannot connect (null)::dataChanged(QModelIndex,QModelIndex) to KDevelop::FramestackWidget::checkFetchMoreFrames()

Git commit 85684244bc57d8e8ea1616a7aa579383a95970f3 by Sven Brauch.
Committed on 12/06/2013 at 11:05.
Pushed by brauch into branch 'master'.

Revert "Debugger framestack: Fetch frames until the widget is full"

This reverts commit edbc931ee49555556ba4cda606524bbe58f23d5a.
It currently doesn't work anyways for unknown reasons, I'll come up
with a better solution later.

M  +2    -9    debugger/framestack/framestackwidget.cpp

http://commits.kde.org/kdevplatform/85684244bc57d8e8ea1616a7aa579383a95970f3

*** Bug 436059 has been marked as a duplicate of this bug. ***