Review Request 121880: FocusedTreeView: use a timer to batch recomputations of column width

Nicolai Hähnle nhaehnle at gmail.com
Wed Jan 7 08:32:05 UTC 2015



> On Jan. 6, 2015, 12:53 nachm., Milian Wolff wrote:
> > afaik, the FocusedTreeView is only being used by the OutputWidget, which already contains code like this as well to scroll the view to the bottom. Could we merge the two somehow to get rid of the timer duplication?
> 
> Aleix Pol Gonzalez wrote:
>     +1
>     In fact, FocusedTreeView as a generic class hasn't been very successful. We could just move it back in OutputView and get all the delaying code together.
> 
> Nicolai Hähnle wrote:
>     Alright; FocusedTreeView works by overriding a virtual method (sizeHintForColumn), which means the class itself can't just be removed, though obviously it would be trivial to move focusedtreeview.cpp|h into plugins/standardoutputview.
>     
>     I started to merge the auto-scroll functionality from OutputWidget into FocusedTreeView so that the timers can be merged (given that the class needs to stay around anyway, that seemed cleaner than the other way around), but ran into troubles because now the scrolling isn't in sync between different "areas" (Debug vs. Code). Did I mention that I hate the way those areas work?
>     
>     Anyway, I'll look into that in the near future to come up with a new version of this change.
> 
> Kevin Funk wrote:
>     Why does that need to be in sync? I think I don't understand.
>     
>     Regarding areas: I think everyone hates them, yet anyone came up with a better solution ;)

The out-of-syncness is really jarring in the following scenario: Start debugging a non-interactive program that writes to stdout. As the program is running, the output scrolls in the Debug toolview in the Debug area just fine. When the program ends, KDevelop switches back to the "Code" area and the Debug toolview jumps back to the first line of program output, which is a regression relative to what's happening so far (just to make it clear: this is a regression in my changes so far, which is why I haven't updated this RR yet).


- Nicolai


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121880/#review73257
-----------------------------------------------------------


On Jan. 6, 2015, 11:58 vorm., Nicolai Hähnle wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121880/
> -----------------------------------------------------------
> 
> (Updated Jan. 6, 2015, 11:58 vorm.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdevplatform
> 
> 
> Description
> -------
> 
> We need to recompute the column width when a new row is inserted to ensure that
> the horizontal scrollbar behaves properly.
> 
> Under certain circumstances (in particular: running an extremely spammy process
> or filtering large outputs), rowInserted is called many times in quick succession,
> which leads to essentially quadratic runtime behavior, because some of the
> recomputation triggers a slow layout recomputation inside QTreeView. So we delay
> the recomputation until we get back to the event loop.
> 
> After this change, output views work smoothly even on very large outputs.
> 
> 
> Diffs
> -----
> 
>   util/focusedtreeview.h f813c2de6d8679c57c1477d8bc63c29e2139ba98 
>   util/focusedtreeview.cpp b58720313cc9c3ca08ae401c009425a30cdc326a 
> 
> Diff: https://git.reviewboard.kde.org/r/121880/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Nicolai Hähnle
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150107/cd767108/attachment.html>


More information about the KDevelop-devel mailing list