QTextStream vs. QPlainTextEdit (not looking the same)
-
I am capturing the output from ffmpeg and am doing two things, 1) writing it to a QTextStream and the other writing it to a QPlainTextEdit; the output is different - QPlainTextEdit is correct.
Here is how I open the text stream (note, all this code has been condensed from their various functions for demonstration purposes):
@
_logFile = new QFile("ffmpeg.log"));
_logFile->open(QIODevice::WriteOnly | QIODevice::Truncate | QIODevice::Text);
_log = new QTextStream(_logFile);
@Next when I receive text from the QProcess, I write it to the QTextStream and append it to the QPlainTextEdit like so:
@
QString out = proc->readAllStandardError().constData();
_log << out;QTextCursor cur = _plainTextEdit->textCursor();
cur.movePosition(QTextCursor::End);
cur.insertText(out);
@Here is a snippet of what the text in QPlainTextEdit looks like:
@
FFmpeg version git-c9e16a9-Sherpya, Copyright (c) 2000-2011 the FFmpeg developers
built on Feb 4 2011 07:04:01 with gcc 4.2.5 20090330 (prerelease) [Sherpya]
libavutil 50. 37. 0 / 50. 37. 0
libavcore 0. 16. 1 / 0. 16. 1
@And here it is in the resulting text file:
@
FFmpeg version git-c9e16a9-Sherpya, Copyright (c) 2000-2011 the FFmpeg developersbuilt on Feb 4 2011 07:04:01 with gcc 4.2.5 20090330 (prerelease) [Sherpya]
libavutil 50. 37. 0 / 50. 37. 0
libavcore 0. 16. 1 / 0. 16. 1
@
Also in the text file apart from the extra lines that everything is indented by 1 space (which you can't really see here due to the forum formatting). Furthermore later on when ffmpeg is spitting out its processing data the extra lines go away yet the first line still has the 1 space indentation. example:
@
frame= 7 fps= 0 q=0.0 size= 96kB time=0.58 bitrate=1355.0kbits/s dup=0 drop=1
frame= 12 fps= 9 q=0.0 size= 192kB time=1.00 bitrate=1576.4kbits/s dup=0 drop=2
frame= 16 fps= 8 q=0.0 size= 262kB time=1.33 bitrate=1610.0kbits/s dup=0 drop=4
@edit: you can't see it here but that first line should have a single whitespace in front of it.
I appreciate your help.
Thanks.
-
My first try would be to remove QIODevice::Text from the open flags of the QFile object.
-
Better except now it seems \n does not add a line break.
-
That depends on the editor you open the resulting file with. Did you look with a hex editor or dumper what the file actually contains?
-
strange, my logs are ok now; not sure what I was looking at when I said \n was not working. I am using UltraEdit and it can handle dos / unix ctrl returns just fine.
Thanks for the tip, looks like removing QIODevice::Text was the ticket.
-
You're welcome. From my experience, using the text flag on files on windows is hardly necessary these days.
-
Since you mention windows specifically, am I going to find different behavior on Mac?
-
In principle, you have three options:
- CR+LF (aka \r\n)
Mostly used on Windows systems - CR (\r)
Used on the Mac up to OS 9 - LF (\n)
Used on Unix/Linux systems and on Mac OS X
As Mac OS 9 is dead, in practice you will have to deal with CR+LF vs LF. From my experience, the CR+LF on Windows is only needed in some special cases. Most modern editors can handle a single LF as line ending, including wordpad.exe (but not notepad.exe).
The text option was always a bit fishy in my opinion, as it can easily trash your line endings completely.
- CR+LF (aka \r\n)
-
Ok, in other words omitting the Text option will produce the same results regardless of platform?
-
Yes. There is no translation of \n to something else while writing to the file.
-
Ok, good, I would be concerned if there was. :)