[Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357

[Dmitriy Purgin]

Hello everyone,

I partly agree with Corentin on that.

On Linux the end-user application should use journald to write logs
since the user expects it to be there. The in-development application
though should still use stderr or both since it's much easier to look
into Creator's Application Output window and see what's going on than
searching through the journal.

On the contrary, the end-user on Windows expects the application logs
to be in a file somewhere near the executable if it's not a system
service. So in my opinion the logs shouldn't write into system unless
explicitly asked to. Moreover afaik not every enterprise user has
access to System Logs on Windows.

Cheers
Dmitriy Purgin

2014-07-10 8:40 GMT+06:00 Thiago Macieira <thiago.macieira at intel.com>:
> On Thursday 10 July 2014 02:54:12 Corentin Jabot wrote:
>> At least on unix desktop platforms, I expect to get stderr output on the
>> console.
>> So, detecting its presence is certainly a good approach.
>>
>> When there is no console, I probably don't care about the logs at all.
>>
>> I *may* care about error/warning messages, granted that the application
>> manages its outputs diligently, which is often not the case.
>
> As we discussed on IRC: *if* you care about the warnings, then you want to find
> them. And reading ~/.xsession-errors is not acceptable. Mine has close to 1.2
> million lines in 7 days of uptime (roughly 7000 lines per hour), in an output
> that doesn't log application name, PID, TID or function name. We can turn
> those on with the logging framework, but they're not easily searchable.
>
>> One argument is that the system logging offers better rotating & search
>> facilities, which is true, but the logs would still be cluttered by probably
>> useless messages.
>> There are tons of signal/slot missing throughout KDE applications, as a end
>> user what can I possibly do about it ?
>
> Hence the searchability.
>
> $ journalctl -l /home/thiago/obj/qt/qt5/qtbase/bin/qdbusviewer
> -- Logs begin at Wed 2014-07-09 16:14:48 PDT, end at Wed 2014-07-09 19:23:29
> PDT. --
> Jul 09 19:23:29 tjmaciei-mobl4 qdbusviewer[36992]: Connecting to deprecated
> signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
>
> $ journalctl -l QT_CATEGORY=default
> -- Logs begin at Wed 2014-07-09 16:14:48 PDT, end at Wed 2014-07-09 19:23:29
> PDT. --
> Jul 09 19:23:29 tjmaciei-mobl4 qdbusviewer[36992]: Connecting to deprecated
> signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
>
> I can even search for which Qt categories are getting logged:
>
> $ journalctl -F QT_CATEGORY
> default
>
>> I do not have a huge ~/.xsession-error file, but for those who have,
>> I think it's a problem for distributions to solve, not Qt.
>
> Agreed. But we have to integrate with the mechanisms that the distros provide.
>
>> A think an application should be assumed to be unimportant ( not to log to
>> the system's journal) by default. The choice should be given both to the
>> developer ( with an api) and maintainers/end user (environment variable) to
>> modify this behavior.
>
> I disagree. I think the application should log and then the log system can
> decide whether to keep it or throw it away.
>
> The one thing I'm missing here is a user-configurable log system. If I'm a
> developer of a Qt application and I'm using the system Qt, I want to get my
> logs and not clutter the system. Which is where the recommendation comes from:
> Linux distributions should not enable a logging system that regular users
> can't access.
>
>> As for Qt Creator, my opinion is that the logs of an in-development
>> application become irrelevant the second you press the rebuild button and so
>> its output should always go to stderr only.
>
> Yes and no. Creator must show it, but I don't think it matters to the user
> where it got the output from.
>
> If Creator can read from the log, it can get more information than just plain
> pipes. It could, for example, allow you to jump to the source line that
> produced the line in question. Granted, that could be done with a proper
> message formatting too, but it would be harder because stdout and stderr are
> just plain buffers (they're not even line buffered), whereas the log would be
> properly packetised.
>
>> For platforms which offer no or poor console support, not-in-development
>> applications logs should arguably go to the system journal to be forever
>> forgotten :I don't expect end-users to know how access those logs, even less
>> to provide the developers with them when something goes wrong.
>
> That's the case on Windows: GUI apps have stderr connected to the blackhole
> and the OutputDebugString buffer is only 32k in size. Use it or lose it.
>
> But again: it can be used. Hence the suggestion to use the system log.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development