<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/110960/">http://git.reviewboard.kde.org/r/110960/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On July 8th, 2013, 9:09 a.m. UTC, <b>Vlas Puhov</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">You see, the functionality of those two signals intersect, so frameSelectionChanged slot will be called twice if you change current frame by clicking. To solve it you could use selectionChanged signal located in m_frames->selectionModel(), that includes both currentChanged and clicked cases or you could implement missing signal in subclass of QTreeView.
If there is something I understand wrong, please let me know.</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Yes, I have actually written as much myself in a comment on this review request two weeks ago. The thing is: selectionChanged doesn't work, because the frameSelectionChanged method needs to be called in cases where the selection doesn't actually change (as in the use case I have written before).
So the question is: Do we care enough to bother eliminating the case where the method is triggered twice, and if so, how? To be honest, I don't care (openDocument is fast, and this code is only triggered by user actions) and I don't have an answer to the second part.
Adding a new signal in a subclass of QTreeView seems awfully fragile to me, because it would have to duplicate functionality that is already in there. It would have to somehow duplicate the code that checks for all the possible inputs that made change or click on the active selection, and we'd have to hope that there is no subtle change in the future that breaks that. That's not code I would want to maintain.
The alternative is to somehow recognize when we're in this intersection case, but I just don't see a simple *and* robust way of doing that (I don't want to rely on undocumented behavior such as the order in which those signals are emitted). One robust way would be to check whether the source code that we want to become visible is already visible, but then we might as well call into openDocument, which is what happens right now.</pre>
<br />
<p>- Nicolai</p>
<br />
<p>On July 8th, 2013, 7:04 a.m. UTC, Nicolai Hähnle wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for KDevelop and Niko Sams.</div>
<div>By Nicolai Hähnle.</div>
<p style="color: grey;"><i>Updated July 8, 2013, 7:04 a.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Allow users to navigate the Frame Stack Toolview using the arrow keys
and tab/shift-tab without distraction to locate the thread(s) and
frame(s) of interest.
This required the following changes:
1) Add IDocumentController::DoNotFocus; assorted changes in
DocumentController and MainWindow.
The intention is clear: Allow opening and showing a document without
yanking the focus away from where it currently is. This could also be
interesting for other toolviews (e.g., keyboard navigation in the Code
Browser).
Focusing the new view is hidden inside MainWindow::activateView, so
I added an overloaded variant of this method which allows the caller
to choose whether the view should get the focus.
2) Use DoNotFocus in the relevant parts of the debugger.
3) Change FramestackWidget signal wiring to react to all types of input
Previously, FramestackWidget connected its slots to the item views'
clicked() signal, which only reacts on mouse input. Use the selection
models' currentChanged() signal instead, which reacts to other types of
input, in particular the keyboard.
As a consequence, the connections have to be set up in
currentSessionChanged(), because that's where the model is fully set up.
Relatedly, switch only m_frames->rootIndex in currentThreadChanged()
rather than the entire model, because the entire model doesn't actually
change.
4) There is one unrelated change, which is that I moved a connection
attempt to checkFetchMoreFrames down into currentSessionChanged;
otherwise, the connection does not succeed (and QObject complains
about it on the console).
I noticed that there is a related bug report, bug #316873, about this
fetch-more-frames feature; the bug report ends rather vaguely without
resolution, and I only noticed it after starting this Review Request.
However, fetching more frames automatically, triggered by scrolling,
works for me.
That's pretty much it. I hope you consider this a useful new feature,
and I hope the patch looks good to you. If you see any problems, or if
I have misstepped outside the coding guidelines at some point, please
let me know!</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Only manual testing - I don't know if/how this could be tested
automatically:
Within {my own project, the threads test case from kdevelop,
kdevelop itself} I have interrupted the debug run and done a lot
of mouse- and keyboard-based back and forth between threads and
frames. I also explicitly checked that loading additional frames
still works. That's pretty much it.</pre>
</td>
</tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="http://bugs.kde.org/show_bug.cgi?id=316873">316873</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>debugger/framestack/framestackwidget.h <span style="color: grey">(9794353)</span></li>
<li>debugger/framestack/framestackwidget.cpp <span style="color: grey">(dcc7a64)</span></li>
<li>interfaces/idocumentcontroller.h <span style="color: grey">(434cb4d)</span></li>
<li>shell/debugcontroller.cpp <span style="color: grey">(01432e6)</span></li>
<li>shell/documentcontroller.cpp <span style="color: grey">(660637f)</span></li>
<li>sublime/mainwindow.h <span style="color: grey">(421ee57)</span></li>
<li>sublime/mainwindow.cpp <span style="color: grey">(dce4bf7)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/110960/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>