Version: 3.9.94 (using KDevPlatform 0.9.94) (using 4.2.4 (KDE 4.2.4), Debian packages) Compiler: cc OS: Linux (i686) release 2.6.26-2-686 If you make : cout << "test line"; and don't end it by a "endl", it get not displayed in the run tab . Maybe it's overwritten by "*** Exited normally ***". I don't know if it's done intentionally, but I searched quite a lot of time in my code before i noticed that the problem was the missing endl. I know that it might be ugly but displaying "test line*** Exited normally ***" would be better as the cout at least get displayed.
1.0.0
The ProcessLineMaker is theoretically nice, but it won't give any output until the process gives a newline. However, it seems pretty clear that a process should have it's output spit out immediately, regardless of whether or not it ends with a newline, which means that the ProcessLineMaker isn't usable, and should probably be removed. Someone tell me if this is a bad idea or if there is a better alternative.
Removed from the nativeappjob, that is.
(In reply to comment #2) > The ProcessLineMaker is theoretically nice, but it won't give any output until > the process gives a newline. However, it seems pretty clear that a process > should have it's output spit out immediately, regardless of whether or not it > ends with a newline, which means that the ProcessLineMaker isn't usable, and > should probably be removed. > Someone tell me if this is a bad idea or if there is a better alternative. No that cannot be done and no there's also no better alternative (except implementing a real terminal emulator). The problem is that we need to convert the byte-array that we get from the process into a QString. This is only possible once a newline is received so we know that if we create a QString from the currently buffed QByteArray we're not in the middle of a multi-byte-sequence. See the problem is that the data we receive from the stdout of the process can contain such multi-byte sequences and depending on various factors they might be split up into two 'receivedData' signals. When a newline is received however we can be sure that everything between this newline and the previous one is a working string and can be converted. However this bugreport is more about stuff thats being written out without and endl never appearting at all. That should actually not happen as we do flush the buffers once the process ended I think.
SVN commit 1065397 by olivierjg: Flush lineMaker's buffer when app finishes. BUG: 202096 M +2 -0 nativeappjob.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1065397
We didn't, but now we do flush the buffers. For the record however... If someone wants to do this... --- void dosomething() { cout << "Processing... "; //some time consuming processing cout << "Done!\n" } --- You still won't see any output till the end of dosomething(). I guess we'll have to live with it for now.