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

[Thiago Macieira]

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