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

[Shawn Rutledge]

On 10 July 2014 19:17, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 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?

I don't think it would need to go to the journal by default.  If users
don't know how to turn it on, they probably don't need the feature
either.  We just need to make it easy to turn on.

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

Edit it and run the application again and try to reproduce the bug
again?  Being able to debug after something has already happened is a
rare privilege anyway.  If you expect problems you can turn on the
logging in advance though.

Or maybe it could be configured on a per-application basis in addition
to the defaults.  Maybe we invent a standardized easy way that an app
can allow its own QSettings to control the logging, like have a
standard [qtlogging] section.  We could make it opt-in by requiring
that you call a method on your QSettings object to enable the standard
logging section, and after that, users will be able to edit the
settings file and turn on logging categories just as they can in
qtlogging.ini.  Or it could be always-available if that doesn't bother
anybody...

>> 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 thought so, but I'm glad Ossi found a possible strategy. ;-)

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

What are the use cases?  Somehow I don't usually need more than what
the Creator output pane already provides... except that categorized
logging opens up a possibility to control what you see there.

But even if we go that far, it's not so hard to find some code for a
terminal that we could use (there's even a certain QtQuick one I
happen to know of ;-)  And some people would like having a terminal
window in Creator anyway; I've seen it in other IDEs.  But of course
it would add more bloat.

Anyway just being able to see and manage the logging output in Creator
does not preclude running the application in a terminal if that's what
you want to do, right?  But IMO it should not be the default, and it
wouldn't hurt if it was more configurable.