[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 16:50:22 Shawn Rutledge wrote:
> 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.

That doesn't solve the problem of the default. What do we do when 
qtlogging.ini isn't present?

And how do you debug an application that got installed on a system that 
already has qtlogging.ini?

> 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 don't think it's possible at all. If the application was compiled to the GUI 
subsystem, it *has* no stdout and stderr. We can open a new console window, 
but I don't think you can write to an existing one.

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

Colour support, TTY support, job control, etc. TTYs on Unix are much more 
complex than pipes.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center