On Thursday 10 July 2014 10:22:14 Thiago Macieira wrote:
On Thursday 10 July 2014 07:56:28 Koehne Kai wrote:
Provide a define QT_LOG_TO_CONSOLE that let QCoreApplication.h record
whether it should log to console (QT_LOG_TO_CONSOLE=1), to the system
(QT_LOG_TO_CONSOLE=0), or both
On Friday 11 July 2014 14:47:04 Joerg Bornemann wrote:
On 11-Jul-14 14:14, Joerg Bornemann wrote:
Here's the code. Maybe I missed something.
Ossi showed me what I missed.
We cannot just change stdout unconditionally.
So no reason to not do this, as long as the application call is prefixed
-Original Message-
From: development-bounces+kai.koehne=digia@qt-project.org
[...]
Some background: on Sailfish, we launch all major system services (and
UI) through systemd services ( user session for the UI parts). Those
processes may then choose to execute processes of their
On Thu, Jul 10, 2014 at 7:14 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
I'm not asking that distributions turn journald on if they don't want to.
Journald is optional.
Good to have that fact stated clearly:-)
snip section on remote debugging and having a way to force stderr
On Fri, Jul 11, 2014 at 11:13 AM, Hunger Tobias tobias.hun...@digia.com wrote:
I see why you would want journal data in your output, but I do see a
problems making that work for remote debugging/running. Even sailfish is
apparently forcing output to stderr when starting applications on-device
Looks like there are many different uses cases and point of views, we may
not reach an agreement.
I agree that the default settings should be as unified as possible, but, on
the other and, each platform
having different capabilities, it make sense to set the default behavior on
a
On 10-Jul-14 20:03, Thiago Macieira wrote:
That means we can replace the GetConsoleWindow() call with
AttachConsole(ATTACH_PARENT_PROCESS). If it succeeds or if it returns
ERROR_ACCESS_DENIED, we have a console.
For the Windows folks around: should we do this?
I've just played around with
On 11-Jul-14 01:18, Thiago Macieira wrote:
Logging to both is a problem if you have something that is able to read from
both. On Windows, all debuggers and IDEs read from both. Therefore, the option
is out.
That's not true. Visual Studio displays output from OutputDebugString in
its debug
On 11-Jul-14 14:14, Joerg Bornemann wrote:
Here's the code. Maybe I missed something.
Ossi showed me what I missed.
We cannot just change stdout unconditionally.
So no reason to not do this, as long as the application call is prefixed
with start /wait to run it in the foreground.
---snip---
On Friday 11 July 2014 09:13:30 Hunger Tobias wrote:
Note that it's also possible to query the system log remotely too. I
believe
that is done on Android, isn't it? From all I can find on the
Internet, in
order to enable capture of stderr, you need to have a rooted device.
AFAIK
On Friday 11 July 2014 08:59:35 Alejandro Exojo wrote:
I agree. Which is why my proposal email does not talk about debug mode.
Oh, I'm confused then. It does in the Patch Set 6, no?
The commit does not match the proposal.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software
On Friday 11 July 2014 14:32:51 Joerg Bornemann wrote:
BTW QTestLib did log to both until 5.2.1.
See 7fab8eb56b9309734d1b34d3d935d6a4cf14ce6e
To be clear: since 5.2.0 until 5.2.1.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
-Original Message-
From: development-bounces+kai.koehne=digia@qt-project.org
[...]
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
-Original Message-
From: development-bounces+kai.koehne=digia@qt-project.org
[mailto:development-bounces+kai.koehne=digia@qt-project.org] On
Behalf Of Thiago Macieira
Sent: Wednesday, July 09, 2014 11:44 PM
To: development@qt-project.org
Subject: [Development] Cake and
Sorry for my vague statements :)
Actually I wasn't talking about logging to file as a default for
Windows. On the contrary I think this has to be done by each
application individually -- someone needs as you rightly say 10 lines
of code just to make sure everything went okay, others need a large
-Original Message-
From: development-bounces+kai.koehne=digia@qt-project.org
[...]
Here's what I propose:
Heuristically determine at runtime. On all platforms (including Windows), use
only the fact that a terminal is present. If a terminal is present, write to
it
using
Perhaps, it makes sense to select an output message sink in runtime?
E.g. before QCoreApplication, by means of specify some QLogging flags, to
override the installMessageHandler and so on?
Maybe make sense to introduce a some pre-defined qInstallMessageHandler's()
or something others functions,
Hi Thiago,
Basically I agree with your statements, but I do not think we can rely
on journald
at this time.
The first problem is of course systemd itself: Ubuntu is one of the
biggest distros out
there and we can not reasonably assume that to be running systemd
before 14.04 is
at the end of its
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
On Thursday 10 July 2014 08:13:09 Koehne Kai wrote:
-Original Message-
From: development-bounces+kai.koehne=digia@qt-project.org
[...]
Here's what I propose:
Heuristically determine at runtime. On all platforms (including Windows),
use only the fact that a terminal is
On Thursday 10 July 2014 11:05:03 Tobias Hunger wrote:
Hi Thiago,
Basically I agree with your statements, but I do not think we can rely
on journald at this time.
Agreed.
The first problem is of course systemd itself: Ubuntu is one of the
biggest distros out
there and we can not
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
On Thursday 10 July 2014 07:56:28 Koehne Kai wrote:
Provide a define QT_LOG_TO_CONSOLE that let QCoreApplication.h record
whether it should log to console (QT_LOG_TO_CONSOLE=1), to the system
(QT_LOG_TO_CONSOLE=0), or both (QT_LOG_TO_CONSOLE=2).
Qmake can wrap this into convenience CONFIG
On Thu, Jul 10, 2014 at 10:17:52AM -0700, Thiago Macieira wrote:
On Thursday 10 July 2014 16:50:22 Shawn Rutledge wrote:
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
On Thursday 10 July 2014 19:34:59 Oswald Buddenhagen wrote:
On Thu, Jul 10, 2014 at 10:17:52AM -0700, Thiago Macieira wrote:
On Thursday 10 July 2014 16:50:22 Shawn Rutledge wrote:
On Windows I never liked CONFIG += console, because it's never in the
.pro by default (usually not in manual
On 10 July 2014 19:17, Thiago Macieira thiago.macie...@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
El Wednesday 09 July 2014, Thiago Macieira escribió:
=== Log to both ===
Aside from the extra overhead, this causes systems that capture both stderr
and the system log to record and display the same message twice. That's the
source of task [3].
This is not an option.
Why not? Task [3] is
El Thursday 10 July 2014, Koehne Kai escribió:
Provide a define QT_LOG_TO_CONSOLE that let QCoreApplication.h record
whether it should log to console (QT_LOG_TO_CONSOLE=1), to the system
(QT_LOG_TO_CONSOLE=0), or both (QT_LOG_TO_CONSOLE=2).
Would it be too problematic to make the environment
On Friday 11 July 2014 00:27:51 Alejandro Exojo wrote:
Would it be too problematic to make the environment variable
(QT_LOGGING_TO_CONSOLE, which already is in use) accept also a 2 for
logging to both sources?
Problematic, no. It can be easily implemented.
But it's an option we discarded.
On Friday 11 July 2014 00:17:48 Alejandro Exojo wrote:
El Wednesday 09 July 2014, Thiago Macieira escribió:
=== Log to both ===
Aside from the extra overhead, this causes systems that capture both
stderr
and the system log to record and display the same message twice. That's
the
On Thursday 10 July 2014 10:07:56 Thiago Macieira wrote:
[snip]
Creator must be able to handle reading from the system log before logging to
the system is enabled for that system. On Linux, the code is already there,
so we have to tell distributions *not* to enable journald yet.
AFAIU from
El Friday 11 July 2014, Lisandro Damián Nicanor Pérez Meyer escribió:
AFAIU from this thread, journald support should not be enabled except
regular users can read the output. Now what I'm missing here is: if Qt
is built with journald support, can it be still be used if journald is not
On Thursday 10 July 2014 23:53:20 Lisandro Damián Nicanor Pérez Meyer wrote:
On Thursday 10 July 2014 10:07:56 Thiago Macieira wrote:
[snip]
Creator must be able to handle reading from the system log before logging
to the system is enabled for that system. On Linux, the code is already
On Friday 11 July 2014 07:45:23 Alejandro Exojo wrote:
It might be even worse if systemd-shim provides that directory. Is it worth
to try sd_journal_open() and see if it fails? Or check some other way if
systemd actually launched the application?
No and no.
sd_journal_open might fail
== Problematic ==
Qt 5.3 and dev are currently able to send the output of qDebug, qWarning and
the rest of the logging framework to somewhere other than stderr. That's done
on Windows, BlackBerry, Android, and on Linux systems with journald.
Additionally, there's a pending patch for OS X to use
On Wednesday 09 July 2014 14:43:36 Thiago Macieira wrote:
=== Log to system logs only ===
This causes reports like [4]. But note that the bug is actually in Creator,
for failing to read the log store and display the data, like it does on
Windows with the debug output.
This is an option.
On Wednesday 09 July 2014 14:43:36 Thiago Macieira wrote:
Current Linux desktops with journald:
- default stderr: captured into ~/.xsession-errors
- system logging available: available
- is stderr useful: yes, for launching from terminal
[when Linux desktops start using user-mode systemd,
I feel the urge to give my two cents on that.
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
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
39 matches
Mail list logo
