<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/103380/">http://git.reviewboard.kde.org/r/103380/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On December 11th, 2011, 9 a.m., <b>Andreas Pakulat</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;">This is far too simple-thought, did you actually try this out? If the cloning is non-instant the progress will jump around because git has multiple stages which all print the progress from 0 to 100%.
In addition you're loosing the stderr output from git clone, I'm not sure wether its logged right now, but if its not it should be so in case something goes wrong during the clone the user can see the git output.</pre>
</blockquote>
<p>On December 11th, 2011, 9:05 a.m., <b>Andreas Pakulat</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;">Sorry, didn't fully read the "Testing done" part, apparently you did try this and know about the problem. I don't know how the progress is done right now, but there should be a way to tell the job-progress-meter that the job does not know how long it'll take. In that case the simple progressbar will change to one indicating that there's something going on without indicating how far it is. IMHO this is sufficient, it is an animation which clearly shows that something is going on and hence visible the job is not halted.</pre>
</blockquote>
<p>On December 13th, 2011, 11:46 a.m., <b>David Narváez</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;">Progress is not done at all right now, so it's true that any solution is better than what we have right now. In order to tell the progress bar to change to a busy indicator, we would need to add some extra calls to VcsJob allowing it to specify whether it knows how log will it take to finish or not (or simply assume no VcsJob knows how long will it take and make the progress bar a busy indicator for any VCS we support).
On the other hand, that gives only half of the information. The information I am particularly interested in is knowing how much time do I have to wait in order to take other decisions like hop to next task or take a nap, whatever. As I mentioned before, having a bar that "quickly" fills at the first time, then takes a lot of time to fill in the second pass and then a fills up a third time is not so confusing once you understand what those three passes are.
The issue you raised about losing stderr output is still valid, though, I have no idea on how to solve that without doing a rather serious overhauling of output handling.
Any other comments from other developers?</pre>
</blockquote>
<p>On December 13th, 2011, 12:34 p.m., <b>Andreas Pakulat</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 understand that because you know/care how git works, but thats not necessarily something we can assume every user does know/care about. For any such users seeing 3 0->100% progresses is confusing if he triggered just a single action. I don't think a user should be required to know this technical detail about the git fetch process just to be able to understand a progress meter. In addition this would be completely inconsistent with all other progress reports in Kdevelop, even those that trigger the same action for a different VCS.
Since I don't know the code anymore off-hand for the jobs, in particular the dvcsjobs, I can't advise on loosing the stderr-output. My gut feeling however is that if its even ok to read the output from the process in the job itself, then it should be possible to add it to the jobs output model (or whatever) once you extracted the information.</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;">regarding loosing stderr: like apaku said, it should be possible to push the contents to the output model, or to "re-emit" it and let it be handled where it was handled before.
regarding progress bar: apaku again is right in that we cannot/should not expect our users to know such details about git. but we/you know, so can't we just do something like this:
- split range [0, 100] into three ranges [0, a], [a, b], [b, 100]
- since apparently steps 1 and 3 are fast, make a small and b nearly 100.
- map progress percentages into these three ranges
reasoning:
it's better to get some overall percentage, even if it is *not* linearly mappable to an ETA imo - a bouncing progress bar has much less information
</pre>
<br />
<p>- Milian</p>
<br />
<p>On December 10th, 2011, 8:55 p.m., David Narváez wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for KDevelop.</div>
<div>By David Narváez.</div>
<p style="color: grey;"><i>Updated Dec. 10, 2011, 8:55 p.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;">Very naive approach to leverage stderr to get progress. I'm no expert on QProcesses so if anything looks bad or the idea is bad as a whole, just 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;">1. Fetch a large project using the Git provider (I tried NetworkManager, for instance)
2. Fetch a project using the KDE provider
In both tests, before this patch, progress is not changed until the project is completely fetched (see bug 256832). After this patch, progress bar changes with the standard error. Notice that the bar is filled three times, I'm not sure how to avoid that without making the code overly complex, but I thought it was a nice start to at least have the progress in the critical part of the process which is the second time the progress bar fills (downloading objects).</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=256832">256832</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>plugins/git/gitclonejob.h <span style="color: grey">(3279ba1)</span></li>
<li>plugins/git/gitclonejob.cpp <span style="color: grey">(ce48ee7)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/103380/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>