QTextStream vs. QPlainTextEdit (not looking the same)

mirswith

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 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

@

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.

goetz

My first try would be to remove QIODevice::Text from the open flags of the QFile object.

mirswith

Better except now it seems \n does not add a line break.

goetz

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?

mirswith

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.

goetz

You're welcome. From my experience, using the text flag on files on windows is hardly necessary these days.

mirswith

Since you mention windows specifically, am I going to find different behavior on Mac?

goetz

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.

mirswith

Ok, in other words omitting the Text option will produce the same results regardless of platform?

goetz

Yes. There is no translation of \n to something else while writing to the file.

mirswith

Ok, good, I would be concerned if there was. :)