Add to Qt GUI logger functionality
-
Hi there,
I am trying to design a Qt GUI to control some hardware components and I am planning to insert to the interface also a console output (kind of logger) which prints messages/warning/failures coming from the different instruments.
I was googling around and it seems to me the best way to do this at the level of the graphical interface is using QPlainText Widget (set to Read Only).
Any recommendation on that? But more importantly, how to design this on the backend side?
Actually I already have a logger library which launches a thread and handles the queue of messages (coming from the various instruments ) to write on a log file.
Is there a recommended way to connect such an external library to my GUI (in particular to the QPlainText in order to write messages from the queue)?
Thanks a lot,
Any help or link share will be much appreciated :)
-
@Gaetano03 said in Add to Qt GUI logger functionality:
Is there a recommended way to connect such an external library to my GUI
Does this lib use Qt? If so you could use signals/slots to send log messages as signal parameter to your QPlainText.
-
@Gaetano03
Then how are you going to know when it callsstd::...
whatever to output/append a message, so that you can react to it to put it into yourQPlainText
? Especially if you cannot change its source code. Sounds like you might have to monitor its output file (if that's where it writes to) via QFileSystemWatcher class if it is such a "closed" system? -
@Gaetano03
That --- or something similar --- would be the best/easiest if you need your Qt UI program to know when/what the external library does in the way of issuing some message which you would like the UI to know about, so that it can put it in itsQPlainText
. That is what @jsulm had in mind when he wrote:Does this lib use Qt? If so you could use signals/slots to send log messages as signal parameter to your QPlainText.
You could probably also do it by having the lib not know about Qt but have an exported "function pointer". If the calling program (Qt) sets that to a non-nullptr static function in itself, the library could call that and then the Qt program act on it (e.g. emit a signal). That's if you don't want your library to know anything about Qt.
-
@JonB Thanks a lot!
Yep that was the original idea: having the logger not knowing anything about Qt.
But might go back to first option, second one scares me a bit XD
Do you have any examples, links to share on second option btw?
Thanks again, appreciate a lot your help
-
@Gaetano03 No need to be scared :-)
// Define a function pointer type typedef void (*LoggerCallback)(std::string message); // A function to use as callback void log(std::string message) { std::cout << message << std::endl; } // Example how to use a function pointer (callBack) to call a function (log) LoggerCallback callBack = &log; callBack("Hello!");
-
@Gaetano03 said in Add to Qt GUI logger functionality:
Do you have any examples, links to share on second option btw?
Basically what @jsulm has shown above. Certainly for type declaring. To make it clear where i have in mind what goes, the principle is:
- In some library
logger.h
file:
typedef void (*LoggerCallback)(std::string message); extern LoggerCallback g_loggerCallback;
- In some library
logger.cpp
file:
#include "logger.h" LoggerCallback g_loggerCallback = nullptr; ... void libraryLoggingFunction(std::string message) { selfLoggingWhatever(message); if (g_loggerCallback != nullptr) g_loggerCallback(message); }
- In one of your Qt app
.cpp
files:
#include "library/logger.h" ... g_loggerCallback = log; ... void log(std::string message) { emit libraryLogged(message); }
Something along these lines. The point is that the library has a
g_loggerCallback
exported variable. It is set tonullptr
initially, in which case it is never called/used. You can link it as-is with any outside-world which knows/cares nothing about the existence of the function pointer variable. The library still knows nothing about Qt.If and only if the outside-world program the library is linked with chooses to set
g_loggerCallback
to a suitable logging function of its own then that will be called by the library'sif (g_loggerCallback != nullptr) ...
logging code. Whereupon the host Qt or otherwise application can decide what to do with the message in its callback function. - In some library
-
@Gaetano03 said in Add to Qt GUI logger functionality:
So if I understood well, the last add will be to catch that signal from QPlainText and that's it?!?!
Yes. The "tricky" bit, I think, is that you need a
QObject
-derived object toemit
any signal. And the function your Qt app will need to set, likeg_loggerCallback = log;
, will I believe not be able to be a member of any class, it will need to be global/static. I think you will need thatlog
function to have access to a globalQObject
object, e.g. it may have to call on yourQApplication
global object, or perhaps some other singleton class, to emit a signal. -
@JonB said in Add to Qt GUI logger functionality:
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();You mean on the "a" object in the application main? How would this be possible in such a case?
my understanding of what you are pointing out is that even if g_loggerCallback has global visibility, not sure what happens when it points to a QObject function (the call in the external logger library does not know what to do)?
What about making both the function pointer and the log function static? Maybe I am telling blasfemies, sorry for that
-
@Gaetano03
Thata
object inmain()
--- or rather, theQApplication
object --- can be accessed from anywhere in a Qt program (because it's a singleton) via qApp macro or qGuiApp macro or QCoreApplication *QCoreApplication::instance(). That means you can use those anywhere in a Qt application, without worrying about thea
variable inmain()
.You could use that to do something like create your own signal (must subclass
QAppplication
, but that's no problem), which you couldconnect()
to a slot somewhere to update yourQPlainText
widget. Then even a static C function which is called from the function pointer we discussed can get at a Qt object to emit a signal. Or, you could skip signal/slot if you have, by whatever means, a global pointer to your desiredQPlainText
, which the staticlog
function can use to set its text directly. Just be careful with coding, but it should be doable!not sure what happens when it points to a QObject function (the call in the external logger library does not know what to do)?
All the external library knows is the outside world has set
g_loggerCallback
to the address of some function which takes astd:string
(or whatever) as a parameter. That is all it needs to know to be able to call it. What happens at the other end in the function pointed to ---log(std::string message)
, which is in your Qt program, not the library --- is the other end's problem, so far as the library is concerned. [Which is why it would be nice if it worked and didn't crash :) ] -
@JonB Getting a little bit of shakes now XD
"You could use that to do something like create your own signal (must subclass QAppplication, but that's no problem), which you could connect() to a slot somewhere to update your QPlainText widget. "
The other problem would be that signal and slot should be static as well? can you use connect on static objects?
If I understand well, your first option would be to create a class that inherits Qapplication and get an instance of the Qapplication. Here I define my own signal (static?) which I then emits thorugh the log function defined above (still static). This should be catched by the QPlainText widget, but at this point how? Should I make the slot static as well? Actually it seems I am getting real troubles when I try to use connect with static methods.
Will investigate also second option
Thanks a lot
-
@Gaetano03
The only thing which needs to be "static" is the global, non-member functionvoid log(std::string message)
, to which you setg_loggerCallback = log;
, so that the library can invoke it viag_loggerCallback(message)
.That can go something like:
void log(std::string message) { emit qApp()->libraryLogged(message); // or probably MyApplication *myApp = qobject_cast<MyApplication *>(qApp()); emit myApp->libraryLogged(message); }
You would need to subclass and use
QApplication
something like:class MyApplication : public QApplication { signals: void libraryLogged(std::string message); }
Now it remains to have done the
connect()
. Somewhere in your code which can "see" wherever you create theQTextEdit *logmessageTextEdit = new QTextEdit
, or afterwards, and can see theclass MyApplication
definition, needs e.g.MyApplication *myApp = qobject_cast<MyApplication *>(qApp()); connect(myApp(), &MyApplication::libraryLogged, this, &ThisClass::onLibraryLogged); class ThisClass { slots: void onLibraryLogged(std::string message) { this->logmessageTextEdit->append(message); } }
Alternatively, if you don't want to use signals/slots, keep some global reference to the
logmessageTextEdit
pointer to theQTextEdit
and just govoid log(std::string message) { if (g_logmessageTextEdit != nullptr) g_logmessageTextEdit->append(message); }
-
@JonB said in Add to Qt GUI logger functionality:
Not sure where to declare the log function though
At this point what I did is
I created a QApplication subclass in a .h file (integer_interface.h) which looks like this
class integer_interface : public QApplication { Q_OBJECT public: integer_interface(int &argc, char *argv[]) {}; // empty constructor signals: void libraryLogged(std::string message); };
then in my logger_widget class, logger_widget.h (the one that contains the QPlainTextWidget) I have the following class definition:
namespace Ui { class logger_widget; } class logger_widget : public QWidget { Q_OBJECT public: explicit logger_widget(QWidget *parent = nullptr); ~logger_widget(); signals: public slots: void onLibraryLogged(std::string message); private: Ui::logger_widget *ui; integer::logger::errors err_init; integer::logger::integer_logger& logger = integer::logger::integer_logger::get_instance(); integer_interface *myApp = qobject_cast<integer_interface *>(qApp); };
and a declaration of the log static function outside the class
static void log(std::string message);
In the logger_widget constructor I have the following two lines to define the connection
integer::logger::g_loggerCallback = log; connect(myApp,&integer_interface::libraryLogged,this,&logger_widget::onLibraryLogged);
while log and onLibraryLogged implementations look like this
void logger_widget::onLibraryLogged(std::string message) { ui->plainTextEdit_logger->appendPlainText(QString::fromStdString(message)); } void log(std::string message) { integer_interface *myApp = qobject_cast<integer_interface *>(qApp); emit myApp->libraryLogged(message); }
constructor and function implementations are obviously in the corresponding logger_widget.cpp file
It compiles fine, but I get a runtime error "abort()" and the following message
qt.core.qobject.connect: QObject::connect(integer_interface, logger_widget): invalid nullptr parameter
-
@Gaetano03
So I assume that occurs at runtime when it hitsconnect(myApp,&integer_interface::libraryLogged,this,&logger_widget::onLibraryLogged);
and indicates one of the two objects are
nullptr
. Check on line above with e.g.qDebug() << myApp << this;
?
If
myApp == nullptr
, you did remember to create aninteger_interface
, not just aQApplication
now, didn't you...??Everywhere you go
integer_interface *myApp = qobject_cast<integer_interface *>(qApp);
you might follow that withQ_ASSERT(myApp);
to verify all is well at that instant.P.S.
integer_interface(int &argc, char *argv[]) {}; // empty constructor
Do you have
integer_interface(int &argc, char *argv[]) : QApplication(argc, argv)
somewhere? -
@JonB
I think the problem might be where I define myApp is not correct? Which is at the moment into the logger_widget classwhen I qDebug as you said I get indeed the following value for myApp
QObject(0x0) logger_widget(0x1e04f63bcd0, name="logger_widget")
and the app crashes few seconds after it starts
Should I declare the myApp out of any member class as I did for the log function?
-
@JonB said in Add to Qt GUI logger functionality:
If
myApp == nullptr
, you did remember to create aninteger_interface
, not just aQApplication
now, didn't you...????
-
Do you have integer_interface(int &argc, char *argv[]) : QApplication(argc, argv) somewhere?
ye I have it in an integer_interface.cpp, looks like this
#include "integer_interface.h" integer_interface::integer_interface(int &argc, char *argv[]) : QApplication(argc, argv) { }
??
I have it declared in my logger_widget.h class file (if you also see my previous reply), but was thinking maybe should be declared outside of the class?
Or maybe you meant something else from this