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

Shawn Rutledge shawn.t.rutledge at gmail.com
Thu Jul 10 16:50:22 CEST 2014


What if we use qtlogging.ini (or equivalent on other systems) to
control whether the logs go to the system log or not?  I agree that
every ordinary KDE user doesn't need to have unread logs taking up
disk space, but maybe developers would like to turn on output to the
journal permanently for after-the-fact diagnosis when something
unexpectedly crashes or misbehaves.

There is already a discoverability problem about the available
categories, so I was thinking we need a nice tool to manage
qtlogging.ini (a widget-based app or a menu-driven console app).  This
tool could turn on and off the system logging too.  Maybe it could be
a feature of qtdiag instead of a separate tool (since logging is a
kind of diagnostic device).

On Windows I never liked CONFIG += console, because it's never in the
.pro by default (usually not in manual tests or examples, and not in
Creator-generated pro files either) and yet I would like to always
have qDebug output in the console when the app is running in a
console.  So detecting whether the app is running in a console and
automatically sending debug output there would mean that we no longer
need that flag in the .pro, right?  If it's technically possible, we
should have done that years ago.

I never want a separate pop-up console otherwise because it's an
annoyance and has too few features.  A log viewer which allows
searching and filtering would be far more useful.  So another idea is
what about including with the Qt SDK a widget-based log viewer, with
UI for turning the categories on and off, and also some searching and
filtering features?  If you are using it, the logging output would be
redirected there instead of stderr or the console... but the question
is how do you use it: by having it start the application?  or have UI
to select and attach to already-running applications?

I also don't like Creator's default "run in terminal" checkbox because
again I don't get to choose which terminal, and the one it chooses is
always 80x25, white background, has no search feature, etc.  So I have
to remember to turn off the checkbox because the default is not what I
want.  IMO the Application Output pane should have enough features
that it can be treated as the console in which the app is running.
What is missing, that we don't already do this?

Or if we write a log viewer tool, Creator could use that as the
Application Output pane instead of needing to write a separate one.
Or maybe it's just a matter of packaging Creator's output pane into a
standalone log viewer tool, and add more filtering features to both.



More information about the Development mailing list