Support '%QT_MESSAGE_PATTERN%'

[gvanem]

When I start AbracaDABra by:

set QT_MESSAGE_PATTERN=[^e[1;32m%%{file}:%%{line}^e[0m] - %%{message}
AbracaDABra.exe

the 1st call to qCInfo() shows:
[gui/rtltcpinput.cpp:51] - RTL-TCP: Initialising Winsock...
^____________________^: this in green on blue (since it's in a static constructor?)

But any subsequent qInfo(), qDebug() etc. output gets reset by logToModelHandler().
No colours. With a QT_MESSAGE_PATTERN set, I'd like the console to show things like this always:

So with this patch:

--- a/gui/mainwindow.cpp 2023-12-01 14:46:44
+++ b/gui/mainwindow.cpp 2023-12-08 09:07:49
@@ -152,6 +152,8 @@

     // creating log windows as soon as possible
     m_logDialog = new LogDialog(this);
+
+    if (qEnvironmentVariable("QT_MESSAGE_PATTERN", "") == ""
+        logToModel(m_logDialog->getModel());
-    logToModel(m_logDialog->getModel());

     ui->serviceListView->setIconSize(QSize(16,16));

It accomplishes that. Probably a better way to do it.

Tested in the TCC shell only. I've no idea (or interest) what an ESC-code is in CMD etc.

[KejPi]

But this would disable logging to application log window or am I wrong?

[gvanem]

Yes that's correct. My patch is too simple. I do not know how Qt can have 2 handlers:

• one for QT_MESSAGE_PATTERN console-messages.
• and a GUI-handler as now.

[KejPi]

I will look at that. Just to understand it correctly, the log is printed to the terminal but it is in the same fotmat as in Application log window and not in the format you like to have. Correct?

[gvanem]

Yes. I'd like the Application log not to be customised (unless those ESC-codes can give GUI-colours, can Qt do that?).
Trying this:

--- a/gui/mainwindow.cpp 2023-12-01 14:46:44
+++ b/gui/mainwindow.cpp 2023-12-08 10:15:08
@@ -90,6 +90,8 @@
     QString::fromUtf8("QProgressBar::chunk {background-color: #5bc214; }")   // green
 };

+QString MainWindow::QT_MESSAGE_PATTERN("");
+
 enum class SNR10Threhold
 {
     SNR_BAD = 70,
@@ -107,6 +109,16 @@
     QString category = context.category;
     QString timeStamp = QTime::currentTime().toString("HH:mm:ss.zzz");
     QString txt;
+    bool    custom_msg = (MainWindow::QT_MESSAGE_PATTERN != "");
+
+    /* Do not modify custom 'QT_MESSAGE_PATTERN' messages. Print strait to 'stderr'.
+     */
+    if (custom_msg)
+    {
+       txt = qFormatLogMessage(type, context, msg);
+       std::cerr << txt.toStdString() << std::endl;
+    }
+
     switch (type) {
     case QtDebugMsg:
         txt = QString("%1 [D] %2: %3").arg(timeStamp, category, msg);
@@ -129,6 +141,7 @@
                               Q_ARG(QString, txt),
                               Q_ARG(int, type));

+    if (!custom_msg)
     std::cerr << txt.toStdString() << std::endl;
 }

@@ -152,6 +165,8 @@

     // creating log windows as soon as possible
     m_logDialog = new LogDialog(this);
+
+    QT_MESSAGE_PATTERN = qEnvironmentVariable("QT_MESSAGE_PATTERN", "");
     logToModel(m_logDialog->getModel());

     ui->serviceListView->setIconSize(QSize(16,16));

--- a/gui/mainwindow.h 2023-11-16 15:15:54
+++ b/gui/mainwindow.h 2023-12-08 09:59:22
@@ -75,6 +75,7 @@
     MainWindow(const QString & iniFilename = QString(), QWidget *parent = nullptr);
     ~MainWindow();
     bool eventFilter(QObject * o, QEvent * e);
+    static QString QT_MESSAGE_PATTERN;

and a more advanced QT_MESSAGE_PATTERN:

set QT_MESSAGE_PATTERN=^e[1;32m%%{file}:%%{line}, ^e[1;37m%%{if-debug}DBG%%{endif}%%{if-info}INFO%%{endif}%%{if-warning}WARN%%{endif}%%{if-critical}CRIT%%{endif}%%{if-fatal}FATAL%%{endif}^e[0m: %%{message}

shows in my shell:

and the Application log:

[KejPi]

This looks good :-)

[gvanem]

BTW. starting with AbracaDABra.exe --reverse, the App-log looks:

Not quite Semitic :-)

[KejPi]

What should it do?

[gvanem]

I assume it should read from right to left.

[KejPi]

Somehow yes, but it is testing switch - the application looks completely strange :-D

[KejPi]

Could you please provide a feedback? Can I close this issue?

[KejPi]

No feedback so I assume it works as expected, closing issue.

[gvanem]

Could you please provide a feedback?

I did not see this until now. But you patch made no difference.

[KejPi]

Sorry, I do not understand. I have tested it on Linux right now and it clearly shows some functionality.

[gvanem]

Inspecting the running .exe with ProcessExplorer shows it has this env-var:

QT_MESSAGE_PATTERN=�[1;32m%{file}:%{line}, �[1;37m%{if-debug}DBG%{endif}
%{if-info}INFO%{endif}%{if-warning}WARN%{endif}%{if-critical}CRIT%{endif}
%{if-fatal}FATAL%{endif}�[0m: %{message}

� == 27

(all on one line). But it has no effect in shell:

So I've no idea if this is an issue of Qt6 on Windows vs. Linux.

[KejPi]

Well, I would say it does have an effect but the ANSI sequences are not interpreted correctly and the output is corrupted for some reason. Application does not print function names by default.

[KejPi]

I have reviewed the change I did and it seems to be pretty aligned with your proposal. I assume that it was working you your side when you proposed it.
Meanwhile I can comfirm that it works somehow in Bash under Windows the same way as on Linux.

[gvanem]

Application does not print function names by default.

What does this mean. Modifying my starting abra.bat to use:

QT_MESSAGE_PATTERN=�[1;32m%{function}, �[1;37m%{if-debug}DBG%{endif}
%{if-info}INFO%{endif}%{if-warning}WARN%{endif}%{if-critical}CRIT%{endif}
%{if-fatal}FATAL%{endif}�[0m: %{message}

and no start AbracaDABra.exe (simply AbracaDABra.exe), shows:

So now I'm confused. Why doesn't a start AbracaDABra.exe work! AFAIK any program run with start shall
inherit the env-vars from it parent. Not in this case. Hence I'm inclined to close this issue.

[KejPi]

Application does not print function names by default.

I meant that when QT_MESSAGE_PATTERN is not set, then there are no function names on output, while if I set it, function names appeared, thus the environment variable modifies behavior of the application, so it seems to work somehow. The question is whether this "somehow" is what you expect.

Maybe you could try with old version of the application before introducing log window and compare the behavior to see if is behaves the same or there might still be some problem.