Do you have a mixed of Qt and Rust in your project, and dislike how your logs mismatch? Do you want one single source of truth, so it's easier to redirect to a file or other destination? I've been hitting my head against this problem, and developed a novel solution for marrying the two. It's even possible to transfer information like the source file and line!
As mentioned previously in my [Obscure Qt post on logging]({{< ref "obscure-qt3" >}}), the default logging format for Qt isn't that great in the first place. Not to mention, it looks really out of place when mixing in logs from [Tracing](https://crates.io/crates/tracing) in the Rust parts of the code:
The Qt logger looks basic compared to the default formatting of the Tracing crate. But what if we try to marry their output together? If I want to do some advanced operations like redirecting it all to a file, then it becomes easier as we're only dealing with one log!
In this case the final application is Qt based, so I think the best course of action is to shove everything through their logger. Going in the other direction might be an interesting future project :-)
## Piping messages from Tracing into Qt
First we'll want to set up a C function for use by our application. You can use your favorite FFI crate, but in this example we'll just use good ol' `extern "C"` Let's begin by defining a `LogCallback` type. It will take a [QtMsgType](https://doc.qt.io/qt-6/qtlogging.html#QtMsgType-enum), the message, file and line.
Now it's time to define `CustomLayer`. As hinted above, it's a struct with one member: the callback. The trait we'll implement is [Layer\<S\>](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/layer/trait.Layer.html).
Getting the message content is a bit complex due to how Tracing works. We need to implement the [Visit](https://docs.rs/tracing/latest/tracing/field/trait.Visit.html) trait which and it's up to you to decide how to format each field. For this example we'll simply append each field into one big string.
```rust
struct CustomVisitor<'a> {
string: &'a mut String,
}
impl tracing::field::Visit for CustomVisitor<'_> {
Here we implement the [record_debug](https://docs.rs/tracing/latest/tracing/field/trait.Visit.html#tymethod.record_debug) and print each field via the [Display trait](https://doc.rust-lang.org/std/fmt/trait.Display.html) (`{:?}`). Let's plug it into our `CustomLayer`'s `on_event()`:
```rust
let mut buffer: String = String::new();
let mut visitor = CustomVisitor {
string: &mut buffer
};
event.record(&mut visitor);
```
In order for the message levels to transfer, let's set up a match case for converting [Tracing's Level](https://docs.rs/tracing/latest/tracing/struct.Level.html) to Qt's. Except Qt doesn't have a tracing level so we'll map that to `QtMsgType::Debug`.
``` rust
let msg_type = match *event.metadata().level() {
Level::ERROR => QtMsgType::Critical,
Level::WARN => QtMsgType::Warning,
Level::INFO => QtMsgType::Info,
Level::DEBUG => QtMsgType::Debug,
Level::TRACE => QtMsgType::Debug
};
```
The final step on the Rust side is to pass the message and relevant information over the FFI layer like so:
```rust
unsafe {
let file = if let Some(file) = event.metadata().file() {
CString::new(file).unwrap().into_raw()
} else {
null()
};
let line = if let Some(line) = event.metadata().line() {
There's an undocumented function in the [\<QtLogging\>](https://doc.qt.io/qt-6/qtlogging.html) header called [qt_message_output](https://codebrowser.dev/qt5/qtbase/src/corelib/global/qlogging.cpp.html#_Z17qt_message_output9QtMsgTypeRK18QMessageLogContextRK7QString) that will format your message and hand it off to the current message handler. If you don't want to depend on that, using [qFormatLogMessage](https://doc.qt.io/qt-6/qtlogging.html#qFormatLogMessage) works as well.
