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 pre
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 (QT_
On Wednesday 09 July 2014 16:15:16 Thiago Macieira wrote:
> 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 stderr. Otherwise, write to the system log.
This proposal is now impl
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
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 Arc
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.
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 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 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 wi
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 platform-per-plat
On Fri, Jul 11, 2014 at 11:13 AM, Hunger Tobias 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
> via Qt Creator.
Don
On Thu, Jul 10, 2014 at 7:14 PM, Thiago Macieira
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:-)
> It's there in two ways:
>
> 1) Option -t to ssh, which forces the allocation of a TTY
> -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
El Friday 11 July 2014, Thiago Macieira escribió:
> On Friday 11 July 2014 00:17:48 Alejandro Exojo wrote:
> > Logging to the console _and_ journald has proven very useful to us. We
> > did it specifically for an application using Qt's API, and developers
> > can code, press Run (in Creator), and s
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 alrea
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 beca
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
> pr
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 t
On Wed, Jul 9, 2014 at 11:43 PM, Thiago Macieira
wrote:
> == 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 jo
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
> > t
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 discarde
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 environme
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]
On 10 July 2014 19:17, Thiago Macieira 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
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 i
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 fil
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 CON
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 wo
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 re
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 t
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-
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 l
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, li
> -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
> u
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
l
> -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 a
> -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 in
Hello everyone,
I partly agree with Corentin on that.
On Linux the end-user application should use journald to write logs
since the user expects it to be there. The in-development application
though should still use stderr or both since it's much easier to look
into Creator's Application Output w
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 abou
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 message
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 syste
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 optio
42 matches
Mail list logo
